「後隱私」時代，個性化廣告如何保護隱私？

時間  2021-08-12
標籤 html 前端 git github web 算法 後端 跨域 瀏覽器 緩存 欄目 HTML 简体版
原文   原文鏈接

總覽

在廣告領域，「個性化」和「隱私」彷佛是天平的兩端：個性化作的很好的廣告，一般都要收集不少用戶數據，對用戶畫像有清晰的認識；而若是將用戶數據都屏蔽掉，個性化的廣告很難取得效果。html

隨着 Apple 公司發佈 iOS 14，隱私問題也愈來愈受到你們關注，隱私保護愈來愈受到重視。在這種背景下，咱們要作的是「乘勢而爲」，本文就「後隱私」時代，個性化廣告該何去何從進行討論。從技術角度分析，內容包括：前端

  1. 分析個性化廣告和隱私的關係（原理）；
  2. 隱私問題的本質
  3. 如何保護隱私
    1. Web 間
    2. App 間
  4. 在隱私保護的狀況下，個性化廣告有哪些出路。
    1. 目前各大廠商的思路
    2. Apple: SKAN/PCM
    3. Google: Privacy Sandbox (FLoC)
    4. Facebook: AEM
    5. 第一方落地頁

廣告和隱私的關係

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

（圖片來源：人人都是產品經理）github

經過媒介定向

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

經過內容定向

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

經過意圖定向

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

經過用戶畫像定向

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

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

根本問題是什麼？

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

爲何呢？由於一切數據、偏好的基礎背後都是用戶，咱們須要根據一個 User ID 來「惟一」定義一名用戶。

聽起來「惟一」定義一名用戶，比較簡單，可是在沒有登陸的狀況下，如何惟一的定義一名用戶呢？

PC 時代

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

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

juejin.cn/post/684490…

移動時代

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

Android 可使用 Android ID，iOS 則從 MAC 升級到 UDID 再到 IDFA，固然隨着 iOS 14 的逐步覆蓋提高，IDFA 獲取到的難度大大增長（後文會解釋）。

（圖片來源：知乎）

有了 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 共享，那麼防範的主要途徑有兩個：

  1. User ID：變得難以獲取；
  2. 共享：禁止跨主體的數據共享或匹配；

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

Web 間

  1. 讓 user ID 難以獲取

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

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

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

Safari

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

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

Firefox

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

能夠看出，左右兩個是相同的，受限於 Firefox 的指紋檢測模式（是經過該網頁是否有和主流的 提供 Fingerprint 服務的域名有通訊，從而進行攔截，該項服務由 Disconnect 提供），詳見 Firefox 72 的發佈說明

Chrome

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

能夠看出，左右兩個是相同的，目前尚未找到 Chrome 太多的關於指紋保護的公開資料，更多的是一些 Chrome 插件提供的能力。

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

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

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

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

第三方 Cookie 對於隱私保護方面的風險你們的認同基本是一致的，這一作法在主流瀏覽器上在不一樣程度上已經逐步得以實現，小衆的瀏覽器如 Tor 瀏覽器、Brave 瀏覽器 早已實現了這一舉措，主流瀏覽器的狀況以下：

Safari

Firefox

Chrome

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

  • 2016.5.25 發佈：Chrome 51 開始，Cookie 增長一個新的屬性：samesite，該屬性有三個從低到高的值：None、Lax、Strict，默認值爲 None，詳見 MDN。
值
解釋
None
Cookie 將在全部上下文中發送，即容許跨域發送。
Lax
Cookie 容許與頂級導航一塊兒發送，並將與第三方網站發起的 GET 請求一塊兒發送。
Strict
Cookie 只會在第一方上下文中發送，不會與第三方網站發起的請求一塊兒發送。

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

