當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

「后隐私」时代，个性化广告如何保护隐私？

發布時間：2024/1/18 编程问答 36 豆豆

生活随笔收集整理的這篇文章主要介紹了「后隐私」时代，个性化广告如何保护隐私？小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

總覽

在廣告領域，「個性化」和「隱私」似乎是天平的兩端：個性化做的很好的廣告，通常都要收集很多用戶數據，對用戶畫像有清晰的認識；而如果將用戶數據都屏蔽掉，個性化的廣告很難取得效果。

隨著 Apple 公司發布 iOS 14，隱私問題也越來越受到大家關注，隱私保護越來越受到重視。在這種背景下，我們要做的是「乘勢而為」，本文就「后隱私」時代，個性化廣告該何去何從進行討論。從技術角度分析，內容包括：

分析個性化廣告和隱私的關系（原理）；

隱私問題的本質

如何保護隱私

Web 間

App 間

在隱私保護的情況下，個性化廣告有哪些出路。

目前各大廠商的思路

Apple: SKAN/PCM

Google: Privacy Sandbox (FLoC)

Facebook: AEM

第一方落地頁

廣告和隱私的關系

廣告并不是一開始就和隱私有關系的，而是隨著時代的發展，廣告平臺對于變現效率不斷提出了更高的要求，云計算、大數據、機器學習等前沿技術的應用也越來越多，對于數據的收集、運算和應用的規模也在逐步地擴大。我們把廣告精準性的深入程度由淺入深的劃分了幾個階段：

（圖片來源：人人都是產品經理^[1]）

通過媒介定向

這是傳統媒體階段，通過 媒體屬性的差異 來定向的投放廣告，比如體育頻道的受眾更多是體育愛好者、北京西二旗地鐵站的廣告受眾更多的是互聯網公司的從業者、海淀黃莊地鐵站的受眾則是課外輔導班的家長們。

通過內容定向

2000 年左右的第一波互聯網浪潮，最早的門戶網站比如新浪、搜狐上線，計費模式比較多的是 CPT 或者 GD 廣告。以 內容為意圖的 定向精準度相比于線下媒體更高了一些，比如小說頻道和綜藝頻道的瀏覽者是不同的。

通過意圖定向

隨著 Google 和百度搜索上線，以 搜索意圖 為廣告定向相比于以內容定向要精準得多了，計費模式更多的是 CPC 或者 CPM。當然這些就更多的依賴了用戶信息的收集（搜索內容、歷史、相關性）等。

通過用戶畫像定向

當依賴于推薦引擎的信息流產品如今日頭條、抖音上線，用戶的偏好很大程度上決定了內容，這些產品通過各個渠道收集到的數據形成的 用戶畫像，再基于用戶畫像進行內容和廣告的推送。計費模式多為 oCPX 或者 CPA。

隨著對定向精準程度的逐步提升，廣告對于用戶數據的收集、計算和應用的程度也越來越高。用戶隱私問題也越來越多地進入到用戶視線中。

根本問題是什么？

從技術角度看，最根本的問題是用戶標識，即 User ID。

為什么呢？因為一切數據、偏好的基礎背后都是用戶，我們需要根據一個 User ID 來「唯一」定義一名用戶。

聽起來「唯一」定義一名用戶，比較簡單，但是在沒有登錄的情況下，如何唯一的定義一名用戶呢？

PC 時代

在 PC 的時代，前端意義上「唯一定義一名用戶」是一個非常有意思的話題，即問題為：如何生成一個唯一的 User ID？

如果了解前端庫如 fingerprintjs^[2]，你就會知道為了在前端生成碰撞率極低的指紋（User ID），用了多少用戶維度的信息，比如 UserAgent、IP 地址、安裝的字體、Canvas、安裝的插件等等。

https://juejin.cn/post/6844903617510506504

移動時代

到了移動時代，除了 Web 之外，我們還多了 App 形態。在 Web 時代，前端能獲取到的信息十分有限，而 App 則直接可以和系統甚至硬件進行交互，獲取到的信息就多得多了。移動時代的 Android 和 iOS 系統甚至分別提供了唯一的設備標識符，都不用自己生成。

Android 可以使用 Android ID，iOS 則從 MAC 升級到 UDID 再到 IDFA，當然隨著 iOS 14 的逐步覆蓋提升，IDFA 獲取到的難度大大增加（后文會解釋）。

（圖片來源：知乎^[3]）

有了 User ID 之后呢？

有了唯一的 User ID 之后，能做的事情就太多了：

單主體

Web 上：在同一家主體的網站中，用戶即使不登錄，也能很容易被持續跟蹤。從技術角度看，只要生成了 User ID 后，將其保存至 cookie 中，隨后所有和后端的交互，瀏覽器都會自動帶上這個 cookie，后端根據 cookie 解出 User ID 后，那么這個用戶訪問過哪些頁面、點擊過哪些元素都可以被記錄下來了。即使用戶清除了 cookie，再次進入該網站時，由于生成的算法不變，那么 User ID 也是唯一的。

