總覽

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

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

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

廣告和隱私的關(guān)系

廣告并不是一開始就和隱私有關(guān)系的，而是隨著時(shí)代的發(fā)展，廣告平臺(tái)對于變現(xiàn)效率不斷提出了更高的要求，云計(jì)算、大數(shù)據(jù)、機(jī)器學(xué)習(xí)等前沿技術(shù)的應(yīng)用也越來越多，對于數(shù)據(jù)的收集、運(yùn)算和應(yīng)用的規(guī)模也在逐步地?cái)U(kuò)大。我們把廣告精準(zhǔn)性的深入程度由淺入深的劃分了幾個(gè)階段：

（圖片來源：人人都是產(chǎn)品經(jīng)理^[1]）

通過媒介定向

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

通過內(nèi)容定向

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

通過意圖定向

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

通過用戶畫像定向

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

隨著對定向精準(zhǔn)程度的逐步提升，廣告對于用戶數(shù)據(jù)的收集、計(jì)算和應(yīng)用的程度也越來越高。用戶隱私問題也越來越多地進(jìn)入到用戶視線中。

根本問題是什么？

從技術(shù)角度看，最根本的問題是用戶標(biāo)識(shí)，即 User ID。

為什么呢？因?yàn)橐磺袛?shù)據(jù)、偏好的基礎(chǔ)背后都是用戶，我們需要根據(jù)一個(gè) User ID 來「唯一」定義一名用戶。

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

PC 時(shí)代

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

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

https://juejin.cn/post/6844903617510506504

移動(dòng)時(shí)代

到了移動(dòng)時(shí)代，除了 Web 之外，我們還多了 App 形態(tài)。在 Web 時(shí)代，前端能獲取到的信息十分有限，而 App 則直接可以和系統(tǒng)甚至硬件進(jìn)行交互，獲取到的信息就多得多了。移動(dòng)時(shí)代的 Android 和 iOS 系統(tǒng)甚至分別提供了唯一的設(shè)備標(biāo)識(shí)符，都不用自己生成。

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

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

有了 User ID 之后呢？

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

單主體

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

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

多主體

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

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

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

顯然，風(fēng)險(xiǎn)最高的就是跨主體的進(jìn)行 User ID 共享，特別是在未獲得用戶授權(quán)甚至用戶無感知的情況下。

如何保護(hù)用戶隱私？

既然風(fēng)險(xiǎn)最高的是跨主體的 User ID 共享，那么防范的主要途徑有兩個(gè)：

1. User ID：變得難以獲??；
2. 共享：禁止跨主體的數(shù)據(jù)共享或匹配；

按照這兩條指導(dǎo)原則，我們在 Web 和 App 分別來看看如何實(shí)現(xiàn)？

Web 間

1. 讓 user ID 難以獲取

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

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

這一技術(shù)在 Safari 和 Firefox 已經(jīng)率先實(shí)現(xiàn)，如訪問 Fingerprint 的 DEMO^[4] 地址，我們對比一下 Safari 的普通模式和隱私模式的指紋。

Safari

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

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

Firefox

（左：普通模式，右：隱私模式，F(xiàn)irefox 87.0 (64 位)）

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

Chrome

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

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

2. 禁止跨主體的數(shù)據(jù)共享或匹配

對于 Web 來說，「禁止跨主體的數(shù)據(jù)共享或者匹配」所依賴的載體就是 Cookie 了，準(zhǔn)確來說，應(yīng)該是第三方 Cookie?；驹砣缦聢D：

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

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

第三方 Cookie 對于隱私保護(hù)方面的風(fēng)險(xiǎn)大家的認(rèn)同基本是一致的，這一做法在主流瀏覽器上在不同程度上已經(jīng)逐步得以實(shí)現(xiàn)，小眾的瀏覽器如 Tor 瀏覽器^[8]、Brave 瀏覽器^[9] 早已實(shí)現(xiàn)了這一舉措，主流瀏覽器的情況如下：

Safari

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

Firefox

• 2019.9.3 發(fā)布：在 Firefox 69.0 版本之后，默認(rèn)阻止第三方 Cookie 的傳輸^[11]。

Chrome

Chrome 在阻止第三方 Cookie 傳輸方面的動(dòng)作就要謹(jǐn)慎的多，為了逐步實(shí)現(xiàn)阻止第三方 Cookie 的目標(biāo)：

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

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

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

