當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

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

發(fā)布時(shí)間：2024/1/18 编程问答 40 豆豆

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

總覽

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

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

分析個(gè)性化廣告和隱私的關(guān)系（原理）；

隱私問(wèn)題的本質(zhì)

如何保護(hù)隱私

Web 間

App 間

在隱私保護(hù)的情況下，個(gè)性化廣告有哪些出路。

目前各大廠商的思路

Apple: SKAN/PCM

Google: Privacy Sandbox (FLoC)

Facebook: AEM

第一方落地頁(yè)

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

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

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

通過(guò)媒介定向

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

通過(guò)內(nèi)容定向

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

通過(guò)意圖定向

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

通過(guò)用戶畫(huà)像定向

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

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

根本問(wèn)題是什么？

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

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

聽(tīng)起來(lái)「唯一」定義一名用戶，比較簡(jiǎn)單，但是在沒(méi)有登錄的情況下，如何唯一的定義一名用戶呢？

PC 時(shí)代

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

如果了解前端庫(kù)如 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 升級(jí)到 UDID 再到 IDFA，當(dāng)然隨著 iOS 14 的逐步覆蓋提升，IDFA 獲取到的難度大大增加（后文會(huì)解釋）。

（圖片來(lái)源：知乎^[3]）

有了 User ID 之后呢？

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

單主體

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

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

多主體

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

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

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

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

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

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

User ID：變得難以獲取；

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

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

Web 間

讓 user ID 難以獲取

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

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

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

Safari

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

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

Firefox

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

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

Chrome

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

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

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

對(duì)于 Web 來(lái)說(shuō)，「禁止跨主體的數(shù)據(jù)共享或者匹配」所依賴的載體就是 Cookie 了，準(zhǔn)確來(lái)說(shuō)，應(yīng)該是第三方 Cookie。基本原理如下圖：

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

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

