链接跟踪中的隐私模式与 GDPR：一次点击到底记下什么

每一场关于链接跟踪与隐私的对话，最后都会走到客户提出的同一个问题上：点我们链接的那些人，你们究竟知道些什么？这个答案通常是临场编出来的，所以它通常会朝某一个方向出错——要么承诺得比系统真正保证的更多，要么含糊到听上去像在回避。

本文提供的是一个更好答案所需的材料：一个点击事件里到底有什么，为什么详细程度是在写入时决定的、而不是从报告里筛掉的，网络地址最后去了哪里，保留期实际上是怎么运作的，同意覆盖的是什么，以及客户那边做合规评审的人会索要哪些文件。这不是法律意见——你承担什么义务，取决于你所在的司法辖区、你的受众，以及你事后拿这些数据做什么。

一次点击会记下什么

在跳转发生的那一刻，任何页面都还没有加载，引擎看到的只是一个请求。从这个请求里，事件可以记下点击发生的时刻、链接与域名、目标地址、由网络地址推算出的大致位置、设备类型、从 user agent 解析出的浏览器与操作系统、对方发来时携带的来源域名、浏览器语言，以及地址上带的营销活动参数。

如果工作区打开了详细的那一层，同一个事件还可以携带省/州与城市及其 GeoNames 标识、坐标与精度半径、时区与访客的本地小时、自治系统号与运营商名称，以及一个带质量评分的流量类型判定。这一层是拿来做什么的，写在流量规则文档里。

有两样东西是刻意不在里面的。邮政编码由地理数据库解析出来，随后并不记录，因为在住宅密集的地方，一个邮政编码已经很接近一个门牌号了。而网络地址本身从不被写下，这件事下面有单独的一节。

事件里没有什么，和它里面有什么同样重要。它不识别某一个人，不说明目标页面有没有加载、后面有没有产生购买，也不携带任何跨站标识符。超出这一层的一切，都需要目标站点那边的第二个数据源，这一点在我们的链接点击跟踪指南里讲过。

限制数据的两种不同方式

把这两者混为一谈，是这个领域里代价最高的错误，而厂商很少把它们分开讲。

先说套餐：它限制的是一个工作区能往回看多久。数据行依然存在；更高的套餐能看到更多。这是一个商业上的限制，升级就能反悔。再说隐私模式：它限制的是一开始就写下什么——被它关掉的东西根本到不了存储，因此没有任何报告、导出、支持工单或者日后的查询能把它找回来，你自己改主意也一样找不回来。

| | 套餐保留期 | 隐私模式 | | --- | --- | --- | | 它控制什么 | 你能往回看多久 | 到底记下什么 | | 它在哪里生效 | 读取时 | 写入时 | | 是否可逆 | 是，升级即可 | 否，对已经写下的行而言 | | 谁能改动 | 管理结算的人 | 工作区所有者或管理员 |

两者同时生效，而这正是大家漏掉的一点。一个工作区，套餐给了两年的查看深度，自己却把保留期设成了 30 天，那它留下的就是 30 天。

详细程度在写入时就已决定

这个设置在设置 → 访客数据与隐私里：三档位置详细程度，外加三个彼此独立的开关。

| 级别 | 事件携带的内容 | | --- | --- | | 完整 | 国家/地区、大洲、省/州、城市、GeoNames 标识、坐标、精度半径、时区、本地小时 | | 城市但不带坐标 | 上面全部内容，但不含坐标和精度半径 | | 仅国家/地区 | 国家/地区和大洲 |

在仅国家/地区下，根本不会为这个事件去查询地理数据库——国家/地区和大洲本来就由 CDN 免费带来。这个设置省下的不只是数据，还有一部分工作量，所以隐私最严的那一档，跑起来也是最便宜的。

开关的范围要窄一些。保存访客的网络控制自治系统号和运营商名称；关掉它，网络明细就是空的。保存完整的来源页地址只控制来源页面的路径和查询串——来源域名始终会保留，因为流量来源报告正是建立在它之上的。识别流量类型关掉的是检查本身，而不只是那些字段：不再查询地址段，不再做反向名字检查，也不再维护行为计数器。