從這個(gè)時(shí)間線和預(yù)期來看，未來 samesite 的默認(rèn)值會(huì)再次升級為 Strict，這也是最終目標(biāo)（和 Safari、Firefox 一樣），時(shí)間點(diǎn)預(yù)期是 2022 年，前后可以看出阻止第三方 Cookie 的傳輸，持續(xù) 6 年左右。

App 間

1. 讓 User ID 難以獲取

iOS

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

1. iOS 5 及之前，可以獲取到 UDID
2. 2012.9：iOS 6 發(fā)布，新增了 Identifier for Advertising (IDFA)
3. 2013.5：禁止獲取 UDID 的 App 上架（合規(guī)要求）；
4. 2013.9：iOS7 發(fā)布，禁止獲取 MAC/UDID，IDFA 可以被重置（設(shè)置 -> 隱私 -> 廣告 -> 還原廣告標(biāo)示符），重置后重新生成新的 IDFA，限制廣告跟蹤的開關(guān)默認(rèn)是關(guān)閉狀態(tài)；

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

5. 2016.9：iOS 10 發(fā)布，「還原廣告標(biāo)示符」會(huì)將 IDFA 重置為一串無意義的 0，限制廣告跟蹤的開關(guān)默認(rèn)仍然是關(guān)閉狀態(tài)；
6. 2020.6：Apple 公司宣布將在 iOS 14 中引入新的 隱私保護(hù)政策框架^[17] --- App Tracking Transparency^[18] (ATT)，在新規(guī)之下，限制廣告跟蹤的開關(guān)默認(rèn)是開啟的，如果 App 需要跨應(yīng)用跟蹤用戶，需要彈出申請彈窗，并且在用戶點(diǎn)擊允許之后，才能拿到 IDFA（可以猜想，看到彈窗的用戶大概率是不會(huì)允許的）。

（圖片來源：Apple 開發(fā)者官網(wǎng)）

因?yàn)榇伺e會(huì)給整個(gè)移動(dòng)互聯(lián)網(wǎng)廣告行業(yè)帶來巨大的影響（下文會(huì)講到），加上全球新冠肺炎疫情蔓延的影響，ATT 并沒有在 2020.9 伴隨 iOS 14 一起發(fā)布，而是一直在推遲，終于在 2021.4.26，Apple 公司發(fā)布上 iOS 14.5 集成了這一功能。

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

Android

相比于 iOS，Android 對于 User ID 標(biāo)識(shí)的獲取的限制就溫和得多。據(jù) 彭博社報(bào)道^[19]：

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

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

綜上，Android 上的 User ID 及相關(guān)隱私保護(hù)政策，短期內(nèi)沒有明確的時(shí)間表。

2. 禁止跨主體的數(shù)據(jù)共享或匹配

iOS

在第一點(diǎn)其實(shí)已經(jīng)講過了，ATT 政策除了限制 IDFA 的獲取之外，還禁止了跨 App 的數(shù)據(jù)共享和匹配。

Android

同上，相關(guān)政策目前沒有明確的時(shí)間表。

政府機(jī)構(gòu)

除了各大廠商提供了一些隱私保護(hù)措施，政府或機(jī)構(gòu)也先后制定并出臺(tái)了一些是隱私保護(hù)的法律法規(guī)。

1. General Data Protection Regulation (GDPR^[20])

GDPR 的主要目標(biāo)是個(gè)人對于個(gè)人數(shù)據(jù)的控制，以及為了國際商務(wù)而簡化在歐盟內(nèi)的統(tǒng)一規(guī)范。用戶可以直接感知到的解釋是：以上提到的無論是 User ID 的生成、儲(chǔ)存甚至跨主體共享，用戶都是不知情或者即使知情也無法拒絕的。GDPR 就是希望將這個(gè)控制權(quán)「拿」回來。

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

1. 個(gè)人數(shù)據(jù)的用途、保留時(shí)間以及是否和第三方共享
2. 如何停止跟蹤
3. 如何訪問、管理、更新和刪除個(gè)人數(shù)據(jù)

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

2. California Consumer Privacy Act (CCPA^[22])

