监管找上门之前,先把自己网站上的追踪代码查一遍
你在网站上装的每一个营销像素,都是一份以访客名义签下的数据共享协议。而法律正越来越倾向于让网站经营者本人,而不是背后的平台,来为此负责。
装上一枚营销像素,你就替每一个未来会打开你网站的人做了一个决定,而这个决定关乎他们的数据,不是你的。这段代码埋在页面头部,访客还没读到一个字它就已经触发,把行为信号发送给一个你永远无法检查的第三方。如果你从没坐下来审计过自己网站上的追踪代码,那你其实在运营一套自己都说不清、控制不了的数据输出系统。这是一段你在毫不知情的情况下签下的供应商关系,理应和其他任何供应商关系一样,被摆上风险清单。
追根溯源,因为机制本身就是全部论证所在。追踪像素是供应商写的代码,无论是一段JavaScript标签还是一次裸露的图片请求,都是在访客浏览器里、借着你域名的信任被加载执行的。它读取被告知要读取的内容,发送到被告知要发送的地方。你拿不到副本,也拿不到回执。《消费者报告》联合软件公司Disconnect扫描了约两万个网站,发现数百家机构在悄悄把访客数据交给TikTok,其中包括从未安装过该应用的人的数据。没有人入侵谁,网站经营者自己嵌入了这段代码,平台只是接收了经营者同意发送的东西。
为什么一段看不见的追踪代码,能让你变成数据控制者?
因为只要能确定采集行为发生了,即使你从未碰过数据,责任也可能落在你头上。欧盟法院在Fashion ID一案中裁定,网站经营者嵌入第三方社交插件,即便从未接触过由此采集的数据,也可能就该数据的采集和传输被认定为共同控制者。这一判决是依据欧盟法律作出的,但2020年底之前欧盟法院的判例,依据《2018年欧盟(脱欧)法》第6条被保留为英国国内法(即所谓“留用欧盟判例法”),而英国版GDPR第26条延续了同样的共同控制者判定标准,英国信息专员办公室(ICO)关于控制者与处理者的指引正是这样适用的。有一点需要说明:目前还没有任何英国法院判决或ICO执法行动,把这套逻辑正式套用到嵌入式营销追踪代码上,所以以下是笔者对法条走向的推断,而非已经落定的英国判例。照这个推断走下去,如果你选择了采集的方式,你就要为采集行为本身负责,至于接收方之后如何处置数据则是另一回事;而“是供应商采集的,不是我”这套辩护,一旦监管机构追问“是谁决定让供应商的脚本在这个页面上运行”,就会立刻站不住脚。对于同时服务新加坡等亚太市场的企业,新加坡《个人数据保护法》(PDPA)在“同意”与“合理采集”上的要求方向相近,提前用这个案例校准自己的合规敞口,远比等本地监管机构划出同一条红线要划算。
这正是大多数营销技术栈在经济账上站不住脚的地方。数据流不花一分钱就能加上去,财务报表上也看不见,于是它只会越堆越多。这里加一个归因像素,那里加一个再营销像素,再来一个热力图工具,一个会“打电话回家”的客服插件。单独看,每一个都说得过去。合在一起,它们就构成了一张把你访客行为分销出去的网络,公司里没有一个人能凭记忆把它完整画出来。风险是真实的,数据流是隐形的,而这两样东西,从没有人给它们标过价。
如何审计网站上的第三方追踪代码?
把它当作一次供应商复核来做,因为它本质上就是。打开浏览器的网络面板,或者用The Markup的Blacklight这类扫描工具,在一个干净、禁用缓存的会话里把每个重要页面都加载一遍。记下每一个被访问到的外部域名。针对每一个,写清楚供应商是谁、目的是什么、真被问起来你会援引哪条合法依据。然后检查时间点,这是大多数团队会漏掉的一环:看这段追踪代码是不是在访客同意之前就已经触发。一个指向www.facebook.com/tr/(Meta像素)或analytics.tiktok.com的请求,如果在你的同意管理平台写下“已同意”的cookie之前就在页面加载时触发,这正是要重点标记的模式,因为挂在它前面的那个同意横幅其实什么也没拦住。任何在同意之前就采集数据的、或者屋子里没人能解释清楚的,统统拿掉。把清单留存、注明日期,并按固定周期重新跑一遍,因为脚本可以在你完全没碰代码库的情况下自行变动。
供应商能在你装好追踪像素之后,悄悄改动它采集的内容吗?
追踪代码治理里最让人不安的一点是:你上个季度审计过的那段代码,不保证就是今天正在运行的那段。供应商的脚本会执行供应商当下决定它该做的任何事,而这个决定存在对方的服务器上,不在你的代码仓库里。采集范围是一个可以被远程改动的设置,所以你页面头部那枚像素,最好被当作一段随时可能在你不知情、不签字的情况下被重新指向别处的代码来看待。
这正是许多营销团队还没真正感受到的地方:英国体系是有牙齿的。非必要追踪代码同时受《隐私与电子通信条例》(PECR)和英国版GDPR约束,ICO明确要求必须先取得同意,才能设置或读取非必要的cookie及类似技术。一段在同意横幅被回应之前、页面一加载就触发的标签,因此已经踩在规则之外,这让“同意前触发”成为一项执法风险,而不只是风格上的小瑕疵。
把审计结果压回合同里去。数据处理协议不该只是承诺“数据到手后会小心处理”,它应该从源头限定一段脚本能采集什么。可以套用进供应商附件的措辞大致是:处理方不得通过嵌入式脚本采集、读取或传输超出附件X所列字段与用途的个人数据,不得在控制方记录数据主体同意之前如此行事,也不得在未经控制方书面事先批准的情况下扩大该范围。如果某家供应商不肯接受这样一条条款,就把这个拒绝本身当作一个实质信号,计入是否使用该供应商的决策里。
所以真正的连带后果落在采购和合同上,而不是营销日历上。这首先是一个技术策略问题,其次才是法律问题,因为解决办法本质上是架构性的:摸清每一条对外数据流,把它挡在真实的同意机制后面,把每一段供应商脚本当作你自己选择去信任的不可信代码来对待。让自动化能力始终处于人的掌控之下的那套纪律,同样适用于你早就上线的营销技术栈。采集的工具就摆在你自己的网站上,加载它的决定署着你的名字,拿“不知道自己页面头部写了什么”当挡箭牌,监管机构没有义务买账。
常见问题
追踪像素能在访客同意cookie之前就采集数据吗?
可以,而且很多确实如此。脚本被放在页面加载环节,浏览器一读到就会触发,往往比同意横幅本身渲染出来还要早。ICO的立场是,非必要追踪代码必须先取得同意,才能被设置或读取,所以一段在同意之前就采集数据的像素,意味着那条横幅只是摆设,这也是追踪代码审计最先要揪出来、拦下来的问题之一。
第三方像素滥用了我们访客的数据,我们要承担责任吗?
按照Fashion ID判例的逻辑(经《2018年欧盟(脱欧)法》保留为英国国内法),嵌入第三方采集工具的经营者,即便从未接触过数据本身,也可能就其促成的采集和传输被认定为共同控制者。目前还没有任何英国法院或监管机构把这套逻辑正式套用到营销追踪代码上,所以应把它当作一项现实存在的风险,而不是已经定论的法律。责任范围通常限于你自己决定了目的和方式的那部分操作,而选择加载这枚像素,恰恰就是这样一个决定。
第三方追踪代码审计应该多久做一次?
把它当作持续性工作,而不是一年一次的例行公事。供应商的脚本会远程更新,不会牵动你代码库里的任何一行代码,所以你曾经批准过的采集范围,可能在毫无通知的情况下扩大。按固定周期重新扫描,并且每次改动标签管理器或营销工具之后都要再跑一遍。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。