Unified ID 2.0/UID2是什么？它是如何取代Cookie的？
对广告科技感兴趣的读者一定知道，2024年1月4日起，谷歌Chrome浏览器将测试1%的用户不再支持第三方Cookie。而在2024年三季度，谷歌将适时让全部Chrome浏览器都不再支持第三方Cookie。至此被长期诟病隐私安全的第三方Cookie将逐渐退出历史舞台。
第三方Cookie被应用的最多的场景是广告行业，广告网络通过第三方Cookie来标记每个受众个体，完成跨站追踪。因此每次谷歌对第三方Cookie的退出时间线进行调整都会引发广告科技公司估价的震荡。
广告当然不会因此而消失，只不过原先基于第三方Cookie进行定位的广告将会失去定位的能力。这意味着，网民可能会看到更多无关的广告。为了应对这一局面广告科技商和广告代理公司都在寻找并推动替代方案，其中The Trading Desk的Unified ID 2.0是其中较为知名的。
最近，一项针对UID2的测试体现了CPM比第三方Cookie的定位增加200%的结果。这意味着广告通过这种新的定位来进行投放将会更为精准，广告主也更愿意为此广告展现提高出价。
那么UID2是如何工作的呢？它是如何取代Cookie的？本篇马老师将详尽介绍。
UID2框架中的身份数据与各角色
UID2框架中的Identity身份数据包含了两种：UID2和UID2 Token
什么是UID2？
- UID2是框架中标记每个用户的唯一ID。
- 它是由字母和数字构成的字符串。
- UID2通过用户的email来生成。
- DSP，Data Provider，Advertiser能够获得UID2。
- UID2由Operator在email后面加上一个salt字符串并Hash后生成。
- salt字符串来自一百万个salt bucket中的一个，所以并不是每个email都是加上同一个salt字符串
- 由于salt字符串会由Administrator定期更改，当发生大规模UID2泄露时UID2会刷新。建议每天查看一次salt是否变化。
什么是UID2 Token
- UID2 Token是由UID2生成的令牌，它的生存期非常短暂
- 该令牌由Operator加密UID2后获得
- 同一个UID2，每次进入竞价系统都会使用不同的UID2 Token，这样Publisher，SSO供应商，SSP就不能拿到并收集UID2并建立人群包
- UID2 Token是存储在浏览器的Local Storage中类似于第一方Cookie
- 对于app或者CTV而言存储位置较为灵活，但需要每隔几分钟刷新确保用户没有opt out
- DSP会对UID2 Token进行解密，还原UID2并和Advertiser提供的UID2进行比对决定出价
上面也提到了UID2框架中包含了以下角色：
- Publisher-广告发布商
- SSO Provider-Single Sign-On供应商
- SSP-Supply Side Platform
- Advertiser-广告主
- DSP-Demand Side Platform
- Administrator-管理员
- Operator-操作员
- Data Provider-数据供应商，可以理解为DMP
- User-用户
下面再介绍一下UID2中的重点角色：
Administrator-管理员
- Administrator的职能是管理各方的接入
- 他会分发用于生成UID2的密钥salt给Operator
- 他会分发用于解密UID2 Token的密钥给DSP
- 如果用户想要取消退出opt out，他会通知Operator和DSP
Operator-操作员
- Operator操作运行生成与管理UID2和UID2 Token
- Operator会收到Admin给的加密密钥salt从email生成UID2
- Operator会运维用来调用的API使各方获得UID2或者UID2 Token
Publisher-广告发布商
- Publisher可以选择与已经接入服务的SSO Provider合作
- 对Publisher来说，首要任务是通过用户的email生成UID2 Token
- 首次生成UID2 Token后代表该用户opt in
- 之后Publisher就可以新生成UID2 Token通过SSP去参与竞价
- DSP通过SSP传来的UID2 Token会进行解密，解密为UID2，比对后决定是否出价并控制Frequency Capping
- 每次竞价后UID2 Token将会刷新
DSP-Demand Side Platform
- DSP的主要工作是解密UID2 Token通过UID2查看用户身份以及对接用户opt out
- 要想加入UID2网络，DSP必须在Administrator进行注册获得授权码authkey
- DSP使用的SDK会通知DSP用户的UID2 Token是否过期
- DSP需要每隔几分钟看一下解密密钥是否变化
User-用户
- 用户在进入Publisher网站时会有注册选项，目的是换取有价值的内容。
- 这样Publisher/SSO供应商便能拿到用户的email并通过Operator由email生成UID2 Token打通UID2竞价通道
- 在用户触发广告位后，Publisher通过Operator再度刷新UID2 Token后可以通过SSP通过传递到竞价系统。
- DSP拿到该UID2 Token后将进行解密，获得UID2后与Advertiser和Data Provider提供的UID2或者自己所有的UID2进行比对身份和频率来决定出价
- 这样User便可以获得一个广告展现，UID2 Token也进行刷新
- 当用户退出UID2后，便不会收到与其身份相关的广告
总结
从整体方案来看，UID2可以解决由第三方Cookie退出产生的身份缺失的问题。短暂将Token存储在Local Storage在未来跨各种浏览器的风险也较小，能让类似的解决方案存活下去并一直发挥作用。
但是马老师也不得不指出一些潜在的不完美之处：
- 首先是UID2依旧依赖用户进行登录，这意味着Publisher必须具有优秀的内容与用户进行个人隐私数据的交换。这会倒逼Publisher拿出更优质的内容也会让UID2的发展规模和速度受到压制。相对于Google的Topics的方案来说，Publisher如何说服用户愿意进行这种交换是取得UID2的关键。
- 其次是在整个技术框架中，Publisher需要频繁请求刷新UID2 Token，而DSP也需要反复对UID2 Token进行解密。前者加重了网络请求的负担，后者增加了计算的负担，最终可能影响到响应时间和效率。
- 第三是该解决方案需要一个中立的Administrator和有效且健壮的Operator，这对技术和安全上的要求很高，一旦发生问题可能造成整个网络的瘫痪。
- 最后是该解决方案依赖于以email作为主键的身份识别，在一些市场，如中国，主要以手机号作为主键，这会需要一些改良使得网络在email缺失的情况下依然起作用。
综上，UID2的框架和目前的接入状态是相当让人欣喜的，UID2带来的精准定位也让广告技术圈重获希望，其更高的收益让Publisher专注于更优质的内容让用户依旧享受到免费的价值交换。
UID2和类似的解决方案并非是第三方Cookie的完美替代，但随着行业的进步，我们应该拥抱那些能够促进互联网广告有序、健康、安全发展的新技术。希望这些方案能进一步改善，在解决用户隐私的前提下促进数字广告的快速发展。