App 上：這個就更簡單了，用戶在打開 App 的那一刻開始，所有的行為，只要該 App 想記錄，那么都可以被記錄下來。

多主體

當然，如果到此為止，隱私問題倒還好，畢竟屬于同一家主體，你去使用別人的服務，做了些什么事情、偏好什么的，別人自然最清楚不過了。

但是，在 Web 上，如果存在一個第三方主體，將其腳本置入到其他的主體的域下，使用同一個 User ID，保存在 cookie 中，那么這個第三方主體就可以獲取到用戶在其他主體下的所有的活動數據，這就給用戶隱私保護帶來很大的挑戰。

在 App 上，由于可以很方便的獲取到統一的 User ID，那么就可以跨 App 進行追蹤了，甚至比 Web 還要方便。

顯然，風險最高的就是跨主體的進行 User ID 共享，特別是在未獲得用戶授權甚至用戶無感知的情況下。

如何保護用戶隱私？

既然風險最高的是跨主體的 User ID 共享，那么防范的主要途徑有兩個：

User ID：變得難以獲取；

共享：禁止跨主體的數據共享或匹配；

按照這兩條指導原則，我們在 Web 和 App 分別來看看如何實現？

Web 間

讓 user ID 難以獲取

如上文所說，User ID （即瀏覽器指紋）的生成依賴瀏覽器或者其他可采集到的設備信息，利用的就是這些信息的不可變性，而隨著隱私保護的理念逐步深入人心，主流的瀏覽器廠商都將「指紋保護」納入到了瀏覽器隱私保護范圍內。

比如：使用 Canvas 繪制圖像，并轉為 base64 的做法來做，由于每臺機器的硬件性能、屏幕顯示的不同，導致了這種方法很容易成為生成指紋的重要信息來源。比較常見的反制策略，在繪制 Canvas 圖形的時候，加上一些隨機的噪聲數據，就讓生成的信息就變得不唯一了。

這一技術在 Safari 和 Firefox 已經率先實現，如訪問 Fingerprint 的 DEMO^[4] 地址，我們對比一下 Safari 的普通模式和隱私模式的指紋。

Safari

（左：普通模式，右：隱私模式，Safari 版本 14.0.3）

可以看到，左右兩個是不同的。另外，在測試過程中，刷新頁面，生成的指紋還會發生變化（可能是 Safari 內部的機制），詳見 Apple Safari 2019 隱私安全白皮書^[5]。

Firefox

（左：普通模式，右：隱私模式，Firefox 87.0 (64 位)）

可以看出，左右兩個是相同的，受限于 Firefox 的指紋檢測模式（是通過該網頁是否有和主流的提供 Fingerprint 服務的域名有通信，從而進行攔截，該項服務由 Disconnect^[6] 提供），詳見 Firefox 72 的發布說明^[7]

Chrome

（左：普通模式，右：隱私模式，Chrome 版本 89.0.4389.90（正式版本））

可以看出，左右兩個是相同的，目前還沒有找到 Chrome 太多的關于指紋保護的公開資料，更多的是一些 Chrome 插件提供的能力。

禁止跨主體的數據共享或匹配

對于 Web 來說，「禁止跨主體的數據共享或者匹配」所依賴的載體就是 Cookie 了，準確來說，應該是第三方 Cookie。基本原理如下圖：

圖中綠色背景的 Cookie 為第三方 Cookie，即 第三方腳本在主體網站上設置的 Cookie，這些 Cookie 可以由第三方控制，并且在發往第三方的簡單請求時，會自動攜帶。在實際的情況下，處于各種各樣目的用于跟蹤用戶的第三方腳本，在某些網站上甚至多達一百多條。

很顯然，我們的保護手段是：禁止第三方 Cookie 的傳輸。

第三方 Cookie 對于隱私保護方面的風險大家的認同基本是一致的，這一做法在主流瀏覽器上在不同程度上已經逐步得以實現，小眾的瀏覽器如 Tor 瀏覽器^[8]、Brave 瀏覽器^[9] 早已實現了這一舉措，主流瀏覽器的情況如下：

Safari

2020.3.24 發布：在 iOS/iPadOS 13.4 和 Safari 13.1 版本之后，默認阻止第三方 Cookie 的傳輸^[10]。

Firefox

2019.9.3 發布：在 Firefox 69.0 版本之后，默認阻止第三方 Cookie 的傳輸^[11]。

Chrome

Chrome 在阻止第三方 Cookie 傳輸方面的動作就要謹慎的多，為了逐步實現阻止第三方 Cookie 的目標：

2016.5.25 發布：Chrome 51 開始，Cookie 增加一個新的屬性：samesite，該屬性有三個從低到高的值：None、Lax、Strict，默認值為 None，詳見 MDN^[12]。

針對第三方 URL 的影響舉例如下：

