“萬眾矚目”的iOS14（macOS, iOS, iPadOS）終於發布了，隨著大量蘋果設備更新到最新版的操作系統有哪些數字行銷者必須了解的變化？HubSpot One將以此篇為讀者劃一下重點。如果技術背景缺失閱讀困難可直接跳到文末。好了，不廢話，我們直接切入主題。
Browser端比App端先受影響
iOS14中原先的UIWebView類將強制要求升級到WKWebView，“Allow Cross-Website Tracking”（允許跨站跟踪）這個新設置被默認關閉。這個變化意味著原來僅Safari瀏覽器受影響的各種限制將會擴散到其他瀏覽器，包括iOS下的Chrome和其他套皮膚的瀏覽器。至此，所有iOS下的瀏覽器都將受到ITP的影響。
App端比較幸運，由於Facebook等廣告網絡和內容髮布者網絡的壓力，蘋果推遲了閹割IDFA的計劃到明年。所以業界會珍惜這寶貴的三個月尋求並部署替代計劃。
隱私報告和ITP
Safari瀏覽器中將會提供Privacy Report，點擊網址前的小盾牌可查看。這裡應用了DuckDuckGo的Tracker Radar顯示哪些你所接觸過的具有跟踪能力的域名。注意，這些域名只是起“告知”作用，和ITP不同。 ITP是根據這些域名實際的行為來判斷是否限制的。 Tracker Radar中包含的域名和ITP中包含的域名有重疊，但沒有誰包含誰。請注意區別。
第三方Cookie之死
第三方Cookie至此在蘋果生態中涼透了。觸髮用戶主動開啟，任何第三方Cookie將不被支持。
第一方Cookie的限制
用JS寫的第一方Cookie，如GA寫的，將只能存在7天。
另外，注意，如果訪客從一個帶有跟踪能力的域名，如baidu.com訪問你的網站https://yoursite.com/page.htm ，且來的這個你的頁面含有參數?或標識片段#，如https://yoursite.com/page.htm?utm_source=cpc ，那麼任何該頁面中用JS寫入的第一方Cookie，如GA寫的，將只能存在24小時。這會嚴重影響廣告轉化的數據，隔天轉化將可能無法被歸因！
本地存儲localStorage
由於蘋果深知localStorage將會被用作第三方Cookie的替代方案，因此對localStorage也加以限制。你可以在cookiestatus.com查閱具體限制，由於比較複雜，本篇不介紹。
Referrer限制
對Referrer的限製或許是ITP中除了對Cookie的限制之外最大的挑戰。簡單來說跨站的訪問中將默認強制（意思是這是它的底線，你無法關閉或用更寬鬆的政策覆蓋它）採用origin的政策（Referrer Policy）。舉個例子，從https://hubspot.one/ios14-tracking-and-analytics/的一個鏈接瀏覽https://yoursite.com/page.htm時，瀏覽器會在HTTP請求中添加referer字段。過去這個字段是完整的URL，即https://hubspot.one/ios14-tracking-and-analytics/ ，而現在，由於是跨站訪問，將只提供scheme和host name（還有port）訊息，即https://hubspot.one/ 。
由此帶來的影響是，像GA這樣的網站分析工具中查看引薦流量時，將無法查看具體是對方哪個頁面產生的流量。這相當於自動應用了strict-origin-when-cross-site的Referrer Policy。
strict-origin-when-cross-site？
熟悉Referrer Policy的同學可能發現Referrer Policy中根本沒有strict-origin-when-cross-site ，而只有strict-origin-when-cross-origin 。那麼strict-origin-when-cross-site究竟是什麼呢？它是Simo Ahava造出的用以描述ITP的這種行為的。為了讓讀者了解Cross Site與Cross Origin的區別，HubSpot One覺得有必要藉此機會詳細地講一下。首先是Referrer Policy，HubSpot One曾經多次提到referer，那麼這究竟是什麼？前方套娃預警！
Referrer Policy是什麼？
Referrer-Policy是在HTTP響應中的一個字段（你也可以在HTML中對特定鏈接進行指引），它向瀏覽器指示了該頁麵點到下一個頁面時，在HTTP請求中Referer字段該如何表示。它可以有這些值：
- Referrer-Policy: no-referrer
- Referrer-Policy: no-referrer-when-downgrade
- Referrer-Policy: origin
- Referrer-Policy: origin-when-cross-origin
- Referrer-Policy: same-origin
- Referrer-Policy: strict-origin
- Referrer-Policy: strict-origin-when-cross-origin
- Referrer-Policy: unsafe-url
這些值的具體定義請查看Mozilla的參考文檔。
上圖中Google就使用了unsafe-url作為Policy，這樣要是後面是跨站或者非安全的網址依然可以將完整的referer傳遞過去。注意：在Chrome和Chromium 85以後如果你不指定Referrer Policy，瀏覽器將默認使用strict-origin-when-cross-origin 。因此Google必須進行unsafe-url的設置。但是對於蘋果ITP，設置unsafe-url並不能使strict-origin-when-cross-site無效，這就是我們上面說的默認強制。
Cross Site和Cross Origin
Cross Site和Cross Origin是相對於Same Site和Same Origin來講的。我們先講Cross Origin和Same Origin。
一個Origin包含了三個部分https:// www. hubspot.one :443
它們分別為Scheme ， Host Name和Port 。這裡Port經常省去，443通常表示SSL安全（https://）默認端口，80為非安全的（http://）默認端口。
當上面三者任意一個不匹配時，我們稱為Cross Origin。前後Scheme與Port很容易理解，那什麼時候Host Name才匹配呢？我們又要引入TLD，eTLD，eTLD+1的概念！
TLD，eTLD，eTLD+1
TLD是Top-Level Domain的縮寫，如.com，.cn，.jp，.us，.uk，.io。
由於互聯網的發展一些國家和組織又在自己控制的TLD上發展了下一級TLD，如.com.cn，.co.jp，.co.uk，.github.io。你看原來一個品牌只要買一個brand.cn的，這下還不得不買個brand.com.cn，這麼高級的賺錢方法真虧他們想得出來。 （此處應有掌聲）於是人們把這些不是TLD又和TLD差不多的叫作eTLD 。 e就是effective 的意思。
順便說一下ccTLD是指country-code TLD，如.cn這樣以國家兩字代碼結尾的域名，gTLD是global TLD的意思，如.com，.net，主要用於SEO。
好了，你們只要記住，不管是TLD還是eTLD都是市面上買不到的。也用不了。我們能用的最短的域名就是eTLD+1 。也就是說，hubspot.one也好，t.cn也好，t.co也好都是eTLD+1。
了解了eTLD+1我們就可以理解Host Name判定Same Origin的標準——eTLD+1相同。因此www.hubspot.one、www2.hubspot.one和hubspot.one三者的eTLD+1相同；www.baidu.com，baidu.com，e.baidu.com，tongji.baidu.com，ziyuan.baidu.com這五個Host Names的eTLD+1相同。因此這兩組如果Scheme與Port相同的話會判定為Same Origin。所以舉例
判定Same Origin還是Cross Origin
- http:// baidu.com與https:// www.baidu.com是cross origin。 Scheme不同。
- https:// baidu.com :80與https:// www.baidu.com :443是cross origin。 Port不同。
- https:// hubspot.one與https:// baidu.com是cross origin。 Host Name的eTLD+1不同。
- https:// hubspot.one與https:// www.hubspot.one是same origin。 Scheme相同，Host Name的eTLD+1相同，Port隱含為443相同。
- http:// hubspot.one與http:// hubspot.one :80是same origin。 Scheme相同，Host Name的eTLD+1相同，Port隱含為80相同。
然後我們再來講Cross Site和Same Site。
Cross Site和Same Site
非常簡單，只要Host Name相同，不管Scheme和Port是否相同，都是Same Site。反之，為Cross Site 。因此比較Same Origin在Scheme和Port上有所放寬，但是僅僅是eTLD+1相同就不行了， Same Site必須域名完全一致。
在Chrome的DevTools裡，我們可以查看Request Headers裡的sec-fetch-site字段。該字段會包含下面四個值之一：
- cross-site
- same-site
- same-origin
- none
這樣我們可以快速進行驗證。
strict-origin-when-cross-site的意義
我們解釋了Cross Origin和Cross Site就可以理解strict-origin-when-cross-site的意義，它必須是嚴格的域名完全一致，當不一致時Referer中只傳遞Origin而不包含具體哪個頁面（Path） 。
因此，當用戶從Google資源平台（ziyuan.baidu.com）點擊到Google統計（tongji.baidu.com）時，只要它們都是https://的安全頁面，按照strict-origin-when-cross-origin的Policy並不會受到影響，而蘋果ITP中的新政策strict-origin-when-cross-site將會對其產生影響。 Google統計並不會知道是資源平台哪個頁麵點擊過來的。再強調一遍，這是默認強制的。
更有甚者，如果baidu.com被判定為跟踪域名（條件一），並且源網頁帶參數（條件二），兩個條件同時滿足，那麼目標網頁獲得的referer會是原網頁的加工為eTLD+1的Origin。舉個例子，當我在https:// ziyuan.baidu.com /keywords/index?site=https://hubspot.one/上點了一個到https:// tongji.baidu.com/的鏈接時，tongji.baidu.com僅能獲得https:// baidu.com/作為Referer。
總結一下
iOS14的更新使我們擔心已久的事終於變成了現實，在未來是否會有各種瀏覽器指紋各種防封殺的新方法我們還不得而知。在蘋果生態中Web端/Browser端有三點重要影響。
- 第三方Cookie已經成為歷史，廣告平台無法有效地對受眾進行標記和跨站跟踪。
- 如GA那樣部署的第三方分析軟件中用JS生成的第一方Cookie的生存期大幅減少。
- 包括引用來源在內的大量的跨站統計分析的數據丟失，可能造成部分網站功能上出錯。
本文參考了Simo Ahava的《Intelligent Tracking Prevention In iOS 14, iPadOS 14, And Safari 14》並略作梳理和註解。如果有錯誤之處或解釋不夠之處，請多包涵並在HubSpot One的公眾號文章留言。