数据分析

隐私设计：七项原则、GDPR 第 25 条和一个算例

隐私设计是从一开始就把隐私做进产品。把七项原则落到团队实践，讲清 GDPR 第 25 条的要求，用一次埋点方案评审说明怎么把含个人数据的字段从 6 个降到 1 个，并附检查清单。

伊森·布鲁克斯发布于 2026 年 11 月 5 日 5 分钟阅读数据分析

示例数据

用你自己的数据试一下

这篇文章里出现的报表免费版全都有。一段代码，网站和 App 都能接，最多 10 个站点。

免费开始

隐私设计很容易赞同，却不容易落地。本文把七项原则翻译成产品和统计团队真正要做的事，概括 GDPR 第 25 条，并走一遍一次埋点方案评审：6 个含个人数据的属性变成 1 个假名用户 ID，所有报表照常可用。

读完你会知道

在设计阶段就决定需要哪些数据，而不是上线之后
默认设置要在用户什么都不做时就保护他们
采集时就对标识符做假名化、截断 IP
大多数统计报表不需要姓名或邮箱
设定并执行保留期，日志和导出也要算进去

什么是隐私设计？

隐私设计（Privacy by Design，也译作「隐私始于设计」）是指从一开始就把隐私保护做进产品、系统和流程里，而不是上线之后、或者被投诉之后再补。这一思想由时任加拿大安大略省信息与隐私专员的 Ann Cavoukian 在 20 世纪 90 年代提出，如今在欧盟和英国已是法律要求：GDPR 第 25 条要求通过设计和默认设置保护数据。

落到实处，隐私设计就是在每个设计决定上都问：这些数据我们到底需不需要？需要的话，最少要多少、存多久、谁能看、怎么保护？

七项基本原则

#	原则	在产品团队里意味着什么
1	主动而非被动，预防而非补救	在设计文档阶段、写代码之前就评审隐私
2	隐私是默认设置	用户不用改任何设置就受保护；任何额外收集都要用户主动同意
3	隐私嵌入设计	做进架构里（哈希、最小化），而不是事后贴一页隐私政策
4	功能完整：正和而非零和	找到既能实现功能、又能保护隐私的设计，比如用汇总统计代替追踪个人
5	端到端安全	在数据的整个生命周期里保护它：采集、存储、使用、删除
6	可见和透明	记录收集了什么、为什么收集，并且可以核查
7	尊重用户隐私	以用户利益为中心：清楚的选择、方便的查阅和删除

原则	实践
主动	设计文档阶段评审
默认保护隐私	不用改设置就受保护
嵌入设计	代码里做哈希和最小化
正和	用汇总代替追踪个人
端到端安全	保护到删除为止
透明	记录并可核查
以用户为中心	方便查阅和删除

GDPR 第 25 条把这些变成了欧盟和英国的法律义务。

通过设计： 在决定如何处理数据时以及处理过程中，都要采取适当的技术和组织措施，比如假名化和数据最小化，并综合考虑技术水平、成本和对个人的风险。
通过默认设置： 默认情况下，只处理每个具体目的所必需的个人数据：包括收集的数量、处理的范围、保存期限和可访问的范围。

对高风险的处理，第 35 条规定的数据保护影响评估（DPIA）就是隐私设计的正式形式。相关技术：假名化、哈希和无 Cookie 统计。

计算示例：把隐私设计用在统计埋点方案上

某 SaaS 公司在产品改版上线前，评审了产品分析的埋点方案。方案里 18 个事件共有 42 个事件属性（示例数据）。

第 1 步：盘点。 有 6 个属性包含或可能包含个人数据：email、full_name、phone、完整页面网址（有些从邮件链接带着 ?email= 进来）、ip_address，以及一个自由文本的 feedback 字段。

第 2 步：逐个问「真的需要吗？」

属性	声称的用途	决定
`email`	和 CRM 关联	换成内部用户 ID；实在需要关联键就做哈希
`full_name`	没找到用途	删除
`phone`	没找到用途	删除
页面网址	页面报表	保留路径；去掉 UTM 和白名单以外的查询参数
`ip_address`	国家报表	采集时截断；推出国家后丢弃其余部分
`feedback` 文本	产品调研	挪到问卷工具，单独取得同意、单独设定保留期

第 3 步：设定默认值。 在用户同意更多之前，统计以无 Cookie 模式运行；只有登录后、且只针对产品功能，才做实名追踪；原始事件保留 13 个月，而不是「永不删除」。

结果： 含个人数据的属性从 6 个降到 1 个（一个假名的用户 ID）。各团队用到的报表全都照常可用：页面、漏斗和留存分析都不需要姓名或邮箱。统计系统的 DPIA 结论从「高风险，需采取缓解措施」变成「剩余风险低」，后来处理一次数据主体请求只用了几分钟，而不是一天。

这就是第 4 条原则的体现：功能完整，数据却少得多。

app.tapcub.com/platform/data

含个人数据的属性

6 → 1

▼

仍可用的报表

全部

原始事件保留期

13 个月

埋点方案评审 · 个人数据

42 个属性、18 个事件

属性	决定
email	换成用户 ID
full_name	删除
phone	删除
页面网址	只保留白名单内的参数
ip_address	采集时截断
feedback 文本	挪到问卷工具

示例数据。

示例数据

产品和统计的隐私设计检查清单

[ ] 每个新数据字段都写明用途和负责人
[ ] 除非必要，个人数据不发给统计、日志或第三方，见不要把个人数据发进来
[ ] 标识符做假名化，IP 地址做截断
[ ] 默认设置保护隐私，额外追踪需用户主动同意
[ ] 定义保留期并自动执行
[ ] 按角色限制访问，访问个人数据要留日志
[ ] 能很快完成数据主体请求（查阅、删除、导出）
[ ] 高风险处理做 DPIA
[ ] 评估供应商，并签订数据处理协议

常见错误

把隐私政策当成设计。 文字不会让数据变少，架构才会。
先收集，以后再说。 在 GDPR 下，「以后可能用得上」不算目的。
只在上线前把一次关。 评审要在设计时做，那时改动成本最低。
过度依赖用户同意。 同意并不能让收集超出必要范围变得合理。
忘了日志和备份。 调试日志、错误追踪和导出文件里的个人数据，照样是个人数据。

TapCub 怎么按隐私设计来做

TapCub 的默认设置遵循同样的原则：用加盐访客哈希做无 Cookie 计数，IP 截断和保留期限制，以及采集分级，只有你打开时才做实名追踪，必要时取得同意。为识别用户而发送的登录邮箱，存储前会先转小写再哈希。你可以按地区设置隐私规则、遵守「请勿追踪」，并在合规中心处理数据主体请求。另见符合 GDPR 的网站统计。

另见：数据驻留。

另见：什么是数据最小化？含义、法律要求和例子。