2020.1.14 發布：將在 2022 年徹底阻止第三方 Cookie 的傳輸^[13]。
2020.2 發布：Chrome 80 開始，samesite 的默認值由 None 升級為 Lax，并且要求如果強行設置 Cookie 的 samesite=None，那么必須同時設置一個 Secure屬性（即該 Cookie 必須由 HTTPS 協議傳輸）；
2020.4.3 發布：受 COVID-19 的影響，上一條的變更被回滾^[14]；
2020.7.14 發布：Chrome 84 開始，重新上線回滾的變更；
...
未完待續：關于 samesite 的進展和更詳細的時間線，可以查看官方網站的說明^[15]。

從這個時間線和預期來看，未來 samesite 的默認值會再次升級為 Strict，這也是最終目標（和 Safari、Firefox 一樣），時間點預期是 2022 年，前后可以看出阻止第三方 Cookie 的傳輸，持續 6 年左右。

App 間

讓 User ID 難以獲取

iOS

當前，「最有名」的讓 User ID 難以獲取的政策莫過于 Apple 公司的 iOS 14 新政了，讓我們來看下整體的時間線：

iOS 5 及之前，可以獲取到 UDID

2012.9：iOS 6 發布，新增了 Identifier for Advertising (IDFA)

2013.5：禁止獲取 UDID 的 App 上架（合規要求）；

2013.9：iOS7 發布，禁止獲取 MAC/UDID，IDFA 可以被重置（設置 -> 隱私 -> 廣告 -> 還原廣告標示符），重置后重新生成新的 IDFA，限制廣告跟蹤的開關默認是關閉狀態；

（圖片來源：知乎^[16]）

2016.9：iOS 10 發布，「還原廣告標示符」會將 IDFA 重置為一串無意義的 0，限制廣告跟蹤的開關默認仍然是關閉狀態；

2020.6：Apple 公司宣布將在 iOS 14 中引入新的隱私保護政策框架^[17] --- App Tracking Transparency^[18] (ATT)，在新規之下，限制廣告跟蹤的開關默認是開啟的，如果 App 需要跨應用跟蹤用戶，需要彈出申請彈窗，并且在用戶點擊允許之后，才能拿到 IDFA（可以猜想，看到彈窗的用戶大概率是不會允許的）。

（圖片來源：Apple 開發者官網）

因為此舉會給整個移動互聯網廣告行業帶來巨大的影響（下文會講到），加上全球新冠肺炎疫情蔓延的影響，ATT 并沒有在 2020.9 伴隨 iOS 14 一起發布，而是一直在推遲，終于在 2021.4.26，Apple 公司發布上 iOS 14.5 集成了這一功能。

縱觀整個時間線，從 2012 年至今，Apple 公司對于隱私保護政策的傾向是越來越嚴格的，讓唯一的 User ID 越來越難以獲取到，甚至獲取不到。

Android

相比于 iOS，Android 對于 User ID 標識的獲取的限制就溫和得多。據彭博社報道^[19]：

Google 正在研究和跟進 ATT，并且探索替代方案。其解決方案大概率沒有那么嚴格，也不會需要彈出彈窗來獲取用戶許可，這些探索都處于早期，并沒有決定是否跟進或者何時跟進。

圍繞 Android 類似解決方案的討論顯示，這一替代方案很可能會像 Chrome 限制第三方 Cookie 那樣，逐步地進行限制。

綜上，Android 上的 User ID 及相關隱私保護政策，短期內沒有明確的時間表。

禁止跨主體的數據共享或匹配

iOS

在第一點其實已經講過了，ATT 政策除了限制 IDFA 的獲取之外，還禁止了跨 App 的數據共享和匹配。

Android

同上，相關政策目前沒有明確的時間表。

政府機構

除了各大廠商提供了一些隱私保護措施，政府或機構也先后制定并出臺了一些是隱私保護的法律法規。

General Data Protection Regulation (GDPR^[20])

GDPR 的主要目標是個人對于個人數據的控制，以及為了國際商務而簡化在歐盟內的統一規范。用戶可以直接感知到的解釋是：以上提到的無論是 User ID 的生成、儲存甚至跨主體共享，用戶都是不知情或者即使知情也無法拒絕的。GDPR 就是希望將這個控制權「拿」回來。

一個很明顯的變化是，在 GDPR 生效后，很多網站會在頁面中披露隱私政策以及 Cookie 技術的使用情況（如上圖所示），告訴用戶：

個人數據的用途、保留時間以及是否和第三方共享

如何停止跟蹤

如何訪問、管理、更新和刪除個人數據

GDPR 法規已于 2018 年 5 月 25 日開始實施，詳細可以參見維基百科^[21] 的詞條解釋。

California Consumer Privacy Act (CCPA^[22])

CCPA 的條款基本內容和設立目的和 GDPR 基本相同，他們區別點在于關于個人數據的定義、每種信息的內容范圍和地域范圍、個人信息銷售的選擇權等。

CCPA 于 2020 年 1 月 1 日開始實施，詳細可以參見維基百科^[23] 的詞條解釋。

附：在調研過程中，發現了能提高合規改造效率的工具：__CookieBot^[24]