CCPA 的條款基本內(nèi)容和設(shè)立目的和 GDPR 基本相同，他們區(qū)別點(diǎn)在于關(guān)于個(gè)人數(shù)據(jù)的定義、每種信息的內(nèi)容范圍和地域范圍、個(gè)人信息銷售的選擇權(quán)等。

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

附：在調(diào)研過程中，發(fā)現(xiàn)了能提高合規(guī)改造效率的工具：__CookieBot^[24]

個(gè)性化廣告會(huì)面臨哪些困難？

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

轉(zhuǎn)化歸因是什么？

用通俗的話來說，就是「本次轉(zhuǎn)化是由于哪個(gè)媒體的哪個(gè)位置哪次的 show/click 引起的」。轉(zhuǎn)化歸因?qū)τ趶V告系統(tǒng)是非常重要的，因?yàn)樗蛷V告計(jì)費(fèi)、廣告定向是息息相關(guān)的。

上圖抽象了用戶 123 從 A 主體到 B 主體之后，發(fā)生轉(zhuǎn)化的過程（當(dāng)然實(shí)際過程要比圖中復(fù)雜得多）。圖中的歸因服務(wù)可以由 A 主體提供，也可以由第三方提供。B 主體上報(bào)信息可以通過埋入來自 A 主體的 SDK 實(shí)現(xiàn)，也可以由 B 主體自己上報(bào)。

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

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

當(dāng)前有哪些解決方案？

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

• Web-to-Web：從網(wǎng)頁跳轉(zhuǎn)至網(wǎng)頁的場景（多見于 PC 端廣告）；

• App-to-Web：從 App 跳轉(zhuǎn)至網(wǎng)頁的場景（這是比較常見的第三方落地頁廣告，如從抖音 feed 流打開廣告主的落地頁）；

• App-to-App：從 App 跳轉(zhuǎn)至 App 的場景（這是比較常見的應(yīng)用下載廣告，如從抖音 feed 流點(diǎn)擊調(diào)起 App Store，下載后，進(jìn)入目的 App）

Private Click Measurement (PCM^[25])

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

Web-to-Web

之前：

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

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

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

1. 在 <a> 標(biāo)簽增加兩個(gè)屬性：attributionsourceid 和 attributeon
1. attributionsourceid：8-bit 的源 ID，即 0 - 255 共 256 個(gè)，在廣告中，通常都是指 campaign_id，表明是從屬于哪個(gè)廣告計(jì)劃；

解讀：

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

答：因?yàn)?PCM 從技術(shù)上并不是和廣告緊密相關(guān)，所以起了一個(gè)比較中性的名字 source_id。

2. 限制 8-bit = 256 個(gè)總數(shù)是為了什么？

答：為了限制同一個(gè) A 主體下，進(jìn)行跨站追蹤的最大廣告計(jì)劃個(gè)數(shù)，即 256 個(gè)。

2. attributionon：接下來要進(jìn)行歸因的目標(biāo)網(wǎng)站域名，只支持可注冊的域名或者 eTLD + 1（通俗來講就是合法的可注冊域名）。

解讀：

1. attributionon 是什么？

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

這里的 eTLD + 1，是更準(zhǔn)確的說法。比如我的 Github 項(xiàng)目 color-picker 的主頁地址：https://zhangbobell.github.io/color-picker/，由于 github.io 是一個(gè) eTLD，所以如果跳轉(zhuǎn)的目的網(wǎng)頁是上面的地址的話，attributionon="https://zhangbobell.github.io"。

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

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

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

2. 如果用戶通過點(diǎn)擊 a 標(biāo)簽，最后到了 shop.example。那么這次 attributionsourceid 將會(huì)被儲(chǔ)存為一次從 social.example 到 shop.example 的點(diǎn)擊，瀏覽器本地儲(chǔ)存 7 天，任何網(wǎng)站都不能讀取這些數(shù)據(jù)，是在瀏覽器上儲(chǔ)存的。
3. 在 shop.example 上，點(diǎn)擊了 “Add to Cart” 按鈕，作為轉(zhuǎn)化事件，會(huì)觸發(fā)事件上報(bào)至 social.example。到這里，和傳統(tǒng)的 Pixel 沒有什么不同。不過和 Pixel 不同的地方在于：

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

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

URL 中的有兩個(gè)參數(shù) trigger data和 optional priority：