請求類型
實例
之前
None
Lax
Strict
連接
<a href="..."></a>
發送
發送
發送
不發送
預加載
<link rel="preload" href="..." />
發送
發送
發送
不發送
GET 表單
<form method="GET" action="...">
發送
發送
發送
不發送
POST 表單
<form method="POST" action="...">
發送
發送
不發送
不發送
iframe
<iframe src="..."></iframe>
發送
發送
不發送
不發送
Ajax
$.get('..')
發送
發送
不發送
不發送
Image
<img src="..." />
發送
發送
不發送
不發送
  • 2020.1.14 發佈：將在 2022 年 完全阻止第三方 Cookie 的傳輸。
  • 2020.2 發佈：Chrome 80 開始，samesite 的默認值由 None 升級爲 Lax，而且要求若是強行設置 Cookie 的 samesite=None，那麼必須同時設置一個 Secure屬性（即該 Cookie 必須由 HTTPS 協議傳輸）；
  • 2020.4.3 發佈：受 COVID-19 的影響，上一條的 變動被回滾；
  • 2020.7.14 發佈：Chrome 84 開始，從新上線回滾的變動；
  • ...
  • 未完待續：關於 samesite 的進展和更詳細的時間線，能夠查看官方網站的說明。

從這個時間線和預期來看，將來 samesite 的默認值會再次升級爲 Strict，這也是最終目標（和 Safari、Firefox 同樣），時間點預期是 2022 年，先後能夠看出阻止第三方 Cookie 的傳輸，持續 6 年左右。

App 間

  1. 讓 User ID 難以獲取

iOS

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

  1. iOS 5 及以前，能夠獲取到 UDID
  2. 2012.9：iOS 6 發佈，新增了 Identifier for Advertising (IDFA)
  3. 2013.5：禁止獲取 UDID 的 App 上架（合規要求）；
  4. 2013.9：iOS7 發佈，禁止獲取 MAC/UDID，IDFA 能夠被重置（設置 -> 隱私 -> 廣告 -> 還原廣告標示符），重置後從新生成新的 IDFA，限制廣告跟蹤的開關默認是關閉狀態；

（圖片來源：知乎）

  1. 2016.9：iOS 10 發佈，「還原廣告標示符」會將 IDFA 重置爲一串無心義的 0，限制廣告跟蹤的開關默認仍然是關閉狀態；
  2. 2020.6：Apple 公司宣佈將在 iOS 14 中引入新的 隱私保護政策框架 --- App Tracking Transparency (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 標識的獲取的限制就溫和得多。據 彭博社報道：

Google 正在研究和跟進 ATT，而且探索替代方案。其解決方案大機率沒有那麼嚴格，也不會須要彈出彈窗來獲取用戶許可，這些探索都處於早期，並無決定是否跟進或者什麼時候跟進。

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

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

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

iOS

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

Android

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

政府機構

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

  1. General Data Protection Regulation (GDPR)

GDPR 的主要目標是我的對於我的數據的控制，以及爲了國際商務而簡化在歐盟內的統一規範。用戶能夠直接感知到的解釋是：以上提到的不管是 User ID 的生成、儲存甚至跨主體共享，用戶都是不知情或者即便知情也沒法拒絕的。GDPR 就是但願將這個控制權「拿」回來。

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

  1. 我的數據的用途、保留時間以及是否和第三方共享
  2. 如何中止跟蹤
  3. 如何訪問、管理、更新和刪除我的數據

GDPR 法規已於 2018 年 5 月 25 日開始實施，詳細能夠參見 維基百科 的詞條解釋。

  1. California Consumer Privacy Act (CCPA)

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

CCPA 於 2020 年 1 月 1 日開始實施，詳細能夠參見 維基百科 的詞條解釋。

附：在調研過程當中，發現了能提升合規改造效率的工具：__CookieBot

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

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

轉化歸因是什麼？

用通俗的話來講，就是「本次轉化是因爲哪一個媒體的哪一個位置哪次的 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)

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

Web-to-Web

以前：

（圖片重繪自 Webkit 博客）

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

