谷歌Chrome隱私沙盒下的轉化分析

這是HubSpot One的谷歌隱私沙盒系列文章的第三篇。對前兩篇感興趣的讀者請參考：

1. 《隱私沙盒與FLoC，後Cookie時代的精準行銷》
2. 《TURTLEDOVE、SPARROW、DOVEKEY、FLEDGE，你算什麼鳥？ 》

本篇HubSpot One講的轉化分析並不是廣告主自己通過類似GA的Web Analytics軟件進行分析的範疇，而是在廣告網絡側的。為什麼廣告網絡也需要轉化分析呢？在廣告網絡背後的廣告科技公司需要這些數據來定期調整投放策略，進行A/B測試，自動優化你的廣告投放效果，而廣告轉化數據是用來建模預測的輸入。

第三方Cookie下的轉化分析

以往我們依賴第三方Cookie來進行投放的轉化跟踪。廣告網絡在用戶點擊後甚至廣告展示後將記錄該用戶的廣告曝光點擊歷史，在用戶在廣告主網站上轉化之後會回溯該歷史進行轉化記錄和歸因。

第三方Cookie對廣告平台來說是該用戶的唯一標識，因此在第三方Cookie可用的時代，廣告平台可用較為準確地進行跨站跟踪每一個設備，並掌握使用設備的用戶的瀏覽歷史和興趣偏好。顯然，這會帶來許多用戶隱私的問題。

隱私沙盒下轉化分析

當第三方Cookie不再可用後，谷歌將提供Event Conversion Measurement API作為應對方案。該方案暫時將不支持View-through轉化，僅支持點擊。谷歌還配套提出了Aggregate Conversion Measurement API和Trust Tokens作為一攬子方案，涵蓋了深度分析洞察和反廣告欺詐。

注意上圖第二步的browser storage並不是第一方Cookie，第一方Cookie並不能跨域監測View-through轉化。正由於不在Cookie中，JavaScript無法輕易對其進行操作，保障了安全性的基礎，只能通過API對該存儲進行有限操作。而API的調用將會整合到HTML的Parser中，由瀏覽器來負責。因此使用window對象的window.open和window.location是不能用此API的，因為不是<a>標籤。舉個例子，之後的一個廣告會由這樣一段代碼構成：

<a id="ad" impressiondata="200400600" conversiondestination="https://advertiser.example" reportingorigin="https://adtech.example" impressionexpiry="864000000" href="https://advertiser.example/shoes07" target="_blank" > <img src="/images/shoe.jpg" alt="shoe" /> </a>

這個例子很直觀地展現了Event Conversion Measurement API通過定義了一堆<a>元素的屬性，當用戶點擊了這個廣告鏈接的時候，瀏覽器會記住這個點擊所關聯的屬性，而當用戶在conversiondestination（eTLD+1）轉化的時候，瀏覽器將記錄下來並在未來的某一時間（注意不是實時）反饋給reportingorigin。你看

1. 廣告網絡依舊可以用JavaScript記錄展現和點擊的發生，收集瀏覽器環境以及廣告發布媒體補充的其他一些數據。如果發生點擊，這些數據依舊可以通過掛載參數傳遞給廣告主網站並保存為第一方Cookie（注意：這種方法還是會被蘋果ITP打擊。）
2. 當用戶在廣告主網站完成轉化時，廣告主依舊可以查看第一方Cookie並將當時的展現情況反饋給廣告網絡。

我們很容易發現這樣做的優點。

• 首先，廣告網絡無法再跨域跟踪用戶了。因為不再有第三方Cookie。 （我們在此不討論瀏覽器指紋。）
• 其次，至少View-through轉化時，廣告網絡無法輕易將看廣告的人和轉化的人對應起來。我們說”輕易“是因為還有時序攻擊（Timing Attack）的可能。

時序攻擊我們在這裡簡單舉個例子，假設A用戶在一個在線文學網站點了動漫書籍廣告後，廣告網絡獲取了該行為訊息，一分鐘後同一IP地址購買了BL漫畫的轉化訊息也傳到了廣告網絡，那麼這兩者很有可能就是同一設備。這樣A用戶作為一個個體喜愛BL文化的偏好就暴露了。由於在線文學網站會分享A用戶的會員ID給廣告網絡，那麼A用戶該偏好訊息將會曝光給更多其他廣告主。不過A用戶在其他網站中的身份還不會和在線文學網站的A君聯繫起來，不至於太糟。

從上面這個A用戶的例子我們也能看到其他一些問題，由此Event Conversion Measurement API為了保護用戶隱私也給出了三個手段：

1. 限制傳送的數據字節數——除了回傳clickid，轉化數據最多3個bit，也就是8種轉化類型，這是避免給用戶打過細的標籤。
2. 添加噪音數據——干擾，不多解釋了。
3. 限制轉化數據回饋的時間間隔——有時會長達兩週，這是規避時序攻擊。

我們最後分析反饋轉化的過程，先看下圖：

這裡的第7步很關鍵。每次轉化pixel都會被調用，讓廣告網絡知道有一個轉化發生了。但為什麼是每次呢？因為不存在Cookie了呀！廣告主的網站如果不做”特殊處理“利用第一方Cookie來標記用戶看過的廣告，或者不針對某一廣告來源做特殊的轉化路徑來區別載入pixel，那麼它是不知道這個用戶的轉化是否該被歸因到某一個廣告的。因此每當有一個轉化行為發生時，就會有一個pixel傻傻地被調用。是不是非常不環保？而且會對廣告網絡暴露廣告主的商業數據？

而在第8步，廣告網絡僅僅需要返回一個轉化類型給瀏覽器，這就是我們剛才說的8種轉化類型之一。然後在第9步，瀏覽器對真正的點擊+轉化數據進行排期。

第10步在瀏覽器加上了歸因後的功勞值（Attribution Credit）然後回傳給廣告網絡，100代表全部歸功於這個點擊（注：當前僅支持Last-Click轉化模型！ ）。然後在過程的最後，廣告網絡將收到轉化報告。

你有沒有發現缺少些什麼？如果你想通過收入金額而不是轉化數來優化廣告行不行呢？很遺憾，你只能在八種轉化類型中想辦法。因為傳輸金額就會造成人為利用金額對個體進行細分標籤的後果。

好的，我們通過三篇文章把谷歌Chrome的隱私沙盒粗淺地講了一遍。如果讀者有疑問，請在HubSpot One公眾號相應文章下留言。