個性化廣告會面臨哪些困難？

隱私保護政策整體收緊的情況下，會對廣告行業的轉化歸因、用戶畫像、程序化交易等產生普遍影響，這里我們討論最重要的即 轉化歸因。

轉化歸因是什么？

用通俗的話來說，就是「本次轉化是由于哪個媒體的哪個位置哪次的 show/click 引起的」。轉化歸因對于廣告系統是非常重要的，因為它和廣告計費、廣告定向是息息相關的。

上圖抽象了用戶 123 從 A 主體到 B 主體之后，發生轉化的過程（當然實際過程要比圖中復雜得多）。圖中的歸因服務可以由 A 主體提供，也可以由第三方提供。B 主體上報信息可以通過埋入來自 A 主體的 SDK 實現，也可以由 B 主體自己上報。

從圖中可以看到，關鍵點在于歸因服務，需要拿到來自 A 主體和 B 主體，根據 User ID 進行匹配。但是如果按照用戶隱私保護政策：讓 User ID 難以獲取并且禁止跨主體的數據共享或匹配 進行處理的話，來自 B 主體的上報鏈路就必須斷開，這對于廣告的轉化歸因來說，簡直是災難。

此外，一般在歸因服務完成后，我們可以依據 User ID 對于該廣告的興趣特征進入到廣告競價模型中，實時地做反饋，優化模型預估 eCPM 的準確性，進而做廣告重定向、給相似用戶推送相似的廣告等。這些工作，在用戶隱私保護政策下，都做不了了。

當前有哪些解決方案？

隱私保護和個性化是天平的兩端，整個行業都在兩者間尋求平衡，看能否做到保護用戶隱私的情況下，給用戶提供個性化廣告。如果完全按照上文的做法實施，隱私保護政策對于個性化廣告的打擊是「毀滅性」的。好在各大廠商在推出隱私保護政策的同時，大多也會提供合規的解決方案，而其中又存在著廠商之間的角力和博弈，下面就介紹一些常見的轉化歸因和模型定向的解決方案，轉化歸因從場景分為 Web-to-Web、App-to-Web、App-to-App：

Web-to-Web：從網頁跳轉至網頁的場景（多見于 PC 端廣告）；
App-to-Web：從 App 跳轉至網頁的場景（這是比較常見的第三方落地頁廣告，如從抖音 feed 流打開廣告主的落地頁）；
App-to-App：從 App 跳轉至 App 的場景（這是比較常見的應用下載廣告，如從抖音 feed 流點擊調起 App Store，下載后，進入目的 App）

Private Click Measurement (PCM^[25])

PCM 是 Apple 在 2021 年 2 月 1 日發布的，將會集成在 iOS/iPadOS 14.5 中。主要解決的是 MacOS、iOS、iPadOS 系統中 Web-to-Web 和 App-to-Web 場景下的廣告歸因問題。原理如下：

Web-to-Web

之前：

（圖片重繪自 Webkit 博客^[26]）

如之前的分析，在隱私保護的情況下，首先 User ID 難以獲取，再就是跨站的數據共享也是不可實現的。我們看 PCM 是如何解決問題：

（圖片重繪自 Webkit 博客^[27]）

在 <a> 標簽增加兩個屬性：attributionsourceid 和 attributeon

attributionsourceid：8-bit 的源 ID，即 0 - 255 共 256 個，在廣告中，通常都是指 campaign_id，表明是從屬于哪個廣告計劃；

解讀：

既然是用于歸因的，為什么名字不起成 campaign_id？

答：因為 PCM 從技術上并不是和廣告緊密相關，所以起了一個比較中性的名字 source_id。

限制 8-bit = 256 個總數是為了什么？

答：為了限制同一個 A 主體下，進行跨站追蹤的最大廣告計劃個數，即 256 個。

attributionon：接下來要進行歸因的目標網站域名，只支持可注冊的域名或者 eTLD + 1（通俗來講就是合法的可注冊域名）。

解讀：

attributionon 是什么？

答：要跳轉目的網站的域名，這里有個名詞叫 eTLD + 1，eTLD= effective Top Level Domain，不同于 TLD 即 .com, .cn 等，eTLD 是有效的 TLD，如 .com.cn, .edu.cn, Mozilla 維護了一個 Public Suffix List^[28] (PSL) 。

這里的 eTLD + 1，是更準確的說法。比如我的 Github 項目 color-picker 的主頁地址：https://zhangbobell.github.io/color-picker/，由于 github.io 是一個 eTLD，所以如果跳轉的目的網頁是上面的地址的話，attributionon="https://zhangbobell.github.io"。

還有一些非常有意思的 eTLD，如 s3.eu-west-2.amazonaws.com, pvt.k12.ma.us，他們都是可以被 eTLD + 1 的，如果有興趣翻看 PSL 官網的話，可以發現「瀏覽器地址欄如何判定你是在搜索，還是在進入一個網站？」這個判斷就是基于這個維護的列表，其他應用可以參見官網^[29]。