1. trigger data：4-bit （00 到 15，必須為兩位數(shù)字），用于表示事件類型如：加入收藏、加入購物車、下單、付款完成等；
2. optional priority：6-bit（00 到 63，必須為兩位數(shù)字），用于表示事件優(yōu)先級。trigger data 的事件在業(yè)務(wù)中，可能有不同的優(yōu)先級，比如付款完成 > 下單 > 加入購物車，我們給這些轉(zhuǎn)化事件賦予不同的優(yōu)先級，用于控制最后的發(fā)送內(nèi)容，并不會(huì)包含在最后的歸因報(bào)告中（下文會(huì)講到）。

一旦瀏覽器檢測到某個(gè)轉(zhuǎn)化事件和之前的 click 匹配，瀏覽器會(huì)在接下來的 24 - 48 小時(shí)隨機(jī)時(shí)刻發(fā)送出歸因結(jié)果，在這一區(qū)間中，如果有更高優(yōu)先級的轉(zhuǎn)化事件進(jìn)入，則會(huì)上報(bào)這個(gè)更高優(yōu)先級的事件。

解讀：

1. 這一步和傳統(tǒng)的 Pixel 有哪些不同？

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

其次，由于「優(yōu)先級」的存在，一份歸因結(jié)果中，只會(huì)出現(xiàn)一種轉(zhuǎn)化事件，而 Pixel 可以將發(fā)生過的所有轉(zhuǎn)化事件上報(bào)，即 PCM 歸因具有聚合性。

最后，瀏覽器會(huì)將轉(zhuǎn)化事件儲(chǔ)存起來，在 24 - 48 小時(shí)中的隨機(jī)時(shí)刻發(fā)送出去，而 Pixel 是實(shí)時(shí)的，即 PCM 歸因具有延遲性。

5. 最后就是歸因結(jié)果的內(nèi)容了

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

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

{
   "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 信息不會(huì)包含最終的結(jié)果中。需要解釋的是：

• source_engagement_type：對于 PCM 來說，值始終為 "click"。
• version：當(dāng)前值為 1，未來可能會(huì)有升級的空間。

App-to-Web

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

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

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

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

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

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

左：MacOS：Safari 瀏覽器-> 開發(fā) -> 試驗(yàn)性功能 -> Ad Click Attribution

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

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

PCM 目前處于在 W3C 隱私社區(qū)組的 Draft 階段，詳細(xì)內(nèi)容見 W3C spec^[35]，需要兩個(gè)瀏覽器（目前只有 Safari 瀏覽器）獨(dú)立實(shí)現(xiàn) 該標(biāo)準(zhǔn)后，才可能成為 Web 標(biāo)準(zhǔn)，關(guān)于 PCM 的更多詳細(xì)信息，可以參見 Webkit 的 博客文章^[36]。

SKAdNetwork (SKAN^[37])

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

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

詳情如下圖所示：

（圖來自 Apple 開發(fā)者官網(wǎng)）

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

{
    "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]
}

我們來討論一下細(xì)節(jié)：

1. campaign-id：因?yàn)?SKAN 是專為 App Ad 打造的，所以名字就不用像 PCM 那樣比較通用了，這里的限制是 1 - 100 之間的整數(shù)；
2. conversion-value：轉(zhuǎn)化事件的值，6-bit 的整數(shù) 0 - 63，實(shí)際用途是轉(zhuǎn)化事件類型，如用戶注冊、登錄等，類似于 PCM 中的 trigger data 屬性。App 可以在第一次打開之后，0-24 小時(shí)窗口期之前，可以通過調(diào)用函數(shù)，更新這個(gè)值，更新之后，窗口期重新開始計(jì)時(shí)。

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

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

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

1. 約束范圍（Restricted）：無論是 campaign_id 還是 trigger-data，所有用于歸因的數(shù)據(jù)，都進(jìn)行了相應(yīng)的 bit 位數(shù)的限制，很大程度上避免了精準(zhǔn)的信息泄露；
2. 事件聚合（Aggregated）：一次點(diǎn)擊產(chǎn)生的后續(xù)所有轉(zhuǎn)化事件，都按照一定的規(guī)則（PCM 是通過 Priority，SKAN 則是時(shí)序）會(huì)進(jìn)行聚合，最后上報(bào)的只會(huì)有一次轉(zhuǎn)化事件。
3. 延遲發(fā)送（Delayed）：轉(zhuǎn)化事件發(fā)生后，不會(huì)立即發(fā)送，會(huì)延遲 24 - 48 小時(shí)之內(nèi)的隨機(jī)時(shí)間發(fā)送出去。

