隐私和安全总是协助寡头把花园围墙越砌越高，同时花园围墙也常常侵蚀一些开放的商业模式，技术创新却不断支持新的商业模式和客户需求。今天讲的事情就是浏览器禁用三方Cookie后的商业模式和技术创新。

科技向善是很多公司愿景，一家公司的”善“，也许是其它公司的”不善“。

谷歌2019年提出禁用第三方Cookie，计划在2022年实现相关的方案。谷歌的Chrome占有超过2/3的市场份额，因此谷歌禁用第三方Cookie引起波澜最大。为了支持定向广告，去年谷歌提出了FLoC（联邦学习人群）的技术，用于识别一些行为相似的人群，这个技术会成为禁用第三方Cookie后，用于广告定向的技术基础。

1） 第三方Cookie如何支持重定向广告

对于PC的浏览器，AdTech公司会通过”第三方Cookie“技术，把不同Publisher的同一用户，利用第三Cookie ID技术关联起来，为广告主提供定向用户兴趣或ID的能力。

• 了解用户行为，为用户打标签，这些标签可以被广告主使用

• 在Publisher 和 Advertiser的网站进行埋码，实现Retargeting功能。

禁用三方Cookie后，AdTech公司无法识别来自不同Publisher的同一用户，也拿不到一个稳定的用户ID，因此过去定向的商业模式需要找到新的技术方案。（顺便说一下，这个影响主要是国外的PC广告，对国内的移动为主的广告行业影响不大）。

禁用第三方CookieID后的伪标识时代

稳定和同一的标识（ID）是广告投放的核心概念，在初级阶段，投放都是以不可变的ID为主（包括设备ID ,IMEI)，但目前广告应用都已迁移到可重置的ID（例如 IDFA，OAID等）。在PC领域，目前以CookieID为主，未来禁用三方Cookie后会使用一个CohortID(人群ID)或兴趣组（Interest Group)的技术。

另外， 很多巨无霸公司也会构建自己的花园围墙，用户标识也会使用自己特定的标识（例如OpenID,BDID,UniID等）。这些标识都是经过特殊加密，经常会动态换标识，以及加密方法和场景或广告主有关。例如，对于不同的广告主，同一个用户会使用不同的ID。举例来说，微信的OpenID是代表一个用户ID，在不同公司的公众号下，同一个人的OpenID是不一样的。在巨量的BDID中，不同广告主获得的同一用户的BDID也是不一样的。

2）未来网络隐私保护的模型

Michael Kleber是谷歌的一位数学家，他提出一个未来网络隐私的模型，这个也是后面所有技术的基础逻辑。

1. 一个人在不同网站有不同的ID（一方ID），但不提供全局唯一的ID

2. 第三方技术伙伴在授权情况下可以访问一方ID

3. 不同的第一方ID，不支持一一关联，但作为一个群体可以进行关联

既然无法使用第三方Cookie ID用于标识同一个人，那么AdTech如何实现定向广告？

前几年，大家都使用一个兴趣组的概念，其实就是一些Tag标签，Publisher和AdTech对齐一些兴趣分类体系，或者用关键词。去年，谷歌提出了一种技术FLoC（ Federated Learning of Cohorts）用于标识一组可定向的人群，这样定向的时候就无需使用个体的CookieID，这个Cohort也是全局性质的。

这里面有很多核心问题：

1）内容匹配：人群ID（Cohort)如何产生和管理，包括生命周期，包括隐私问题，如何与广告内容匹配？

2）优化度量：如何支持动态定价，动态创意等优化的场景？

3）数据管理：广告的归因和转化报告如何获取？（缺少个体ID后的一些新问题）

3）用户标识从个体ID到人群ID：FLoC的诞生

禁用第三方Cookie后，AdTech公司无法获得统一的用户ID后，谷歌提出了一个FLoC算法，可以提供统一的人群ID，这个能力会内置在浏览器中。FLoC可以聚合相同浏览行为的人群，这些类似行为的人群叫做Cohort。这个Cohort的ID可以被广告主定向使用。

3.1）FLoC的基本算法逻辑

如何定义网络的一群人，Google 提供了一个FLoC的算法。基本原理如下

a） FLoC定义了一个浏览行为到Cohort ID的一个算法。这个算法运行在浏览器上，因此不同浏览器上，流量行为相同的人，会获得相同的CohortID.

b）CohortID 代表了一个人群，只有这个人群大于一定的数量（大约是千或万级别），这个CohortID才生效，可以被使用。

c）CohortID 的算法使用的是SimHash算法，这个算法效率很高，浏览行为相近的用户，他们CohortID也很接近。 用户浏览行为都是在本地计算，没有浏览数据上传到集中服务器，Cohort的生成是在本地进行（计算的模型和参数是通过网络下载的）。

d）FLoC算法不计算和考虑敏感网站的行为。如果服务器感知一个Cohort的计算中包含了敏感网站，集中服务器将发送新的参数，这个Cohort将被重新计算。

e） 一个网站可以通过声明的方式，设置是否参与Cohort的计算。

" Permissions-Policy: interest-cohort=()"

