ITP 2.0和Google Parallel Tracking—这次Cookie真死了
极诣在上半年曾经介绍过苹果发布ITP（Intelligent Tracking Prevention）破坏广告业生态，也介绍了ITP的本质以及以谷歌为例的行业应对方法。
TL;DR
Cookie在Safari环境下快彻底废了。默哀吧。
从ITP 1.0说起
我们来回顾一下：
- ITP 1.0采用机器学习算法判定哪些域名是用于跟踪的域名
- ITP 1.0提供了24小时的Grace Period。在这24小时中，浏览器可以读取写在目前网页下的第三方Cookie的内容。
- ITP 1.0对广告业判定访客身份的影响巨大，但是对网站分析的影响较小。
- ITP 1.0并不会让你少看多少广告，反而是广告的相关性大幅下降。
- ITP 1.0会使网站为用户个性化定制内容受到影响从而使用户体验下降。
- 目前业内的网站分析工具和转化收集工具都采用将Cookie写为第一方Cookie来规避这个问题。
我们举个例子：当你访问maxket.com时，页面会调用百度统计的代码，该代码会检测百度用户登录状态并写入BaiduID在百度域的Cookie。这个叫第三方Cookie。
在Safari环境下，所有的第三方Cookie只能被写入该Cookie的网站和Cookie的域读取。也就是说如果另一网站也存在百度统计代码，该访问无法获取在maxket.com访问时写下的baidu.com域的Cookie。
如果你在苹果的Safari浏览器中ITP 1.0环境下，在24小时内，当你访问极诣网站时，你可以直接读取这个值。当你访问baidu.com时，你也可以读取访问maxket.com时写下的这个值。
如果24小时内未访问baidu.com，24小时以后，再访问极诣时，之前写入的BaiduID将无法被读出。30天后会被清除。
那么ITP 2.0又是什么？
当然是更“恶心”了。ITP 2.0简直“恶心”出了新境界。
24小时的窗口期不再
0到30日内要想读取你写下的第三方Cookie就必须通过Storage Access API来完成。
举个例子，访客是优酷的免广告付费会员。某天他在优酷登录了。一周后他在极诣的网站上看到了嵌入的优酷视频。为了了解该访客的身份，通常情况下会去检查优酷域下的登录状态来决定是不是免广告。但是在ITP 2.0环境下，浏览器并不知道用户许可在极诣网站访问时读取优酷域的Cookie。那么还得看广告。除非利用SA API来去广告。
调用SA API会出来这种样子弹窗，效果感人：
更为感人的是，访客在其他网站播放优酷的视频时还需要一遍又一遍地经历这个过程。
没用浏览器不算在30天内
这点很人性啊，如果访客在登录优酷后的34天，其中有5天没开机。那么还是算29天。所以那些Cookie数据不会被清空。
主域的界定
ITP 2.0使用eTLD+1来界定各方。也就是说www.maxket.com和blog.maxket.com是一个实体，他们之间互相调用Cookie不需要弹窗许可不在ITP 2.0限制对象里。而merklechina.com与merklechina.cn却是不同实体。
掐死ClickTracker
我们知道ClickTracker，一般是使用302跳转在各方记录下点击详情的方式。比如你在网站A点击了一个广告，链接指向网站B。网站B会记下点击的详细情况再跳转到网站C。网站C也记下点击的详情最后跳到落地页D。
宛如一股清流，不留下一点尘埃。ITP 2.0会使用机器学习识别B和C并让它们在这过程中写不了Cookie。
ITP 2.0还能识别各种Tracker之间的“串通”，所以当你们想通过各方对访客的片面理解来勾勒出访客全貌时，这些参与的Tracker会被“一窝端”。干得漂亮！
调戏Referer
ITP 2.0的另一改版是对于HTTP请求的referer字段的。
如果baidu.com被判定为跟踪域名（ITP的世界里可没有白名单），那么当极诣的页面（https://maxket.com/apple-safari-itp-3rd-party-cookie-gtag-js/）调用百度的js资源时，百度服务器接受到的请求就不会带有referer=”https://maxket.com/apple-safari-itp-3rd-party-cookie-gtag-js/”而仅仅会是referer=“https://maxket.com”。你或许只能靠参数显式地传递这些信息了。
Google Parallel Tracking（谷歌并行跟踪） – 谷歌的应对
为了应对这艰难的跟踪环境，谷歌推出了并行跟踪模式。该模式5月便作为可选特性启用，将于10月30日起强制实行。谷歌的官方文档称其将有助于更快速地加载着陆页，从而减少错失的访问。这可能会增加转化次数，并提高广告效果。”
并行跟踪有别于以往的基于302跳转的跟踪方式，它在将访客送去落地页的同时并发地通知各个跟踪方。也就是说以往SERP-TrackerA-Tracker-B-LP的模式会拆解为：SERP-TrackerA，SERP-TrackerB，SERP-LP。
以往模式中一旦A和B出现问题会导致点击无法到达LP。并行跟踪下，A、B和LP各自的到达率分别独立，没有依赖性。极诣认为这么做会让你的网站访问监测量更接近于点击数，从而提高我们关心的一个重要指标——到达率。
但这样做会让TrackerA和TrackerB失去新建Cookie的机会，不过这也是无奈之举。
并行跟踪使用了Navigator.sendBeacon()方法发送一小段数据给目标服务器。这么做有几点影响：
- 首先sendBeacon只允许HTTPS的跳转
- 其次sendBeacon并不运行跟踪页面的HTML，当然也不会运行JS
- 最后是跟踪方的第一方Cookie无法写入
从目前来看，桌面端的IE和移动端的Safari还未支持sendBeacon。希望在不远将来得到解决。
Cookie时代的终结
我们可以清晰地看到Cookie这个浏览器中最原始的少量数据客户端存储方式已经进入了暮年。在未来的几年中桌面端的用户标记会越来越困难，而移动端会越来越一来手机app的SDK抓取设备ID。像谷歌、Facebook、腾讯、阿里这样的超级平台由于第三方Cookie的限制在页端的投放精准性会受到影响。
Cookie功能的人为限制会造成以上一系列影响，这和Web发展向更多HTML5，PWA的趋势背道而驰（当然，苹果始终是坚守APP的桥头堡）。由于广告的精准性下降和随之带来的用户体验下降，我们仿佛又看到了一波GDPR，看到了一个个弹窗询问着“你同意我们使用Cookie吗？”
容我再去吐一会。