Aggregated Event Measurement (AEM^[39])

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

1. trigger-data：轉(zhuǎn)化事件類型，PCM 為 4-bit（16 種），AEM 為 3-bit（8 種）；
2. 延遲上報(bào)：PCM 為 24 - 48 小時(shí)，AEM 最長為 72 小時(shí)（3 天）；

當(dāng)然，如何儲(chǔ)存在本地、優(yōu)先級匹配和延遲上報(bào)，都依賴于 Facebook App 自己的實(shí)現(xiàn)，通過這種「自我約束」行為，AEM 讓 App-to-Web 在全鏈路都發(fā)生在 App 內(nèi)部，用戶體驗(yàn)較好。詳細(xì)可以查看 Facebook 關(guān)于 AEM 的介紹^[40]。

Facebook 廣告平臺(tái)已經(jīng)發(fā)布了 AEM 方案，并且面向廣告主使用。另一方面，AEM 方案是否獲得 Apple 的認(rèn)可的問題，還在進(jìn)行中，目前一切尚不明朗，后續(xù)有任何進(jìn)展，會(huì)隨時(shí)同步。

Federated Learning of Cohorts (FLoC^[41])

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

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

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

（圖片來自 FLoC 的 官網(wǎng)文章^[43]）

舉例如下（來自官網(wǎng)）：

1. FLoC Service 提供了一個(gè)包含了成千上萬個(gè) Cohorts 的模型，每個(gè) Cohort 可以看作是近期瀏覽記錄相似的瀏覽器；
2. 通過 FLoC Service，A 的瀏覽器可以獲取到 FLoC 模型的數(shù)據(jù)，依據(jù) A 的瀏覽歷史，瀏覽器本地計(jì)算出，A 屬于 Cohort 1354，同樣的方式，盡管 B 的瀏覽歷史和 A 不太相同，但是可能仍然屬于 Cohort 1354；
3. 接著，B 訪問了某個(gè)賣鞋的電商網(wǎng)站：
1. 該網(wǎng)站向 B 的瀏覽器請求了他的 Cohort：1354，接著 B 看了看登山靴，B 網(wǎng)站記錄下「一個(gè)來自 Cohort 1354 的瀏覽器可能對登山靴感興趣」；
2. 該網(wǎng)站定期聚合數(shù)據(jù)，并向廣告平臺(tái)如 TT4B 共享關(guān)于 Cohort 和產(chǎn)品興趣的信息。
4. 接著，A 訪問了某個(gè)新聞網(wǎng)站：
1. 該網(wǎng)站向 A 的瀏覽器請求了他的 Cohort：1354；
2. 該網(wǎng)站向廣告平臺(tái) TT4B 請求廣告，包含了 A 的 Cohort 1354
5. 廣告平臺(tái) TT4B 為 A 提供相關(guān)的廣告，主要來自兩方面的數(shù)據(jù)：
1. 新聞網(wǎng)站提供的 A 的 Cohort 信息；
2. 電商網(wǎng)站提供的「來自 Cohort 1354 的瀏覽器可能對登山靴感興趣」
6. 新聞網(wǎng)站展示廣告：??

以上的 A 和 B 是為了表述，實(shí)際過程中，個(gè)人信息并不會(huì)向任何相關(guān)方泄露?？梢哉J(rèn)為 Cohort 不是一群人，而是一些瀏覽歷史的集合。

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

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

默認(rèn)所有的網(wǎng)站的歷史記錄都會(huì)被當(dāng)作 Cohort 的計(jì)算來源，如果想要 Opt-out，可以通過 HTTP 的 reponse header 來進(jìn)行：

Permissions-Policy: interest-cohort=()

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

安全隱患包括：

1. 指紋識(shí)別風(fēng)險(xiǎn)猶在：指紋 + FLoC 加劇了風(fēng)險(xiǎn)。

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

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

另外，F(xiàn)LoC 未經(jīng)用戶知情并同意，在瀏覽器內(nèi)部進(jìn)行了用戶行為數(shù)據(jù)的「處理」，不符合 GDPR 的原則，所以 Google 主要選擇 SEA, JP, NA 等地區(qū)的 0.5% 的用戶進(jìn)行測試。

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

