TURTLEDOVE、SPARROW、DOVEKEY、FLEDGE，你算什么鸟？
极诣上篇介绍了谷歌的FLoC。它按照分组（cohort）原则方法将单个用户隐藏在上千具有相同特性的用户之后，由此达到隐私保护的目的。我们认为FLoC并不能代替第三方Cookie，因为第三方Cookie不仅仅是用于跨域跟踪用户，还有其他诸如第三方登录等作用。并且FLoC仅仅基于Chrome浏览器，纵然其占有六成以上的市场份额，依旧有很大一部分处于其他浏览器设备上。
谷歌不情愿地告别第三方Cookie会为其赚得美名的同时，也会被反信任问题困扰。当FLoC成为一个黑盒子，同时其他广告技术公司又无法通过浏览器级别的技术与之抗衡时，带来的必定是垄断。
好了，上回我们讲完FLoC留了一个引子，讲了点TURTLEDOVE。这是怎么回事呢？我们接着讲。
TURTLEDOVE
TURTLEDOVE被看作在失去第三方Cookie后Chrome环境下的精准定位方式。遗憾的是它依旧不是基于个体的。仅在人群达到一定规模之后才生效，以满足隐私保护的需要。TURTLEDOVE被看作未来服务于Chrome环境下的再营销的主要技术之一。
TURTLEDOVE的全称直译出来就是“两个不相关的请求，然后是胜利的本地决策”。两个不相关的请求指的是一个以上下文进行定位的请求和另一个以兴趣组进行定位的请求。本地决策是指广告的竞价发生在浏览器本地而不是广告网络的服务器。
我们先说两个不相关的请求。
- 第一个上下文的请求非常好理解，页面的内容是什么，页面中的广告代码就会把这些信息通过SSP连接的广告网络发送到各DSP。浏览器收到返回的上下文广告出价信息。
- 第二个以兴趣组进行定位的请求才是关键。当用户先前访问了你的网站时，你的网站就可以调用Chrome的FLoC API给这个用户添加兴趣标签，同时授予广告网络查看该用户标签的权限。当具有这样标签的用户足够多之后，他们的浏览器就会定时去广告网络请求兴趣广告，而此时广告物料并不会被下载，只是收集一些出价信息和竞价逻辑再将它们缓存。这里的竞价逻辑包含了首位出价还是次位出价，最大展示数，上下文广告/兴趣广告偏好与优先级等规则。
由于这两个请求并不是同时发生的，因此可以规避时序攻击的风险。在TURTLEDOVE的初始版本中，到这里就可以开始最终竞价了。竞价的发生地就在用户的浏览器中，而不是广告网络的服务器中，这才叫本地决策！我们再来举个简化后实例：
- 张三访问了maxket.com。maxket.com标记了张三，并授予广告网络GGWL访问的权限。
- 由于maxket.com标记的访客超过1000（这个对匿名性至关重要），张三的浏览器请求该标记相关的广告，浏览器缓存广告和竞价逻辑。（请求一）
- 张三访问了example.com，查看一个“小海豹”的文章。该网站有广告网络GGWL的广告位。此时浏览器发送上下文“小海豹”的广告请求给GGWL。（请求二）
- GGWL返回最有竞争力的上下文广告信息给张三的浏览器。张三的浏览器中进行竞价，使用缓存后的竞价逻辑得出胜者。注：此处要记得缓存的广告并不止maxket.com标记的，还有可能有其他网站标记的广告也缓存着！
- 张三的浏览器下载广告物料并展现。
SPARROW
TURTLEDOVE看上去是一种不错的解决方案。之所以是“看上去”是因为它存在这样两个问题：
- 广告网络不知道具体谁（上下文广告）在和谁（兴趣广告）PK，因此无法做A/B测试优化竞价逻辑。
- 用户的浏览器需要下载更多数据并进行复杂运算。这对流量和电量是额外的考验。
于是2020年5月法国广告技术公司Criteo提出了一个新的提案——SPARROW，全称Secure Private Advertising Remotely Run On Webserver，译作“在Web服务器上远程运行的安全私有广告”。SPARROW要做的是将发生在用户侧的竞价搬到一个第三方服务器上。这个第三方服务器将是中立的、保密的、安全的，被称为Gatekeeper（看门人）。这样广告网络就不用把敏感的竞价逻辑每天几百万次发送到浏览器且这样做为手机设备省电省流量。
听上去很完美，但是SPARROW太过理想了，而且违背了TURTLEDOVE的一个重要原则——敏感信息不离开用户本地。SPARROW的方法对第三方服务器暴露了正在访问某内容的访客具有某一堆标签，这就不像只暴露某一个标签那样容易混在人群中。如果第三方服务器被黑，那么用户隐私依旧得不到保障。SPARROW的另一个问题是这样“出淤泥而不染”的广告公司几乎是不存在的，也就是说所谓的“中立”是“空谈”。SPARROW并不是一个可行性很强的方案，不过说它毫无价值还是有些武断，至少这只“麻雀”激发了谷歌的想象力。于是又有了
DOVEKEY
Dovekey就是用了Key的TURTLEDOVE，它并不是什么首字母缩写:-)。它将Gatekeeper服务器改作了一个“键值”服务器，也就是一个查询表。只要输入加密过的【上下文信号+兴趣组ID】（键）就能返回一个出价。而DSP和SSP将会持续更新键值表供查询。下图解释了这整个过程：
- 浏览器会按照TURTLEDOVE中的说明发送常规的上下文广告请求。
- SSP返回获胜的上下文广告，以及派生的上下文信号（分别来自SSP和DSP）。最终的上下文信号为来自DSP和SSP信号的串联。比如SSP分类为“菠萝”，DSP分类为“凤梨”，最终上下文信号即为“菠萝凤梨”。
- 浏览器通过组合上下文信号和兴趣组ID（ig_id）来构造键（Key），并将这些键在请求中发送给KV服务器。
- KV服务器返回与请求的键关联的所有出价。（*）
- 浏览器在从KV服务器获取的兴趣组候选人和获胜的上下文广告之间进行简单的竞价。（*）
- 如果上下文广告获胜，则浏览器可以继续呈现广告。
- 如果兴趣组广告获胜，浏览器可以向KV服务器发送另一个请求，以获取广告素材，或者可以通过兴趣组请求提前提取广告素材，如TURTLEDOVE提案中所述。
（*）假设KV服务器只能执行查找，则需要执行第4步和第5步。KV服务器也有可能进行最终竞价，在这种情况下，仅需要返回获胜的出价和广告素材。
Dovekey的好处是KV服务器并不知道这些键都是什么意思，只是一个“没有感情的机器”做着简单翻译工作，竞价还是会发生在浏览器本地。
当然Dovekey的问题依然存在。比如谁来托管KV服务器？谁有资格托管KV服务器？如何保证KV服务器供应商永葆“纯真”？Dovekey依旧牺牲了匿名性，只是对广告主而言隐身，KV服务器依旧“可以”跟踪用户，只要他们愿意对键进行分析。
FLEDGE
而事实就是这样，FLEDGE（雏鸟）出现了。FLEDGE全称为First “Locally-Executed Decision over Groups” Experiment，意为第一个“以小组进行本地执行决策”的实验。至此我们终于可以在Github上看到部署DOVEKEY的方法了。
简要总结一下并谈一下感想，目前我们看到的大多数的所谓第三方Cookie在互联网广告上的替代方案都是基于谷歌占六成市场的Chrome浏览器的。这整个事件的驱动力在于其他玩家包括Safari、Firefox的压力。但是毒苹果们忽略了一点，谷歌一旦开始发力建设自有广告Inventory，掌握了更多发布商资源，会更加恐怖，这将使整个互联网广告转变成谷歌一家独大的局面。谷歌有OS有Browser可以封闭着自己玩，其他家的广告在精准性上根本无法匹敌。真正需要第三方Cookie替代品的不是谷歌，而是盼着带头大哥来拯救的其他广告科技公司。放在国内，自己的操作系统自己的浏览器自己的内容媒体意味着什么无需极诣再明示了。
今年，极诣将继续关注广告科技和隐私政策之间的博弈，我们也会在不久讲下谷歌的隐私沙箱对归因分析的冲击。感谢读者厚爱！