為什么要限制為 eTLD + 1 ，而不是通常意義 URL 的 host 部分？

答：一般情況下，eTLD + 1 都是有明確域名注冊主體的，而 host 部分可能為泛解析^[30]，如果將 *.shop.example 都指向 shop.example，然后 attributionon="``https://``janeDoeTracking.shop.example"，很顯然，這個 janeDoeTracking 就可以映射為 user ID，存在漏洞，不能達到保護隱私的目的。

如果用戶通過點擊 a 標簽，最后到了 shop.example。那么這次 attributionsourceid 將會被儲存為一次從 social.example 到 shop.example 的點擊，瀏覽器本地儲存 7 天，任何網站都不能讀取這些數據，是在瀏覽器上儲存的。

在 shop.example 上，點擊了 “Add to Cart” 按鈕，作為轉化事件，會觸發事件上報至 social.example。到這里，和傳統的 Pixel 沒有什么不同。不過和 Pixel 不同的地方在于：

上報是 GET 請求到 https://social.example/.well-known/private-click-measurement/trigger-attribution/[4-bit trigger data]/[optional 6-bit priority]，如下圖：

（圖片重繪自 Webkit 博客^[31]）

URL 中的有兩個參數 trigger data和 optional priority：

trigger data：4-bit （00 到 15，必須為兩位數字），用于表示事件類型如：加入收藏、加入購物車、下單、付款完成等；

optional priority：6-bit（00 到 63，必須為兩位數字），用于表示事件優先級。trigger data 的事件在業務中，可能有不同的優先級，比如付款完成 > 下單 > 加入購物車，我們給這些轉化事件賦予不同的優先級，用于控制最后的發送內容，并不會包含在最后的歸因報告中（下文會講到）。

一旦瀏覽器檢測到某個轉化事件和之前的 click 匹配，瀏覽器會在接下來的 24 - 48 小時隨機時刻發送出歸因結果，在這一區間中，如果有更高優先級的轉化事件進入，則會上報這個更高優先級的事件。

解讀：

這一步和傳統的 Pixel 有哪些不同？

答：首先，回傳的信息只有 4-bit，所以就限定了不太可能回傳 User ID / Request ID 之類的信息，即最多支持 16 種轉化事件。而 Pixel 上報則完全沒有這個限制，可以帶 User ID、轉化事件一切歸因相關的信息。

其次，由于「優先級」的存在，一份歸因結果中，只會出現一種轉化事件，而 Pixel 可以將發生過的所有轉化事件上報，即 PCM 歸因具有聚合性。

最后，瀏覽器會將轉化事件儲存起來，在 24 - 48 小時中的隨機時刻發送出去，而 Pixel 是實時的，即 PCM 歸因具有延遲性。

最后就是歸因結果的內容了

（圖片重繪自 Webkit 博客^[32]）

PCM 的歸因結果會通過 HTTP POST 請求到 /.well-known/private-click-measurement/report-attribution/，本例中就是 https://social.example/.well-known/private-click-measurement/report-attribution/，請求體內容如下：

{"source_engagement_type":?"click","source_site":?"social.example","source_id":?[8-bit?source?ID],"attributed_on_site":?"shop.example","attribution_trigger_data":?[4-bit?trigger?data],"version":?1 }

注意到，如上文提到的，priority 信息不會包含最終的結果中。需要解釋的是：

source_engagement_type：對于 PCM 來說，值始終為 "click"。
version：當前值為 1，未來可能會有升級的空間。

App-to-Web

在理解了 Web-to-Web 之后，App-to-Web 理解起來就非常簡單了，只不過點擊源從 Site 換成了一個 App，流程一致，只不過具體 App 實現上，之前通過 a 標簽實現的部分，變成了 iOS App 的函數調用打開 Safari 瀏覽器（注意，目前 PCM 還不支持端內 inline 的 WKWebview 或者 SFSafariViewController（簡稱 SVC），即必須外跳調起 Safari，體驗相對較差，不過 Apple 表示對支持 SVC 感興趣）。

（圖片重繪自 Webkit 博客^[33]）

PS：WKWebview 和 SVC 的 UI 上的差別如下：

（左：Facebook App 的 WKWebview，右：Youtube App 的 SVC）

WKWebview 提供了比較多的 API，具有較強的定制性，比如九分屏、信息流卡片、預加載等。而 SVC 提供了非常有限的 API，基本無法定制，基本上可以認為是一個 Safari 瀏覽器的內嵌版。

值得注意的是，Apple 在 2019 年 5 月就提出了「基于保護隱私的廣告點擊度量^[34]」的提案（也叫 Ad Click Attribution），已經在現在的 Mac 或者 iOS 端已經集成了，這一提案就是 PCM 的前身，基本原理和 PCM 差不多，只是一些參數名略有變化。

左：MacOS：Safari 瀏覽器-> 開發 -> 試驗性功能 -> Ad Click Attribution

右：iOS/iPadOS：設置 -> Safari 瀏覽器 -> 高級 -> Experimental Features -> Ad Click Attribution