一个按钮就能套用为要求严格的司法辖区准备的那套组合：仅国家/地区，网络不保存，完整的来源页地址不保存，流量类型识别关闭，保留期 30 天。留存下来的是聚合层——国家/地区、设备、浏览器、操作系统、来源域名、营销活动标记，以及当天的访客指纹。最后这一项是刻意保留的：没有它，独立访客这个概念本身，连同建立在它之上的每一项聚合指标，都会一并消失。

有两个后果是双向的。保存会重写工作区里每一条链接、以及每一个已发布链接主页的缓存配置，因此下一次点击就已经按新模式记录，而不是等到下一次缓存过期——「我把坐标关了，可它又多采集了一天」，对于一个以不采集为目的的设置来说，这不是一个可以接受的答案。而这个改动不追溯：已经写下的行，保留的仍然是当时写下的内容。两个方向上过滤都不受影响：一条按城市分流的流量规则，即使城市没有被记录，也照常按城市分流，因为规则决定的是访客去往哪里，而不是关于访客保存什么。

地址：截断，还是干脆不留

行业里常见的做法是截断——把 IPv4 地址的最后一段清零，IPv6 则清掉更宽的一段前缀——这确实比原样存下来要好。它也比听上去要弱：一个被截断的地址，依然标出了一个规模有限的网络，依然能把一个小城镇的访客缩得相当窄，而且还能和同一行里的其他字段组合起来看。截断降低的是分辨率，它并没有把这个字段从系统里拿掉。

另一条路是干脆不留。在这里，地址只在一个函数内部存在片刻，刚好够做两件事，然后就被丢弃。哈希是单向的，输入是地址、user agent、链接域名，以及一份每天在 UTC 零点轮换的秘密盐值，旧的盐值随即被丢弃。

address + user agent + link domain + daily salt  ->  one-way hash  ->  stored
address                                          ->  range lookup  ->  country, city, network
address                                          ->  discarded

由此引出两个必须说清楚的后果，而它们都该出现在和客户的对话里，而不是一条脚注里。

第一，独立访客是一个按天计的指标。因为盐值每晚轮换，同一个人到了明天就是另一个哈希，所以一个月度数字是每天独立数的加总，而不是在数有多少个不同的人。任何一家不用 cookie 却报出精确月度独立访客数的厂商，要么是把某个标识符留得比它承认的更久，要么是在估算。

第二，这个地址日后无法为任何人取出来——你自己不行，一张支持工单也不行。这正是这个设计的用意所在，同时也是一个限制：在答应客户去做一次需要它的排查之前，先知道这一点。

这个原则在输出边界上继续生效。一条链接的公开统计页面，从地理这一层只拿到国家/地区和城市：没有网络，没有流量类型，没有质量评分，也没有坐标；把守这条边界的是一个针对响应结构的测试，而不是约定俗成。每一项明细究竟暴露什么，写在地理数据分析里，也写在地理位置与流量质量页面上。

保留期是一项工作区设置

详细事件的保留期字段留空即采用平台上限 730 天，也可以填一个具体的天数。

机制比这个数字更要紧。这个值是随每一个事件一起保存的，而表的过期时间正是按这个值来表达的。在 30 天设置下写入的一行，即使工作区之后改成了 730 天，也仍然在 30 天后被删除，因为生效的是写入那一刻的设置。

正是这一点，让保留期成为一个能用的答案，而不是一句含糊的安抚。「我们保留 90 天」这句话，如果那个 90 是在写入时就盖在每一行上的，那它站得住；如果它描述的只是一个报告筛选器，而底下的行实际上被留了两年，那它站不住。比较平台时，要问的不是保留期是多少，而是它在哪里生效——另外还要单独问一句套餐的查看深度是多少，因为那个限制同样在起作用。两者都写在访客数据与隐私模式里。

同意针对的是数据，不是跳转

这里最常见的误解，是把跳转本身当成同意所针对的对象。一个点了短链接的访客，已经要求被送去某个地方，而把他送过去正是这项服务本身。同意针对的是另外两件事：关于这次访问记录下了什么，以及存放在访客设备上、并非严格必要的任何技术。

