HubSpot One上篇介紹了谷歌的FLoC。它按照分組（cohort）原則方法將單個用戶隱藏在上千具有相同特性的用戶之後，由此達到隱私保護的目的。我們認為FLoC並不能代替第三方Cookie，因為第三方Cookie不僅僅是用於跨域跟踪用戶，還有其他諸如第三方登錄等作用。並且FLoC僅僅基於Chrome瀏覽器，縱然其占有六成以上的市場份額，依舊有很大一部分處於其他瀏覽器設備上。
谷歌不情願地告別第三方Cookie會為其賺得美名的同時，也會被反信任問題困擾。當FLoC成為一個黑盒子，同時其他廣告技術公司又無法通過瀏覽器級別的技術與之抗衡時，帶來的必定是壟斷。
好了，上回我們講完FLoC留了一個引子，講了點TURTLEDOVE。這是怎麼回事呢？我們接著講。
TURTLEDOVE
TURTLEDOVE被看作在失去第三方Cookie後Chrome環境下的精准定位方式。遺憾的是它依舊不是基於個體的。僅在人群達到一定規模之後才生效，以滿足隱私保護的需要。 TURTLEDOVE被看作未來服務於Chrome環境下的再行銷的主要技術之一。
TURTLEDOVE的全稱直譯出來就是“兩個不相關的請求，然後是勝利的本地決策”。兩個不相關的請求指的是一個以上下文進行定位的請求和另一個以興趣組進行定位的請求。本地決策是指廣告的競價發生在瀏覽器本地而不是廣告網絡的服務器。
我們先說兩個不相關的請求。
- 第一個上下文的請求非常好理解，頁面的內容是什麼，頁面中的廣告代碼就會把這些訊息通過SSP連接的廣告網絡發送到各DSP。瀏覽器收到返回的上下文廣告出價訊息。
- 第二個以興趣組進行定位的請求才是關鍵。當用戶先前訪問了你的網站時，你的網站就可以調用Chrome的FLoC API給這個用戶添加興趣標籤，同時授予廣告網絡查看該用戶標籤的權限。當具有這樣標籤的用戶足夠多之後，他們的瀏覽器就會定時去廣告網絡請求興趣廣告，而此時廣告物料並不會被下載，只是收集一些出價訊息和競價邏輯再將它們緩存。這裡的競價邏輯包含了首位出價還是次位出價，最大展示數，上下文廣告/興趣廣告偏好與優先級等規則。
由於這兩個請求並不是同時發生的，因此可以規避時序攻擊的風險。在TURTLEDOVE的初始版本中，到這裡就可以開始最終競價了。競價的發生地就在用戶的瀏覽器中，而不是廣告網絡的服務器中，這才叫本地決策！我們再來舉個簡化後實例：
- 張三訪問了hubspot.one。 hubspot.one標記了張三，並授予廣告網絡GGWL訪問的權限。
- 由於hubspot.one標記的訪客超過1000（這個對匿名性至關重要），張三的瀏覽器請求該標記相關的廣告，瀏覽器緩存廣告和競價邏輯。 （請求一）
- 張三訪問了example.com，查看一個“小海豹”的文章。該網站有廣告網絡GGWL的廣告位。此時瀏覽器發送上下文“小海豹”的廣告請求給GGWL。 （請求二）
- GGWL返回最有競爭力的上下文廣告訊息給張三的瀏覽器。張三的瀏覽器中進行競價，使用緩存後的競價邏輯得出勝者。注：此處要記得緩存的廣告並不止hubspot.one標記的，還有可能有其他網站標記的廣告也緩存著！
- 張三的瀏覽器下載廣告物料並展現。
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替代品的不是谷歌，而是盼著帶頭大哥來拯救的其他廣告科技公司。放在國內，自己的操作系統自己的瀏覽器自己的內容媒體意味著什麼無需HubSpot One再明示了。
今年，HubSpot One將繼續關注廣告科技和隱私政策之間的博弈，我們也會在不久講下谷歌的隱私沙箱對歸因分析的衝擊。感謝讀者厚愛！