想要體驗的話，可以下載 Safari 瀏覽器開發版或者 iOS/iPadOS 14.5 beta 版本，或者直接體驗之前的 Ad Click Attribution 版本，提供了一個 debug 功能，其會在 10s 之后發出歸因結果，而不是 24 - 48 小時。

PCM 目前處于在 W3C 隱私社區組的 Draft 階段，詳細內容見 W3C spec^[35]，需要兩個瀏覽器（目前只有 Safari 瀏覽器）獨立實現該標準后，才可能成為 Web 標準，關于 PCM 的更多詳細信息，可以參見 Webkit 的博客文章^[36]。

SKAdNetwork (SKAN^[37])

Ad network API 是 Apple 提出的 App 廣告歸因方案。主要為了解決在保護隱私的情況下， App 下載/安裝廣告的歸因問題（App-to-App）。主要包含三個參與方：廣告平臺、源 App、推廣的 App。

廣告平臺（如 TT4B）：向 Apple 注冊廣告平臺的 ID，下發廣告至源 App，接收并校驗安裝事件的回調；
源 APP（如抖音，圖中 A App）：顯示平臺下發的廣告；
被推廣的 App（如某款新游戲，圖中 B App）：在 App 打開的時候，調用安裝事件的發送方法（實際延遲 0 - 24 小時發送）。

詳情如下圖所示：

（圖來自 Apple 開發者官網）

在理解了 PCM 之后，SKAN 就很好理解了，所有的特性都差不多（約束范圍，事件聚合、延遲發送），我們看一下最后延遲上報的數據

{"version":?"2.2","ad-network-id":?"com.example","campaign-id":?[integer?between?1-100],"transaction-id":?"6aafb7a5-0170-41b5-bbe4-fe71dedf1e28","app-id"?:?525463029,"attribution-signature":?"MEYCIQDTuQ1Z4Tpy9D3aEKbxLl5J5iKiTumcqZikuY/AOD2U7QIhAJAaiAv89AoquHXJffcieEQXdWHpcV8ZgbKN0EwV9/sY","redownload":?true,"source-app-id":?1234567891,"fidelity-type":?1,"conversion-value":?[6-bit?conversion?value] }

我們來討論一下細節：

campaign-id：因為 SKAN 是專為 App Ad 打造的，所以名字就不用像 PCM 那樣比較通用了，這里的限制是 1 - 100 之間的整數；

conversion-value：轉化事件的值，6-bit 的整數 0 - 63，實際用途是轉化事件類型，如用戶注冊、登錄等，類似于 PCM 中的 trigger data 屬性。App 可以在第一次打開之后，0-24 小時窗口期之前，可以通過調用函數，更新這個值，更新之后，窗口期重新開始計時。

其余的字段，通過字面意思應該就可以知道了，如 app-id 指的是被推廣的 App B，source-app-id 指的是源 App A，ad-network-id 則是廣告平臺的 ID，attribution-signature 則是為了校驗本次歸因結果的，具體這里就不做進一步討論了，有興趣可以查看 Apple 開發者官網關于 SKAdNetwork 的文檔^[38]。

SKAN 也是引起「iOS 14 問題」被熱議的源頭，第一版在 2018 年發布，但是那時 IDFA 還能直接獲取到，所以沒有引起太大的關注。而 2020 年隨著 IDFA 被納入 ATT，作為 Apple 官方提供的唯一合規的 App 廣告的歸因方案，SKAN 也發布了第二版，集成在 iOS 14.5。

縱觀 Apple 提供的方案，無論是 PCM 還是 SKAN，都體現出了「保護隱私的情況下，如何完成廣告歸因」的總體原則：

約束范圍（Restricted）：無論是 campaign_id 還是 trigger-data，所有用于歸因的數據，都進行了相應的 bit 位數的限制，很大程度上避免了精準的信息泄露；

事件聚合（Aggregated）：一次點擊產生的后續所有轉化事件，都按照一定的規則（PCM 是通過 Priority，SKAN 則是時序）會進行聚合，最后上報的只會有一次轉化事件。

延遲發送（Delayed）：轉化事件發生后，不會立即發送，會延遲 24 - 48 小時之內的隨機時間發送出去。

Aggregated Event Measurement (AEM^[39])

由于 PCM 方案的 App-to-Web 目前只支持外跳調起 Safari 瀏覽器，用戶體驗較差，于是 Facebook 基于 PCM 設計的總體原則，提出了 AEM 方案。由于原理一致，就不再對流程進行細致分析了，只分析一下細節上的不同：

trigger-data：轉化事件類型，PCM 為 4-bit（16 種），AEM 為 3-bit（8 種）；

延遲上報：PCM 為 24 - 48 小時，AEM 最長為 72 小時（3 天）；

當然，如何儲存在本地、優先級匹配和延遲上報，都依賴于 Facebook App 自己的實現，通過這種「自我約束」行為，AEM 讓 App-to-Web 在全鏈路都發生在 App 內部，用戶體驗較好。詳細可以查看 Facebook 關于 AEM 的介紹^[40]。