（圖片重繪自 Webkit 博客）

  1. 在 <a> 標籤增長兩個屬性：attributionsourceid 和 attributeon
    1. attributionsourceid：8-bit 的源 ID，即 0 - 255 共 256 個，在廣告中，一般都是指 campaign_id，代表是從屬於哪一個廣告計劃；

解讀：

  1. 既然是用於歸因的，爲何名字不起成 campaign_id？

答：由於 PCM 從技術上並非和廣告緊密相關，因此起了一個比較中性的名字 source_id。

  1. 限制 8-bit = 256 個總數是爲了什麼？

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

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

解讀：

  1. attributionon 是什麼？

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

這裏的 eTLD + 1，是更準確的說法。好比個人 Github 項目 color-picker 的主頁地址：zhangbobell.github.io/color-picke… github.io 是一個 eTLD，因此若是跳轉的目的網頁是上面的地址的話，attributionon="``https://zhangbobell.github.io``"。

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

  1. 爲何要限制爲 eTLD + 1 ，而不是一般意義 URL 的 host 部分？

答：通常狀況下，eTLD + 1 都是有明確域名註冊主體的，而 host 部分可能爲 泛解析，若是將 *.shop.example 都指向 shop.example，而後 attributionon="``https://``janeDoeTracking.shop.example"，很顯然，這個 janeDoeTracking 就能夠映射爲 user ID，存在漏洞，不能達到保護隱私的目的。

  1. 若是用戶經過點擊 a 標籤，最後到了 shop.example。那麼此次 attributionsourceid 將會被儲存爲一次從 social.example 到 shop.example 的點擊，瀏覽器本地儲存 7 天，任何網站都不能讀取這些數據，是在瀏覽器上儲存的。
  2. 在 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 博客）

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

  1. trigger data：4-bit （00 到 15，必須爲兩位數字），用於表示事件類型如：加入收藏、加入購物車、下單、付款完成等；
  2. optional priority：6-bit（00 到 63，必須爲兩位數字），用於表示事件優先級。trigger data 的事件在業務中，可能有不一樣的優先級，好比付款完成 > 下單 > 加入購物車，咱們給這些轉化事件賦予不一樣的優先級，用於控制最後的發送內容，並不會包含在最後的歸因報告中（下文會講到）。

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

解讀：

  1. 這一步和傳統的 Pixel 有哪些不一樣？

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

其次，因爲「優先級」的存在，一份歸因結果中，只會出現一種轉化事件，而 Pixel 能夠將發生過的全部轉化事件上報，即 PCM 歸因具備聚合性。

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

  1. 最後就是歸因結果的內容了

（圖片重繪自 Webkit 博客）

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 博客）

PS：WKWebview 和 SVC 的 UI 上的差異以下：

111111.png

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

WKWebview 提供了比較多的 API，具備較強的定製性，好比九分屏、信息流卡片、預加載等。而 SVC 提供了很是有限的 API，基本沒法定製，基本上能夠認爲是一個 Safari 瀏覽器的內嵌版。

值得注意的是，Apple 在 2019 年 5 月就提出了「基於保護隱私的廣告點擊度量」的提案（也叫 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，須要兩個瀏覽器（目前只有 Safari 瀏覽器）獨立實現 該標準後，纔可能成爲 Web 標準，關於 PCM 的更多詳細信息，能夠參見 Webkit 的 博客文章。

SKAdNetwork (SKAN)

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]
}
複製代碼

咱們來討論一下細節：

  1. campaign-id：由於 SKAN 是專爲 App Ad 打造的，因此名字就不用像 PCM 那樣比較通用了，這裏的限制是 1 - 100 之間的整數；
  2. 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 的文檔。

SKAN 也是引發「iOS 14 問題」被熱議的源頭，初版在 2018 年發佈，可是那時 IDFA 還能直接獲取到，因此沒有引發太大的關注。而 2020 年隨着 IDFA 被歸入 ATT，做爲 Apple 官方提供的惟一合規的 App 廣告的歸因方案，SKAN 也發佈了第二版，集成在 iOS 14.5。