第三方 Cookie 對(duì)于隱私保護(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 開(kāi)始，Cookie 增加一個(gè)新的屬性：samesite，該屬性有三個(gè)從低到高的值：None、Lax、Strict，默認(rèn)值為 None，詳見(jiàn) MDN^[12]。

針對(duì)第三方 URL 的影響舉例如下：

2020.1.14 發(fā)布：將在 2022 年徹底阻止第三方 Cookie 的傳輸^[13]。
2020.2 發(fā)布：Chrome 80 開(kāi)始，samesite 的默認(rèn)值由 None 升級(jí)為 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 開(kāi)始，重新上線回滾的變更；
...
未完待續(xù)：關(guān)于 samesite 的進(jìn)展和更詳細(xì)的時(shí)間線，可以查看官方網(wǎng)站的說(shuō)明^[15]。

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

App 間

讓 User ID 難以獲取

iOS

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

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

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

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

2013.9：iOS7 發(fā)布，禁止獲取 MAC/UDID，IDFA 可以被重置（設(shè)置 -> 隱私 -> 廣告 -> 還原廣告標(biāo)示符），重置后重新生成新的 IDFA，限制廣告跟蹤的開(kāi)關(guān)默認(rèn)是關(guān)閉狀態(tài)；

（圖片來(lái)源：知乎^[16]）

2016.9：iOS 10 發(fā)布，「還原廣告標(biāo)示符」會(huì)將 IDFA 重置為一串無(wú)意義的 0，限制廣告跟蹤的開(kāi)關(guān)默認(rèn)仍然是關(guān)閉狀態(tài)；

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

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

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

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

Android

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

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

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

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

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

iOS

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

Android

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

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

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

General Data Protection Regulation (GDPR^[20])

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

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

個(gè)人數(shù)據(jù)的用途、保留時(shí)間以及是否和第三方共享

如何停止跟蹤

如何訪問(wèn)、管理、更新和刪除個(gè)人數(shù)據(jù)

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

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 日開(kāi)始實(shí)施，詳細(xì)可以參見(jiàn) 維基百科^[23] 的詞條解釋。

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

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

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

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

用通俗的話來(lái)說(shuō)，就是「本次轉(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)化的過(guò)程（當(dāng)然實(shí)際過(guò)程要比圖中復(fù)雜得多）。圖中的歸因服務(wù)可以由 A 主體提供，也可以由第三方提供。B 主體上報(bào)信息可以通過(guò)埋入來(lái)自 A 主體的 SDK 實(shí)現(xiàn)，也可以由 B 主體自己上報(bào)。

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

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

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

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

Web-to-Web：從網(wǎng)頁(yè)跳轉(zhuǎn)至網(wǎng)頁(yè)的場(chǎng)景（多見(jiàn)于 PC 端廣告）；
App-to-Web：從 App 跳轉(zhuǎn)至網(wǎng)頁(yè)的場(chǎng)景（這是比較常見(jiàn)的第三方落地頁(yè)廣告，如從抖音 feed 流打開(kāi)廣告主的落地頁(yè)）；
App-to-App：從 App 跳轉(zhuǎn)至 App 的場(chǎng)景（這是比較常見(jiàn)的應(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 場(chǎng)景下的廣告歸因問(wèn)題。原理如下：

Web-to-Web

之前：

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

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

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

在 <a> 標(biāo)簽增加兩個(gè)屬性：attributionsourceid 和 attributeon

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

解讀：

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

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

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

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

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

解讀：

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)確的說(shuō)法。比如我的 Github 項(xiàng)目 color-picker 的主頁(yè)地址：https://zhangbobell.github.io/color-picker/，由于 github.io 是一個(gè) eTLD，所以如果跳轉(zhuǎn)的目的網(wǎng)頁(yè)是上面的地址的話，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)用可以參見(jiàn) 官網(wǎng)^[29]。

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

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

如果用戶通過(guò)點(diǎn)擊 a 標(biāo)簽，最后到了 shop.example。那么這次 attributionsourceid 將會(huì)被儲(chǔ)存為一次從 social.example 到 shop.example 的點(diǎn)擊，瀏覽器本地儲(chǔ)存 7 天，任何網(wǎng)站都不能讀取這些數(shù)據(jù)，是在瀏覽器上儲(chǔ)存的。

在 shop.example 上，點(diǎn)擊了 “Add to Cart” 按鈕，作為轉(zhuǎn)化事件，會(huì)觸發(fā)事件上報(bào)至 social.example。到這里，和傳統(tǒng)的 Pixel 沒(méi)有什么不同。不過(guò)和 Pixel 不同的地方在于：

上報(bào)是 GET 請(qǐng)求到 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：

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

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

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

解讀：

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

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

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

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

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

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

PCM 的歸因結(jié)果會(huì)通過(guò) HTTP POST 請(qǐng)求到 /.well-known/private-click-measurement/report-attribution/，本例中就是 https://social.example/.well-known/private-click-measurement/report-attribution/，請(qǐng)求體內(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：對(duì)于 PCM 來(lái)說(shuō)，值始終為 "click"。
version：當(dāng)前值為 1，未來(lái)可能會(huì)有升級(jí)的空間。

App-to-Web

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

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

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

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

WKWebview 提供了比較多的 API，具有較強(qiáng)的定制性，比如九分屏、信息流卡片、預(yù)加載等。而 SVC 提供了非常有限的 API，基本無(wú)法定制，基本上可以認(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 瀏覽器-> 開(kāi)發(fā) -> 試驗(yàn)性功能 -> Ad Click Attribution

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

想要體驗(yàn)的話，可以下載 Safari 瀏覽器開(kāi)發(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)容見(jiàn) W3C spec^[35]，需要兩個(gè)瀏覽器（目前只有 Safari 瀏覽器）獨(dú)立實(shí)現(xiàn) 該標(biāo)準(zhǔn)后，才可能成為 Web 標(biāo)準(zhǔn)，關(guān)于 PCM 的更多詳細(xì)信息，可以參見(jiàn) Webkit 的博客文章^[36]。

SKAdNetwork (SKAN^[37])

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

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

詳情如下圖所示：

（圖來(lái)自 Apple 開(kāi)發(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] }

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

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

conversion-value：轉(zhuǎn)化事件的值，6-bit 的整數(shù) 0 - 63，實(shí)際用途是轉(zhuǎn)化事件類型，如用戶注冊(cè)、登錄等，類似于 PCM 中的 trigger data 屬性。App 可以在第一次打開(kāi)之后，0-24 小時(shí)窗口期之前，可以通過(guò)調(diào)用函數(shù)，更新這個(gè)值，更新之后，窗口期重新開(kāi)始計(jì)時(shí)。

其余的字段，通過(guò)字面意思應(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 開(kāi)發(fā)者官網(wǎng) 關(guān)于 SKAdNetwork 的文檔^[38]。

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

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

約束范圍（Restricted）：無(wú)論是 campaign_id 還是 trigger-data，所有用于歸因的數(shù)據(jù)，都進(jìn)行了相應(yīng)的 bit 位數(shù)的限制，很大程度上避免了精準(zhǔn)的信息泄露；

事件聚合（Aggregated）：一次點(diǎn)擊產(chǎn)生的后續(xù)所有轉(zhuǎn)化事件，都按照一定的規(guī)則（PCM 是通過(guò) Priority，SKAN 則是時(shí)序）會(huì)進(jìn)行聚合，最后上報(bào)的只會(huì)有一次轉(zhuǎn)化事件。

延遲發(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 方案。由于原理一致，就不再對(duì)流程進(jìn)行細(xì)致分析了，只分析一下細(xì)節(jié)上的不同：

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

延遲上報(bào)：PCM 為 24 - 48 小時(shí)，AEM 最長(zhǎng)為 72 小時(shí)（3 天）；

當(dāng)然，如何儲(chǔ)存在本地、優(yōu)先級(jí)匹配和延遲上報(bào)，都依賴于 Facebook App 自己的實(shí)現(xiàn)，通過(guò)這種「自我約束」行為，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)可的問(wèn)題，還在進(jìn)行中，目前一切尚不明朗，后續(xù)有任何進(jìn)展，會(huì)隨時(shí)同步。

Federated Learning of Cohorts (FLoC^[41])

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

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

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

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

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

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

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

接著，B 訪問(wèn)了某個(gè)賣(mài)鞋的電商網(wǎng)站：

該網(wǎng)站向 B 的瀏覽器請(qǐng)求了他的 Cohort：1354，接著 B 看了看登山靴，B 網(wǎng)站記錄下「一個(gè)來(lái)自 Cohort 1354 的瀏覽器可能對(duì)登山靴感興趣」；

該網(wǎng)站定期聚合數(shù)據(jù)，并向廣告平臺(tái)如 TT4B 共享關(guān)于 Cohort 和產(chǎn)品興趣的信息。

接著，A 訪問(wèn)了某個(gè)新聞網(wǎng)站：

該網(wǎng)站向 A 的瀏覽器請(qǐng)求了他的 Cohort：1354；

該網(wǎng)站向廣告平臺(tái) TT4B 請(qǐng)求廣告，包含了 A 的 Cohort 1354

廣告平臺(tái) TT4B 為 A 提供相關(guān)的廣告，主要來(lái)自兩方面的數(shù)據(jù)：

新聞網(wǎng)站提供的 A 的 Cohort 信息；

電商網(wǎng)站提供的「來(lái)自 Cohort 1354 的瀏覽器可能對(duì)登山靴感興趣」

新聞網(wǎng)站展示廣告：????

以上的 A 和 B 是為了表述，實(shí)際過(guò)程中，個(gè)人信息并不會(huì)向任何相關(guān)方泄露。可以認(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ì)算來(lái)源，如果想要 Opt-out，可以通過(guò) HTTP 的 reponse header 來(lái)進(jìn)行：

Permissions-Policy:?interest-cohort=()

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

安全隱患包括：

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

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

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

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

值得注意的是，FLoC 只是 Google 提出的 Privacy Sandbox^[49] 的一部分，由于這個(gè)點(diǎn)比較有意思，所以單獨(dú)拿出來(lái)分享。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)目包含了一系列的提案：

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

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

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

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

第一方落地頁(yè)

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

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

（線索收集 DEMO）

結(jié)語(yǔ)

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

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

關(guān)于奇舞團(tuán)

????????奇舞團(tuán)是 360 集團(tuán)最大的大前端團(tuán)隊(duì)，代表集團(tuán)參與 W3C 和 ECMA 會(huì)員（TC39）工作。奇舞團(tuán)非常重視人才培養(yǎng)，有工程師、講師、翻譯官、業(yè)務(wù)接口人、團(tuán)隊(duì) Leader 等多種發(fā)展方向供員工選擇，并輔以提供相應(yīng)的技術(shù)力、專業(yè)力、通用力、領(lǐng)導(dǎo)力等培訓(xùn)課程。奇舞團(tuán)以開(kāi)放和求賢的心態(tài)歡迎各種優(yōu)秀人才關(guān)注和加入奇舞團(tuán)。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

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

生活随笔

生活随笔

编程问答

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

總覽

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

通過(guò)媒介定向

通過(guò)內(nèi)容定向

通過(guò)意圖定向

通過(guò)用戶畫(huà)像定向

根本問(wèn)題是什么？

PC 時(shí)代

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

有了 User ID 之后呢？

單主體

多主體

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

Web 間

讓 user ID 難以獲取

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

App 間

讓 User ID 難以獲取

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

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

General Data Protection Regulation (GDPR^[20])

California Consumer Privacy Act (CCPA^[22])

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

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

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])

第一方落地頁(yè)

結(jié)語(yǔ)

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

參考資料

關(guān)于奇舞團(tuán)

總結(jié)

编程问答

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

總覽

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

通過(guò)媒介定向

通過(guò)內(nèi)容定向

通過(guò)意圖定向

通過(guò)用戶畫(huà)像定向

根本問(wèn)題是什么？

PC 時(shí)代

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

有了 User ID 之后呢？

單主體

多主體

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

Web 間

讓 user ID 難以獲取

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

App 間

讓 User ID 難以獲取

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

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

General Data Protection Regulation (GDPR[20])

California Consumer Privacy Act (CCPA[22])

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

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

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])

第一方落地頁(yè)

結(jié)語(yǔ)

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

參考資料

關(guān)于奇舞團(tuán)

總結(jié)

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])