Facebook 廣告平臺已經發布了 AEM 方案，并且面向廣告主使用。另一方面，AEM 方案是否獲得 Apple 的認可的問題，還在進行中，目前一切尚不明朗，后續有任何進展，會隨時同步。

Federated Learning of Cohorts (FLoC^[41])

聯邦學習提供了一個在保護隱私的情況下基于興趣的廣告選擇機制，在 2016 年由谷歌最先提出，原本用于解決安卓手機終端用戶在本地更新模型的問題，近兩三年在國內應用的比較火熱，2020 年 10 月，InfoQ 上還發表了一篇《字節跳動破局聯邦學習：開源 Fedlearner 框架，廣告投放增效 209%》^[42]文章，介紹字節跳動在聯邦學習上的一些成果。

嚴格來說，FLoC 是為了做廣告定向的。FLoC 的原理，簡單來說就是：**瀏覽器將具有相似瀏覽記錄的用戶分到一個群組（Cohort），廣告平臺通過聯邦運算，可以為這些群組提供合適的廣告。**盡管在聯邦學習過程中，會存在信息交換，但是聯邦學習框架的存在，保證了信息交換時，彼此匿名并且脫敏，無法反向破解或者窮舉，保證個人隱私和法務合規性。根據谷歌自己的評估，FLoC 的有效率達到了使用第三方 Cookie 的 95%。

Cohort 的計算和形成都是在瀏覽器本地完成，數據來源是用戶的瀏覽歷史記錄、本地計算的頁面分類等，為了保護隱私，可能還會在結果輸出時加一些噪聲混淆。下圖展示了一個例子：

（圖片來自 FLoC 的官網文章^[43]）

舉例如下（來自官網）：

FLoC Service 提供了一個包含了成千上萬個 Cohorts 的模型，每個 Cohort 可以看作是近期瀏覽記錄相似的瀏覽器；

通過 FLoC Service，A 的瀏覽器可以獲取到 FLoC 模型的數據，依據 A 的瀏覽歷史，瀏覽器本地計算出，A 屬于 Cohort 1354，同樣的方式，盡管 B 的瀏覽歷史和 A 不太相同，但是可能仍然屬于 Cohort 1354；

接著，B 訪問了某個賣鞋的電商網站：

該網站向 B 的瀏覽器請求了他的 Cohort：1354，接著 B 看了看登山靴，B 網站記錄下「一個來自 Cohort 1354 的瀏覽器可能對登山靴感興趣」；

該網站定期聚合數據，并向廣告平臺如 TT4B 共享關于 Cohort 和產品興趣的信息。

接著，A 訪問了某個新聞網站：

該網站向 A 的瀏覽器請求了他的 Cohort：1354；

該網站向廣告平臺 TT4B 請求廣告，包含了 A 的 Cohort 1354

廣告平臺 TT4B 為 A 提供相關的廣告，主要來自兩方面的數據：

新聞網站提供的 A 的 Cohort 信息；

電商網站提供的「來自 Cohort 1354 的瀏覽器可能對登山靴感興趣」

新聞網站展示廣告：????

以上的 A 和 B 是為了表述，實際過程中，個人信息并不會向任何相關方泄露。可以認為 Cohort 不是一群人，而是一些瀏覽歷史的集合。

FLoC 提案^[44] 提出了一個新的 JavaScript API：

cohort?=?await?document.interestCohort(); url?=?new?URL("https://ads.example/getCreative"); url.searchParams.append("cohort",?cohort); creative?=?await?fetch(url);

默認所有的網站的歷史記錄都會被當作 Cohort 的計算來源，如果想要 Opt-out，可以通過 HTTP 的 reponse header 來進行：

Permissions-Policy:?interest-cohort=()

FLoC API 在 Chrome 89 及以上版本的瀏覽器可用，不過試用的話，需要通過命令行的方式打開 Chrome，最后的 DEMO 見 FLoC.glitch.me^[45]，更多細節在這里^[46]。Google 將在 2021 年第二季度在 Google Ads 上測試 FLoC^[47]（FLoC 也存在一些安全隱患^[48]，盡管這些測試已經開始，但是遭到了抵制）。

安全隱患包括：

1. 指紋識別風險猶在：指紋 + FLoC 加劇了風險。

2. 弱勢群組容易被歧視對待：例如基于性別、年齡、種族、宗教等維度推薦帶有歧視性的求職、買房、信貸等廣告都是在利用弱勢群體標簽謀私利。

3. 跨語境下的隱私曝光：FLoC 會更新，網站會清楚用戶的興趣「遷移」

另外，FLoC 未經用戶知情并同意，在瀏覽器內部進行了用戶行為數據的「處理」，不符合 GDPR 的原則，所以 Google 主要選擇 SEA, JP, NA 等地區的 0.5% 的用戶進行測試。