縱觀 Apple 提供的方案，不管是 PCM 仍是 SKAN，都體現出了「保護隱私的狀況下，如何完成廣告歸因」的整體原則：

  1. 約束範圍（Restricted）：不管是 campaign_id 仍是 trigger-data，全部用於歸因的數據，都進行了相應的 bit 位數的限制，很大程度上避免了精準的信息泄露；
  2. 事件聚合（Aggregated）：一次點擊產生的後續全部轉化事件，都按照必定的規則（PCM 是經過 Priority，SKAN 則是時序）會進行聚合，最後上報的只會有一次轉化事件。
  3. 延遲發送（Delayed）：轉化事件發生後，不會當即發送，會延遲 24 - 48 小時以內的隨機時間發送出去。

Aggregated Event Measurement (AEM)

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

  1. trigger-data：轉化事件類型，PCM 爲 4-bit（16 種），AEM 爲 3-bit（8 種）；
  2. 延遲上報：PCM 爲 24 - 48 小時，AEM 最長爲 72 小時（3 天）；

固然，如何儲存在本地、優先級匹配和延遲上報，都依賴於 Facebook App 本身的實現，經過這種「自我約束」行爲，AEM 讓 App-to-Web 在全鏈路都發生在 App 內部，用戶體驗較好。詳細能夠查看 Facebook 關於 AEM 的介紹。

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

Federated Learning of Cohorts (FLoC)

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

嚴格來講，FLoC 是爲了作廣告定向的。FLoC 的原理，簡單來講就是：**瀏覽器將具備類似瀏覽記錄的用戶分到一個羣組（Cohort），廣告平臺經過聯邦運算，能夠爲這些羣組提供合適的廣告。**儘管在聯邦學習過程當中，會存在信息交換，可是聯邦學習框架的存在，保證了信息交換時，彼此匿名而且脫敏，沒法反向破解或者窮舉，保證我的隱私和法務合規性。根據谷歌本身的評估，FLoC 的有效率達到了使用第三方 Cookie 的 95%。

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

（圖片來自 FLoC 的 官網文章）

舉例以下（來自官網）：

  1. FLoC Service 提供了一個包含了成千上萬個 Cohorts 的模型，每一個 Cohort 能夠看做是近期瀏覽記錄類似的瀏覽器；
  2. 經過 FLoC Service，A 的瀏覽器能夠獲取到 FLoC 模型的數據，依據 A 的瀏覽歷史，瀏覽器本地計算出，A 屬於 Cohort 1354，一樣的方式，儘管 B 的瀏覽歷史和 A 不太相同，可是可能仍然屬於 Cohort 1354；
  3. 接着，B 訪問了某個賣鞋的電商網站：
    1. 該網站向 B 的瀏覽器請求了他的 Cohort：1354，接着 B 看了看爬山靴，B 網站記錄下「一個來自 Cohort 1354 的瀏覽器可能對爬山靴感興趣」；
    2. 該網站按期聚合數據，並向廣告平臺如 TT4B 共享關於 Cohort 和產品興趣的信息。
  4. 接着，A 訪問了某個新聞網站：
    1. 該網站向 A 的瀏覽器請求了他的 Cohort：1354；
    2. 該網站向廣告平臺 TT4B 請求廣告，包含了 A 的 Cohort 1354
  5. 廣告平臺 TT4B 爲 A 提供相關的廣告，主要來自兩方面的數據：
    1. 新聞網站提供的 A 的 Cohort 信息；
    2. 電商網站提供的「來自 Cohort 1354 的瀏覽器可能對爬山靴感興趣」
  6. 新聞網站展現廣告：🥾

以上的 A 和 B 是爲了表述，實際過程當中，我的信息並不會向任何相關方泄露。能夠認爲 Cohort 不是一羣人，而是一些瀏覽歷史的集合。

FLoC 提案 提出了一個新的 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，更多細節在 這裏。Google 將在 2021 年第二季度在 Google Ads 上測試 FLoC（FLoC 也存在一些安全隱患，儘管這些測試已經開始，可是遭到了抵制）。