1. 替換現(xiàn)有依賴于跨站追蹤的功能：比如反垃圾、廣告轉(zhuǎn)化度量（和 PCM 的特性差不多，只是細(xì)節(jié)上有些差別）、廣告定向（FLoC）等；
2. 逐步下線第三方 Cookie：Cookie 的屬性變更（上文分享過）、第一方集合等；
3. 常見的替代方法：瀏覽器指紋、緩存查看、瀏覽追蹤等

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

第一方落地頁

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

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

（線索收集 DEMO）

結(jié)語

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

最后，由于才疏學(xué)淺，本文的內(nèi)容難免出現(xiàn)謬誤，還請大家多多批評指正！

相關(guān)知識(shí)和文檔

1. 認(rèn)識(shí)一下 iOS 系統(tǒng)的各種設(shè)備識(shí)別碼

1、UDID ，全稱是 （Unique Device Identifier），顧名思義，它就是蘋果 IOS 設(shè)備的唯一識(shí)別碼，它由 40 個(gè)字符的字母和數(shù)字組成，為了保護(hù)用戶隱私蘋果已經(jīng)禁止讀取這個(gè)標(biāo)識(shí)了。

2、UUID，全稱是（Universally Unique IDentifier），是基于 iOS 設(shè)備上面某個(gè)單個(gè)的應(yīng)用程序，只要用戶沒有完全刪除應(yīng)用程序，則這個(gè) UUID 在用戶使用該應(yīng)用程序的時(shí)候一直保持不變。如果用戶刪除了這個(gè)應(yīng)用程序，然后再重新安裝，那么這個(gè) UUID 已經(jīng)發(fā)生了改變。UUID 不好的地方就是用戶刪除了你開發(fā)的程序以后，基本上你就不可能獲取之前的數(shù)據(jù)了。

3、MAC 地址，用來定義網(wǎng)絡(luò)設(shè)備的位置。一個(gè)主機(jī)會(huì)有一個(gè) MAC 地址，MAC 地址是網(wǎng)卡決定的，是固定的，為了保護(hù)用戶隱私蘋果已經(jīng)禁止讀取這個(gè)標(biāo)識(shí)了。

4、OpenUDID，不是蘋果官方的，是一個(gè)替代 UDID 的第三發(fā)解決方案， 缺點(diǎn)是如果你完全刪除全部帶有 OpenUDID SDK 包的 App（比如恢復(fù)系統(tǒng)等），那么 OpenUDID 會(huì)重新生成，而且和之前的值會(huì)不同，相當(dāng)于新設(shè)備；

5、IDFA 廣告標(biāo)示符，適用于對外：例如廣告推廣，換量等跨應(yīng)用的用戶追蹤等。

6、IDFV，Vendor 標(biāo)示符 (IDFV - Identifier For Vendor)，來自同一個(gè)開發(fā)商（例如 com.zhihu.app1 和 com.zhihu.app2）的應(yīng)用運(yùn)行在同一個(gè)設(shè)備上，此屬性的值是相同的；不同的運(yùn)營商應(yīng)用運(yùn)行在同一個(gè)設(shè)備上值不同。

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

https://webkit.org/tracking-prevention/

3. 掘金上設(shè)備 ID 生成的文章

https://juejin.cn/post/6844903952148856839

4. Apple 在 2019 年發(fā)布的 Safari 白皮書

https://www.apple.com/safari/docs/Safari_White_Paper_Nov_2019.pdf

5. 瀏覽器指紋生成的調(diào)研論文

https://arxiv.org/pdf/1905.01051.pdf

6. 阿里關(guān)于 Cookie samesite 默認(rèn)值變更為 Lax 的改造總結(jié)：

https://github.com/mqyqingfeng/Blog/issues/157

7. Chromium 團(tuán)隊(duì)提出的 Privacy Sandbox 介紹

https://www.chromium.org/Home/chromium-privacy/privacy-sandbox

8. CSDN 上關(guān)于聯(lián)邦學(xué)習(xí)的簡介

https://blog.csdn.net/cao812755156/article/details/89598410

9. FLoC 測試遭到抵制

https://mp.weixin.qq.com/s/XNgyjrBnFpFvFWKenxZ0jg

參考資料