值得注意的是，FLoC 只是 Google 提出的 Privacy Sandbox^[49] 的一部分，由于這個點比較有意思，所以單獨拿出來分享。Google 于 2019 年 8 月發起了 Privacy Sandbox 項目，使命是：打造一個繁榮的 Web 生態系統，默認尊重每位用戶和隱私。討論并實現「如何在保證隱私的情況下，實現商業化變現」，和本文的主題緊密相關，該項目包含了一系列的提案：

替換現有依賴于跨站追蹤的功能：比如反垃圾、廣告轉化度量（和 PCM 的特性差不多，只是細節上有些差別）、廣告定向（FLoC）等；

逐步下線第三方 Cookie：Cookie 的屬性變更（上文分享過）、第一方集合等；

常見的替代方法：瀏覽器指紋、緩存查看、瀏覽追蹤等

這些對于研究隱私和廣告的平衡，有非常重要的啟示，也反映出 Google 對于二者關系的解決方案更為系統和長遠，強烈推薦大家閱讀（Privacy Sandbox 官網^[50]）。

第一方落地頁

由于隱私保護的大方向是：禁止跨主體的用戶信息匹配，除了以上的方案，我們還可以將所有的用戶信息都限制在同一個主體內，這個方案就是使用第一方落地頁：盡可能將用戶的行為在一方內部完成（全閉環），不在第三方有轉化行為。

為此，我們推出了面向線索收集場景的產品，Lead Generation。用戶會在第一方頁面上提交線索，完成轉化。

（線索收集 DEMO）

結語

隱私和個性化廣告的關系猶如天平的兩端，這給我們從事廣告行業的同學不斷提出了新的挑戰。如何在保護隱私的情況下，為用戶提供個性化廣告服務，也體現了技術對于隱私的尊重和敬畏。本文主要分享了個性化廣告歷史、本質問題、如何保護隱私以及現有的一些解決方案。當然，隨著時間推移，也會不斷有新的方案出現，相信在未來的某天，我們一定可以在兩者之間尋找到更合適的解決方案。

最后，由于才疏學淺，本文的內容難免出現謬誤，還請大家多多批評指正！

關于奇舞團

????????奇舞團是 360 集團最大的大前端團隊，代表集團參與 W3C 和 ECMA 會員（TC39）工作。奇舞團非常重視人才培養，有工程師、講師、翻譯官、業務接口人、團隊 Leader 等多種發展方向供員工選擇，并輔以提供相應的技術力、專業力、通用力、領導力等培訓課程。奇舞團以開放和求賢的心態歡迎各種優秀人才關注和加入奇舞團。

總結

以上是生活随笔為你收集整理的「后隐私」时代，个性化广告如何保护隐私？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：喜欢一个人和爱一个人的区别
下一篇：隐私保护：如何在社交媒体平台上保护用户隐

生活随笔

生活随笔

编程问答

「后隐私」时代，个性化广告如何保护隐私？

總覽

廣告和隱私的關系

通過媒介定向

通過內容定向

通過意圖定向

通過用戶畫像定向

根本問題是什么？

PC 時代

移動時代

有了 User ID 之后呢？

單主體

多主體

如何保護用戶隱私？

Web 間

讓 user ID 難以獲取

禁止跨主體的數據共享或匹配

App 間

讓 User ID 難以獲取

禁止跨主體的數據共享或匹配

政府機構

General Data Protection Regulation (GDPR^[20])

California Consumer Privacy Act (CCPA^[22])

個性化廣告會面臨哪些困難？

當前有哪些解決方案？

Private Click Measurement (PCM^[25])

Web-to-Web

App-to-Web

SKAdNetwork (SKAN^[37])

Aggregated Event Measurement (AEM^[39])

Federated Learning of Cohorts (FLoC^[41])

第一方落地頁

結語

相關知識和文檔

參考資料

關于奇舞團

總結

编程问答

「后隐私」时代，个性化广告如何保护隐私？

總覽

廣告和隱私的關系

通過媒介定向

通過內容定向

通過意圖定向

通過用戶畫像定向

根本問題是什么？

PC 時代

移動時代

有了 User ID 之后呢？

單主體

多主體

如何保護用戶隱私？

Web 間

讓 user ID 難以獲取

禁止跨主體的數據共享或匹配

App 間

讓 User ID 難以獲取

禁止跨主體的數據共享或匹配

政府機構

General Data Protection Regulation (GDPR[20])

California Consumer Privacy Act (CCPA[22])

個性化廣告會面臨哪些困難？

當前有哪些解決方案？

Private Click Measurement (PCM[25])

Web-to-Web

App-to-Web

SKAdNetwork (SKAN[37])

Aggregated Event Measurement (AEM[39])

Federated Learning of Cohorts (FLoC[41])

第一方落地頁

結語

相關知識和文檔

參考資料

關于奇舞團

總結

General Data Protection Regulation (GDPR^[20])

California Consumer Privacy Act (CCPA^[22])

Private Click Measurement (PCM^[25])

SKAdNetwork (SKAN^[37])

Aggregated Event Measurement (AEM^[39])

Federated Learning of Cohorts (FLoC^[41])