安全隱患包括：

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

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

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

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

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

  1. 替換現有依賴於跨站追蹤的功能：好比反垃圾、廣告轉化度量（和 PCM 的特性差很少，只是細節上有些差異）、廣告定向（FLoC）等；
  2. 逐步下線第三方 Cookie：Cookie 的屬性變動（上文分享過）、第一方集合等；
  3. 常見的替代方法：瀏覽器指紋、緩存查看、瀏覽追蹤等

這些對於研究隱私和廣告的平衡，有很是重要的啓示，也反映出 Google 對於兩者關係的解決方案更爲系統和長遠，強烈推薦你們閱讀（Privacy Sandbox 官網）。

第一方落地頁

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

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

（線索收集 DEMO）

結語

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

最後，因爲才疏學淺，本文的內容不免出現謬誤，還請你們多多批評指正！

相關知識和文檔

  1. 認識一下 iOS 系統的各類設備識別碼

一、UDID ，全稱是 （Unique Device Identifier），顧名思義，它就是蘋果 IOS 設備的惟一識別碼，它由 40 個字符的字母和數字組成，爲了保護用戶隱私蘋果已經禁止讀取這個標識了。

二、UUID，全稱是（Universally Unique IDentifier），是基於 iOS 設備上面某個單個的應用程序，只要用戶沒有徹底刪除應用程序，則這個 UUID 在用戶使用該應用程序的時候一直保持不變。若是用戶刪除了這個應用程序，而後再從新安裝，那麼這個 UUID 已經發生了改變。UUID 很差的地方就是用戶刪除了你開發的程序之後，基本上你就不可能獲取以前的數據了。

三、MAC 地址，用來定義網絡設備的位置。一個主機會有一個 MAC 地址，MAC 地址是網卡決定的，是固定的，爲了保護用戶隱私蘋果已經禁止讀取這個標識了。

四、OpenUDID，不是蘋果官方的，是一個替代 UDID 的第三發解決方案， 缺點是若是你徹底刪除所有帶有 OpenUDID SDK 包的 App（好比恢復系統等），那麼 OpenUDID 會從新生成，並且和以前的值會不一樣，至關於新設備；

五、IDFA 廣告標示符，適用於對外：例如廣告推廣，換量等跨應用的用戶追蹤等。

六、IDFV，Vendor 標示符 (IDFV - Identifier For Vendor)，來自同一個開發商（例如 com.zhihu.app1 和 com.zhihu.app2）的應用運行在同一個設備上，此屬性的值是相同的；不一樣的運營商應用運行在同一個設備上值不一樣。

  1. Webkit 阻止跟蹤（ITP）的介紹

webkit.org/tracking-pr…

  1. 掘金上設備 ID 生成的文章

juejin.cn/post/684490…

  1. Apple 在 2019 年發佈的 Safari 白皮書

www.apple.com/safari/docs…

  1. 瀏覽器指紋生成的調研論文

arxiv.org/pdf/1905.01…

  1. 阿里關於 Cookie samesite 默認值變動爲 Lax 的改造總結：

github.com/mqyqingfeng…

  1. Chromium 團隊提出的 Privacy Sandbox 介紹

www.chromium.org/Home/chromi…

  1. CSDN 上關於聯邦學習的簡介

blog.csdn.net/cao81275515…

  1. FLoC 測試遭到抵制

mp.weixin.qq.com/s/XNgyjrBnF…

「招聘信息」

咱們是字節跳動非中國區商業化技術團隊，主要致力於不斷提高全球用戶在廣告落地頁上體驗，優化廣告的轉化效果，構建第一方落地頁生態。 咱們是一個全球化的團隊，Base 在北京、上海、杭州、山景城、西雅圖等地，長期招募高級/資深前端&後端工程師和前端&後端實習生。歡迎加入咱們！

image.png

歡迎關注「 字節前端 ByteFE 」 簡歷投遞聯繫郵箱「tech@bytedance.com」

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程