3.2）FLoC的simHash算法和sortingLSH算法的原理

sortingLSH

CohortID使用了simHash算法，行为相近的人他们CohortID的距离也很近。这种算法有一个好处，当某一个Cohort的人数特别少，或特别多的时候，在聚合这些hash值成为Cohort的时候，可以进行以一些调整（聚合或拆分），以满足差分隐私的要求。

3.3）Cohort计算的其它问题

1）CohortId使用多长的数据来计算：一般是近一个月的数据

2）使用哪些数据计算CohortID : 网站，网站+PII, 网站+三方数据PII，例如是否使用登录信息参与计算？

3) 敏感网站不参加计算，如果参加了计算，中心服务器获知后，将取消这个Cohort，并且设置新的参数，重新计算Cohort.

3.4）FLoC的实现的目前状态态： 

FLoC在本月初上现在最新版本的Chrome上了，目前还在灰度上线中，只有很小部分（大约5%）最新Chrome浏览器有这个功能，可以通过一下网站会检查你的浏览器是否enable了FLoC ( https://amifloced.org)

4）FLoC模型下的商业模式和技术方案

定向广告技术之前是基于CookieID的个体，现在需要基于CohortID了。其中的竞价模式发生很大变化，AdTech公司无法拿到具体的ID，也无法进行有效竞价。因此很多定向问题只能依赖浏览器，或者第三方独立服务商提供。在这个背景下，谷歌和很多广告技术公司都提出了自己的技术方案。

4.1） TURLTEDOVE

TURLTEDOVE是早于FLoC的一个禁用三方Cookie的广告定向的解决方案。它里面定义了一个Interest Group的概念，类似于FLoC的CohortID的概念。由于没有确定的用户ID，因此AdTech公司在竞价的时候获得不了详细的用户信息，因此TURLTEDOVE引入了一个变革型的调整：它将广告竞价与广告转化报告转移到浏览器中。这两个变化将引起AdTech技术的根本性改变。

解释一下其中步骤：

第一步：浏览器访问Publisher，并且发送CohortID给Publisher , 并传递给AdTech。

第二步：AdTech公司和浏览器建立连接，并把竞价策略（同步到浏览器）

第三步：AdTech公司获取广告信息到浏览器中（非实时）

第四步：在Publisher需要Trigger广告的时候，并且内部的竞价配置，广告信息都有的情况下，进行Auction竞价，并展现广告。

第五步：AdTech公司会定期根据策略，拉取广告投放的聚合数据，包括曝光和竞价的信息。（例如每2天）

4.2） FLEDGE

TURTLTEDOVE是一个实验的原型，很多公司都基于这个原型开发实现或扩展实现。FLEDGE是基于TURTLEDOVE的一个CHROME的实现，计划2021年能够发布试运行。以下是FLEDGE的主要目标

• FLEGE会使用Interest Group的概念用于目标人群的划分，会使用一些关键词的实现。FLoC的CohortID应该是后期的计划。

• 支持一个定期更新Interest Group的机制，确保每个Group的大小足够大，并满足差分隐私的要求。

• 实现浏览器上的基于兴趣组的广告筛选和广告竞价模式，支持在沙箱环境的测试.

• 确保广告的最小展现数量，以保护最小人群的隐私。

• 广告生成技术，使用Fenced Frames技术作为试用场景，以支持事件级别的广告投放数据报告。

• 对于竞价需要的一些实时数据，通过第三方的共享KV服务器来实现。

4.3） 广告转化和归因：

所有广告竞价在浏览器上完成，广告主如何获得浏览器的曝光统计数据和转化数据？广告技术公司需要在浏览器上注册所有转化的动作，归于来源等设置。广告技术调用浏览器的API获取归因结果，

归因结果做了很多限制。

1)  归因结果由浏览器提供，AdTech公司可以通过API方式收集这些数据（浏览器在访问Publisher会被AdTech调用API）

2）用户ID变成EventID，使用有限数据长度（例如64bit)。注意，这里面只是事件关联的一个ID。并非持久的一个用户ID.

3）归因结果中，拟会增加一些噪音，以混淆实际ID，例如增加5%的噪音

4）获取报告事件，每两天或三天可以获取一份归因报告

4.4） 虚假浏览的支持（Trust Token)

浏览器承担了很多广告引擎的角色后，虚假浏览的责任会更多落在浏览器上。浏览器也会暴露一个虚假流量的信号给Publisher。这个就是Trust Token，对于每一个Publisher都可以使用自己domain下面的这个API获得bot的判定信息。Trust Token使用了Privacy Pass的安全协议。Trust Token在去年年底的Chrome版本上上线。

4.5） 防止设备指纹的设置

浏览器虽然不在提供唯一的CookieID ，但是很多方式都可以构建设备指纹。最通常的方式，就是使用浏览器版本，OS版本，机器硬件配置，IP和网络等复杂型号，综合来生成设备的唯一标识，虽然这种方式有概率出错，但是大概率还是可以获得相对唯一的标识。