这样看问题会带来实际的后果。这里没有跨站测量 cookie，因为当天的哈希替代了大多数同意法规当初所针对的那套机制。跳转路径上正好只有一个 cookie——你自己跳转域名上的首次访问标记——而且只有当你的某条规则真的要问「这是首次访问还是回访」时，它才会被设置。所以「你们的链接会不会设置 cookie」这个问题，答案取决于一份你能指着看的配置，而不是一条笼统的政策。

跟踪像素是明确的例外。当一个工作区给链接挂上再营销像素时，这个像素以及它设置的一切，属于像素的所有者和那家第三方，而不属于跳转服务。对于这部分处理，链接所有者是控制者，负责把它披露出来并取得所需的同意——代表客户挂像素的代理商，应该把这一条写进客户合同里，而不是在一次审计中才发现它。

角色之所以要紧，也是同一个道理。就点击数据而言，创建这条链接的工作区或合作伙伴是控制者，平台是处理者，因此合法性依据、隐私告知以及任何同意，都是链接所有者的责任。替客户运营链接的代理商处在这个位置上的次数，比他们自己预想的要多，我们的代理商品牌短链接指南从商务角度讲了这件事。

评审会向你索要的那些文件

有两份文件承担了大部分工作，而且它们都不该临时编出来。

第一份是数据处理协议（DPA），它管的是代表你进行的那些处理。评审读它，是为了找到一组很具体的东西：每一类数据下谁是控制者、谁是处理者，数据主体和个人数据的类别，安全措施，数据泄露的通知时限，数据离开欧洲经济区或英国时所用的传输机制，审计权，以及合同终止时数据会怎么处理。我们的 DPA 写明了这些条款，其中包括 72 小时的泄露通知时限、在适用场合下附带英国附录的标准合同条款、提前通知即可行使的年度审计权，以及在导出窗口结束后 30 天内删除数据。

第二份是次级处理者清单，它列出代表平台处理数据的那些第三方、每一家的用途，以及它把数据放在哪里。它是数据处理协议的一部分，而不是一个营销页面，而评审真正在评估的是围绕它的机制：新增或更换一家之前至少提前 30 天通知，有一项写明在册的异议权，以及在确实没有合理替代方案时，可以无罚则地终止受影响的那一部分。我们的次级处理者清单公布了当前的供应商，附带用途和数据所在地；总体描述写在隐私政策里。

如果一家厂商拿不出这两份文件，或者拿出的次级处理者清单上根本没有配套的通知机制，那这就是评审的结论——而不是某个认证徽标的缺席。

和客户对话时的一份清单

1. 拿出当前实际使用的那一档模式下的字段清单——不是平台的最大集合，而是那个工作区今天真正在写下的东西。
2. **说清以天为单位的保留期，以及它在哪里生效，**并且和套餐的查看深度区分开，说明当前起约束作用的是哪一个。
3. **用一句话回答地址问题：**完整存储、截断存储，还是不存储——如果不存储，就解释当天的哈希，以及独立访客按天计的性质。
4. 列出跳转路径上的 cookie，以及每一个是因为什么才被设置的。「除非配置了首次访问规则，否则一个也没有」胜过「仅必要 cookie」。
5. **把你自己挂上去的东西和平台做的事分开。**像素、第三方标签以及目标站点那边的数据分析，是你的处理，不是跳转服务的。
6. 把数据处理协议和次级处理者清单直接交出去，而不是转述它们，并且说明变更的通知期。
7. **把隐私模式设到你的报表还能承受的最严一档，**然后确认哪些明细因此变空了——这正是你弄清一个设置究竟是被选中的、还是仅仅默认落到那里的办法。

这个话题让人不舒服的地方在于：写入时做的决定，在两个方向上都是永久的。你当初选择不采集的数据，等到日后有人要一份城市明细时，找不回来；而你当初确实采集了的数据，等到日后有人问你为什么会有它时，也没法取消采集。这正是一个理由：在一段合作开始的时候就有意识地做决定，而不是继承一个默认值。在最严的那一端，数据分析里的一切照常工作；变的是你能看到多少访客，而不是你能看到多少营销活动。