特别是IP的信号，有比较好的差异性。谷歌的一个员工，提出一个建议叫做Willful IP Blindness，将IP获取的范围，分为网络层获取，和应用层获取；网络层获取还是提供真实的IP的地址，应用层只能获取应用层的IP，在广告的场景下，这个IP可以做一些针对性的扰码。对于其它需要IP地理位置的应用，可以做一些偏移，或者弹性的开放能力。

4.6） 其它的技术方案：

SPARROW(Criteo)：由于TURTLEDOVE将所有的决策都放到浏览器中，很多数据统计，数据分析，模型实验等工作都不利于广告投放的优化，Criteo在2020年基于TURTLEDOVE提出了一种加强的方案，其核心想法就是引入一个Gatekeeper，这个是第三方公立的技术公司，这个Gatekeeper按照标准实现一些实时的竞价等标准行为。这种方案可以降低谷歌花园围墙的高度。

DOVEKEY (Google)：DOVEKEY是谷歌公司推出的基于TURTLEDOVE的解决方案，其中考虑了很多SPARROW的想法，为了解决实时竞价出价的问题，它将Gatekeeper简化成一个标准的KV存储服务，所有的AdTech供应商只需要将出价和策略，写入这个标准的第三方的KV服务。实际竞价依旧在浏览器中，但是出价更加实时一些。

SWAN（Storage With Access Negotiation）：

有一家广告公司1PlusX，提出一种方案，在浏览器定义一个Private Storage 里面，可以定义一个私有的存储区域，保存各个Publisher的Profile，如果两个Publisher联合打通了一些用户，那么浏览器可以识别出这些打通用户，并且做一些广告的竞价选择。

总结各种江湖道术

禁用三方Cookie后，各种技术道术层出不穷，但最后收官的还是以花园围墙的巨擘们。我相信以FLoC的底层技术，标识(ID)是核心的能力。这种能力将改变所有的技术方案。

6） FLoC系统架构和商业架构的风险：

基于FLoC的整个生态还在快速演化当中。它也面临很多风险，尤其是以下几个风险。

工程师进行反编译：比如一个Cohort里面的人的一些信息，可能还是可以通过逆向工程获取。

缺少统一的安全模型：，目前各个模块和组件都是协同发展，缺少统一的安全攻击预防模型，在反欺诈，标识组，竞价模型等都有潜在的集成风险。

商业联盟的复杂性：目前推动这个技术架构的演化，主要是Web Advertising Business Group ，它是W3C组织的一个小组，里面成员基本来自各个公司，他的作用也是协调作用，真正技术标准还是以Google为首的工业寡头，很多AdTech公司也会参与其中。Google短期内的目标，还是构建它的浏览器标准，并非迁移现在的商业模式。

7）总结

构建一个稳定的生态是非常复杂的一件事情，稳定的生态一定要有底层的核心逻辑，用户标识就是一个核心基础。虽然，新技术五花八门，道术杂多，但是没有底层逻辑的技术，没有客户需求的驱动，再好的技术也难走远。

作者介绍：

欧阳辰，《Druid实时大数据分析》书作者，《构建高质量的软件》译者，《产业区块链-营销篇》作者。喜欢大数据，互联网技术，企业软件和服务，有空也会在个人微信公众号“互联居”中，分享一些互联网技术心得，订阅“互联居”公众号，与作者直接交流。

参考：

FLOC技术详解：https://github.com/WICG/floc

FLOC技术论文：https://raw.githubusercontent.com/google/ads-privacy/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf

谷歌隐私沙箱：https://blog.google/products/ads-commerce/2021-01-privacy-sandbox/

FLOC的Dovekey实现：https://cxl.com/blog/floc-dovekey/

聚合转化度量https://web.dev/conversion-measurement/

综合内容 https://clearcode.cc/blog/chrome-privacy-sandbox-explained/

聚合转化度量的项目和代码：

https://privacycg.github.io/private-click-measurement/

https://github.com/WICG/conversion-measurement-api

独立存储区SWAN的解决方案：https://github.com/1plusX/swan

虚假流量的判定

https://github.com/WICG/trust-token-api

https://privacypass.github.io/

IP屏蔽的技术

https://github.com/bslassey/ip-blindness/blob/master/willful_ip_blindness.md

https://github.com/bslassey/ip-blindness

广告技术文章 

Adobe DMP的一些设计

2018年，数字媒体的程序化天空

浅谈2018年的MarTech技术栈

营销DMP的漫谈指北

广告技术和区块链的精彩

OpenRTB 3.0的热寂

Ads.txt是虚假流量的终结者么？

营销，我拿什么来AI你？

一个广告技术人的自白

探索路上永不止步：区块链驱动广告透明和安全

移动广告作弊流量的浅潜规则

互联网广告的归因分析(Attribution Analysis)

MarTech是广告主视角的的营销，技术和管理

广告点击率预估是怎么回事？

“自由即奴役”的Google AMP

两分钟搞明白Beacon,iBeacon和EddyStone

预算平滑(Budget Smooth)是怎样花钱的？

互联网广告CPM,CPC,CPA的魔咒和圣杯

拒绝垄断，走向开放的Header Bidding

自由之设备，独立之人格：从设备识别到跨屏营销

DSP的繁华和伤心

移动DeepLink的前生今世