Apple CEO Tim Cook 受訪表示再過不久 iOS 14.5 就要正式上線。從 2020 年中的蘋果開發者大會 WWDC 中就已經公佈了新的隱私政策，表示將會針對下載 App 的使用者一一詢問是否開放 IDFA 追蹤權限。此舉造成業內一片譁然、牴觸聲浪太大，導致蘋果將這個政策又延到了 2021 年讓廠商有調整空間。然而目前為止真正針對 iOS 14.5 政策有所應變的應用廠商仍不到 1%。
當 IDFA 滅亡後，將造成精準定位行銷再也不復存在、導致廣告平台和廣告主的嚴重損失。事實上，「保護用戶隱私」與「精準行銷」向來是個亙古存在的悖論，蘋果是怎麼針對這個問題提出最終的解決方案？
答案是 iOS 14.5 即將上線的 SKAdNetwork。
究竟什麼是 IDFA？IDFA 是怎麼讓你感覺「被監聽」？SKAdNetwork 這張蘋果針對保護用戶同時做廣告追蹤所交出的答卷又是什麼樣的技術？SKAdNetwork 對廣告主而言存在的重大挑戰有哪些？
包括 Wall Street Journal 在內等多家國內外媒體都在這陣子針對 iOS 14.5 有非常多的報導，但關於上述問題卻少有媒體給出清楚的解答。甚至目前為止只有 1% 不到的應用廠商有針對 iOS 14.5 採取應變措施。
讓我們直接打開蘋果開發者官方文件，細部解構蘋果官方到底是採取什麼樣的行動、探討行動廣告產業將走向何方，和廠商該如何因應。
另外，本篇文會大量使用到第一集跟大家介紹到的觀念和術語，歡迎大家能先參考本系列的第一篇文《數位行動廣告生態到底是什麼？保證你是第一次看懂！》再來看這篇文章。（老話一句，本文一樣是超過一萬字的乾貨文，讀者可以存下來慢慢品味）
三大廣告用戶辨識與廣告歸因方法
還記得在本系列最一開始的時候我們提到在行動廣告世界所面臨的核心問題──失去 Cookie、呈現碎片化的行動廣告世界中，廣告主到底該怎麼追蹤每一個消費者並衡量廣告成效嗎？事實上，市面上仍有許多技術來克服這樣的難題。下面我們就要來針對最常見的三大針對 App 廣告追蹤歸因的方法來作說明。
(1) Google Play Install Referrer：Google 安裝推薦網址
僅適用於 Google Play。這是一套類似於 UTM 追蹤的廣告參數傳遞機制（UTM 的全名是 Urchin Tracking Module，作法是將原本的網址後面連接一段參數，只要點擊到帶有這段參數的連結，GA 都會記錄其來源與在網站中的行爲）。
比如 TikTok 這個 App 在 Google Play 裡面的網址是：https://play.google.com/store/apps/details?id=com.zhiliaoapp.musically
你可以把請將referrer參數添加到直接指向 Google Play 商店的該 App 網址，並將該參數的值設置為用來描述來源的字符串，如下例所示：
比如 TikTok 這個原本的應用商店網址，最後加上表格中的來源說明參數（綠色字體）之後，就會變成：
https://play.google.com/store/apps/details?id=com.zhiliaoapp.musically&referrer=utm_source%3Dgoogle%26utm_medium%3Dbanner%26utm_term%3Dmusic%26anid%3Dadmob
接著我們可以向 Google Play 商店傳遞這個自訂參數。當使用者點擊帶有廣告來源參數的連結跳轉到 Google Play 商店、並下載該 App 後，Google Play 會在該 App 第一次被開啟的時候，發送一個 INSTALL_REFERRER 廣播告知 App 這個用戶成功下載它的廣告來源，讓 App 接收這個參數。接著這個 App 會上報該 referrer 參數到廣告主後台，從而確定該轉化的來源。
這種做廣告追蹤的方法非常可靠，可惜只有在 Google Play 裡面支援、iOS 或非 Google Play 商店的安卓機都無法使用。同時也只在下載 App 的時候才有意義，也就是在衡量 CPI 的時候才有用。如果只是 CPM、CPC 或是已經下載 App 後的 CPA，那基本上沒什麼用處。
(2) Identifier Matching（IDFA / GAID）：廣告識別符匹配
適用於 iOS 和 Google Play。也是這次 iOS 14 新聞鬧的最沸沸揚揚的追蹤方法。最早開始的時候，開發商可以取得每一台裝置的專屬識別碼來打廣告或做利用，但後來為了用戶隱私保護的關係，從 iOS 6 開始改成廣告識別碼 （Identifier for Advertising, IDFA），能讓廣告主用來追蹤使用者。
每台 iOS 裝置都有一組 IDFA 識別碼、類似臨時身分證；臨時意味著使用者可以隨時重置。以 iOS 13 的使用者來說，可以透過設定 > 隱私權 > 廣告的路徑執行重置廣告識別碼。如果想用全面停用的話，也可以啟用限制廣告追蹤（Limit Ad Tracking, LAT）這項裝置設定，讓廣告主無法使用 IDFA。
IDFA 之所以會是廣告主仰賴的關鍵有兩個原因，一是關閉的路徑不明顯、二是 IDFA 的開啟和關閉是在裝置階層而非應用階層。
路徑不明顯的意思是，會知道 IDFA 並特地跑去隱私權頁面重置 IDFA，或啟用限制廣告追蹤的蘋果手機用戶微乎其微，畢竟要跑到隱私權頁面裡面把深藏的 IDFA 找出來重置或關掉超級麻煩（我相信至今聽過 IDFA 的使用者應該不多）。第二點則意味著 IDFA 一旦開啟，就是針對整支手機上的應用都有權限取得，被安裝的應用不需要一次次特別去請求 IDFA 授權。
另一方面，以 Google Play 這邊的安卓機用戶來說，除了第一點提到的 Install Referrer 方法之外，也有一個相對於 iOS IDFA 的廣告識別碼，稱為 GAID（Google Advertising ID），也就是每一台 Android 裝置都一樣有一組 GAID 識別碼，跟 IDFA 一樣可重置。
還記得我們說到第一點的 Google Play Install Referrer 只能適用在用戶下載一款 App 的場景嗎？但 IDFA 和 GAID 的用途則廣泛多了。除了追蹤下載的裝置之外，也可以知道該裝置對於不同廣告的點擊、瀏覽等，幫助廣告主全方位掌握 CPM、CPC、CPI 等指標、也就是說廣告識別符匹配是最精準、同時適用範圍也最廣的廣告轉化歸因方式。
IDFA 是怎麼讓你感覺被監聽？
場景可能是這樣的：使用者下載了一款飲食紀錄 App，接著你打開 Facebook、突然發現自己的動態消息有一大堆關於減肥瘦身或健康飲食之類的廣告；同時在這款飲食紀錄 App 當中，你也突然發現你之前留在 Facebook 的個人興趣資訊（比如關注科技或時尚領域）出現在這個 App 的 Banner 廣告上。感覺是不是有點毛骨悚然…？這都是因為 Facebook 和飲食紀錄 App 兩者透過 IDFA 比對到你是同一個使用者。只要有 IDFA，要知道你下載的 App、你的購買紀錄或定位資訊通通都不是問題。
蘋果 iOS 14 新政策將如何造成所謂「IDFA 已死」？
但廣告主要面臨的大問題來了，以蘋果手機端來說，iOS 14 在今（2021）年初正式上路之後，會預設 App 無法取得 IDFA。App 必須個別向使用者要求授權，才可拿到 IDFA。也就是說，使用者打開 App 的時候會被詢問第一次「要允許 App 追蹤您在其他公司 App 和網站的記錄嗎？」同時這段文字主標題 App 廠商不能做修改。
如果使用者點選了不要追蹤，那 App 廠商就無法得到 IDFA 資訊。同時 App 只會跳出一次視窗，之後不會再開啟。在「IDFA 預設關閉」加上「即使 App 詢問用戶多半也會不允許追蹤」的前提，相較於之前 IDFA 在系統中預設開啟的情況下，等同於 IDFA 直接宣告死亡。
(3) Fingerprinting：指紋匹配
適用於任意手機裝置。除了 Google Play Install Referrer 和 IDFA/GAID，事實上廣告主還有第三種方式去追蹤，尤其不只是在手機裝置、在網頁瀏覽器上面也非常普及且古老的一種方式，叫「Fingerprinting」。
瀏覽器不用 Cookie 一樣能抓的到你
以下用提供瀏覽器訪問者辨別追蹤服務的 FingerprintJS 網站來為大家舉例，讀者也能用這個網站玩玩看。透過登入後的瀏覽器，可以發現無論是採取使用者身分登入瀏覽器、還是使用無痕模式的狀態下，FingerprintJS 網站定義我的使用者 ID 兩組代碼一模一樣，同時也可以辨別出我的 IP 位址和我的裝置資訊，比如它發現我是一個跑在 Windows 10 作業系統上的 Chrome 瀏覽器等資訊。
瀏覽器能夠知道本地的 IP 位址、作業系統，或是針對字型選用、螢幕大小使用習慣做過調整（比如有些人就是喜歡把瀏覽器設定在 110% 大小），甚至如果我們有授權瀏覽器 Web RTC 取得電腦硬體權限，也可以掌握到電腦本身有幾個音訊輸入/輸出裝置、鏡頭等資訊，只要把所有的特徵（Feature）拿去跑機器學習，要能識別出一個 Unique User 的準確率遠遠比你想像地還高，詳細資訊可參考 BrowserLeak 網站。這也是為什麼即便換了不同的瀏覽器分頁，Fingerprinting 網站仍能定位到同一個人。
很多人會好奇，包括 Chrome、Firefox 在內等主流瀏覽器陸續停用第三方 Cookie 到底對廣告追蹤是否會產生影響；然而關於實現追蹤這件事，還是有很多技術手法，舉例來說﹔當使用者連入一個網站時，可以把使用者先導到第三方網站、Fingerprint 完之後再導回來，在這幾秒的期間使用者完全不會有感覺。（在使用 Facebook 等社交平台前後，陸續看到同一項商品的廣告而感到自己彷彿被「監聽」了，原因也是因為 Facebook 也很常 Fingerprint 使用者。）
手機上的指紋辨識技術更細節
但你可能更想問的是﹔電腦瀏覽器可以做 Fingerprinting，那手機能夠實現嗎？效果有瀏覽器好嗎？這邊要告訴讀者一件驚人的事實——手機能被看到的東西更多、做 Fingerprinting 比起電腦更加容易。
手機應用能取得的權限和資訊都非常多，比如作業系統在什麼時間點更新、有沒有充電、有沒有拍照… 假設有一台手機更新了 iOS 版本，然後該手機當中有兩款 App 都整合了某個歸因或數據分析公司的 SDK，這兩個 App 都發現自己的某個使用者在同一天同一時間更新了作業系統，如此一來就有極高的機率推斷這兩名各自 App 的使用者，事實上是同一個手機裝置持有者。
然而畢竟 Fingerpringting 是根據多方因素來做猜測、而且使用者層級的顆粒度不夠細，比如有一批使用者都用最新款 iPhone、最新的 iOS 版本、語言英文、連外 IP 位址顯示結果相同… 要能抓出獨立的使用者其實也有一定困難度，因此廠商多會透過交叉比對的方式來做使用者驗證，比如同時用上 IDFA 和 Fingerprinting；Android 就更方便了、可以有 Google Install Referrer、GAID、Fingerprinting 三重驗證。
目前 Android 手機上有 15% 使用者歸因是透過 Fingerprinting 來做匹配；iOS 手機比率則更高、超過 20％。主要原因就在於缺乏像 Google Install Referrer 這樣官方給出來的下載驗證機制。在未來 IDFA 形同死亡之際，相信透過 Fingerprinting 來識別 iOS 用戶的比率又會再更高。畢竟，Fingerprinting 是唯一不會受到政策調整影響、也可以當作是最簡單的解決方案。
SKAdNetwork：後IDFA時代的歸因新政策
講了那麼多次蘋果在 2020 年 9 月就宣布的 IDFA 已死，那蘋果到底會用什麼樣的新歸因方法，在保留用戶隱私的前提，來作為廣告主追蹤廣告成效的方式呢？這邊就不能不提「SKAdNetwork」。
SKAdNetwork 技術並不會追蹤看過廣告而下載的「單一特定用戶」數據，而是換了個角度、針對「廣告活動」本身來回饋整體用戶行為資料，比如這個廣告貢獻了多少個使用者下載、下載的使用者當中又有多少人在一定時間內在這個 App 上消費超過 10 美金…等，以整體用戶表現的數值來取代「看完這個廣告下載的使用者是誰、這個人花了多少錢或做了什麼行為」。
SKAdNetwork 具體原理
讓我們透過蘋果官方網站的說明文件來看看這件事情是怎麼實現的。在這個故事中的參與者有三位：
- Ad Network：廣告網路
- Source App：展示廣告的 App，即下圖的 App A
- Advertised App：打廣告的 App，即下圖的 App B
來帶入一個案例讓這個故事更清楚吧！假設手遊《明星三缺一》透過 AdMob 在社群平台《Dcard》上面打廣告，就可以替換成：
- Ad Network：Google AdMob
- Source App：Dcard
- Advertised App：明星三缺一
這裡解構一下這張流程圖所代表的意義：
AdMob 首先會針對《明星三缺一》來簽章（註一）、來確保這一則廣告活動的確就是出自這個廣告平台；簽章指的是 Ad Network 宣告「這個 Campaign 是我發的、且 Campaign ID 是這個」別人沒辦法偽造。畢竟可能有人會透過假造廣告的方式來假造曝光率。
註一：數位簽章用途是確認一則訊息的確就是出自發送人。假設 A 要傳訊息給 B，但是 B 要如何確認訊息真的是由 A 發送的呢？只要 A 在發送訊息前利用自己的 Private Key 將訊息加密再傳給 B，B 再利用 A 的 Public Key 進行解密。
AdMob 也會同時跟蘋果登記這個簽章，蘋果就會知道這則廣告是來自「這個 Ad Network 當中的這個 Ad Campaign」。（具體來說，Ad Network 會把它的 Public Key 給蘋果）
廣告形式可以是蘋果的 StoreKit-Rendered Ads——這種廣告類型會在使用者點擊時一則廣告，比如打手遊看到一個廣告 Banner 時、直接呼叫 App Store 裡跳轉到該廣告 App 的下載頁面引導使用者直接下載；也可以是 App 自定義的瀏覽型廣告：如果廣告沒有接入 StoreKit，使用者看完廣告後自行去 App Store 搜尋後下載，稱為 View-Through Ads（瀏覽型廣告）。蘋果在 2021 年 2 月發布的文件中說明在最新的 iOS 14.5 版本中 StoreKit-Rendered 和 View-Through 兩種廣告類型都有辦法做歸因。
接著 AdMob 會把這個簽章過的廣告根據廣告主需求投放《Dcard》上，接著會有《Dcard》的使用者點擊了這則廣告、導到 App Store 之後下載了《明星三缺一》。從看到 StoreKit-Rendered Ad 到歸因下載，蘋果規定了 30 天的歸因期間、View-Through Ad 則是 24 小時。
安裝後，此時《明星三缺一》會把安裝驗證資訊先存在本地裝置上但不做任何動作。
只有到使用者在蘋果規定的 60 天歸因期間打開了這個 App 時，《明星三缺一》才會呼喚函數registerAppForAdNetworkAttribution()生成一個安裝通知儲存在蘋果那邊，讓蘋果可以去通知 AdMob 說「你這個廣告活動成功貢獻了一個下載啦！」但這邊要注意的事情是，此刻《明星三缺一》只是生成安裝通知而已、還沒有正式回傳（Postback, 註二）。（這是個可選項，廣告主也可以立刻回傳安裝通知給 AdMob 後從此停止追蹤這個用戶，只是幾乎沒人會這麼做來放棄追蹤廣告轉換）
當蘋果後續去通知 AdMob 時，蘋果一樣會針對這個安裝通知做加密簽章，而且給 AdMob 的安裝資訊只會有 Campaign ID，不會包含使用者或裝置相關的認證資訊。
註二：這裡的回傳 Postback 是專有名詞，代表 Client（本地伺服器）對 Server（遠端伺服器）做了傳送資料的動作（Request）。
那到底什麼時候才會回傳通知？如果選擇繼續追蹤用戶，讀者可以注意到上圖 App B 當中還有一個函數是updateConversionValue(_:)。它的用途是什麼？
當使用者開啟《明星三缺一》並觸發updateConversionValue(_:)函數之後，會開啟一個 24 小時倒數計時器，接著這個函數會根據 App 使用者後續在 App 內的操作，比如點讚之類的活躍行為或消費金額，逐步更新一個叫 conversionValue 的變數。
Conversion Value：取代單一用戶 ID 的用戶價值數值
精彩的來了！這個故事最關鍵的地方就在於 Conversion Value 這個值，也是我個人認為蘋果工程師最驚人且創意的想法。讓我們一樣回歸到官方文件說明這個變數的意義。
可以看到這是一個長度為 6 bit 的數值，unsigned 意味著無負號整數、從 0 往上加。那我們該怎麼理解「長度為 6 bit」這句話？這是個二進位，意味著總共會有 000000 – 111111 、也就是十進位 0 – 63 共 64 組數字（2 的六次方）。
廣告主 App 或 Ad Network 可以自定義這 64 組數值分別代表的意義更新到conversionValue；從用戶安裝後開啟應用的當下，會在 24 小時的時間內，從 0 開始起算。
那什麼時候會往上疊加 1 呢？只要在 24 小時之內，使用者做了某個定義中的行為，就會往上更新 conversionValue。舉例來說廠商需要事先定義好以下數值分別代表的行為：
- 000000：安裝後開啟 App
- 000001：使用者點了 10 個讚
- 000010：使用者花了 5 美金
- 000011：使用者在遊戲內升到等級 10
- …
- 111111：使用者消費了 3,000 美金
我們能注意到一件對廣告主來說十分有挑戰性的事情：這個變化是單向的，不會往下減、因此只有最多 64 個事件可供定義，但使用者的操作行為又那麼多，到底該列入哪些行為定義事件呢？觀察一下，如果採用上面的定義會有個問題發生：如果使用者一開始就在遊戲內升到 10 等、再花費了 5 美金，數值也沒辦法從 000011 倒回 000010，導致「花費 5 美金」這個事件就無法被有效追蹤、也白白浪費了一個追蹤額度。
因此最好的事件定義方式是行為本身是同定義且不可逆的，比如通通都是累積金額、或累積使用時間等，才更方便做追蹤計算，否則才 64 個可定義事件很容易就被浪費掉。也可以發現無論是只有區區 64 個事件、或是一次只能追蹤一個單一面向（比如消費金額或使用者參與度）都是蘋果故意為之不讓廣告主輕易就能追蹤到某個特定用戶。
另外，每次符合條件的呼叫，不但 Conversion Value 會更新，同時這個 24 小時會重計算一次，只要 24 小時內有合法呼叫、就會重計一次 24 小時，直到 24 小時內沒有再更新 Conversion Value，Apple 會停止計算、並把最終這個 Conversion Value 的結果回傳給 Ad Network。
讓我們用一個簡單的例子來做說明：
- 使用者在 1/1 下午 5 點安裝並打開了《明星三缺一》，呼叫
updateConversionValue(_:)將conversionValue更新為 0，開始起算 24 小時 - 1/2 下午 2 點使用者消費了 1,000 元、
conversionValue照自定義更新為 10，開始起算 24 小時 - 1/3 早上 9 點使用者再消費了 2,000 元，
conversionValue照自定義更新為 20，開始起算 24 小時 - 1/4 下午 2 點使用者花了 5,000 元，
conversionValue照自定義更新為 63，開始起算 24 小時 - 1/4 之後使用者再也沒有在《明星三缺一》消費過
- 蘋果將最終的
conversionValue和對應的ad-network-id、campaign-id、source-app-id等資訊回傳給 AdMob
根據這個案例，讀者覺得最後回傳的 Conversion Value 是什麼？
答案是 20，而非 63。為什麼？原因在於我們提到只要有一次合法呼叫更新 Conversion Value，就會重新起算 24 小時；在這個案例中最後一次在 24 時間限制內的合法呼叫是 1/3 早上 9 點；1/4 早上 9 點之後就已經超過 24 小時的限制，導致當天下午發生的行為無法再呼叫更新 Conversion Value，上述 1/4 下午 2 點使用者花了 5,000 元後，「conversionValue照自定義更新為 63，開始起算 24 小時」事實上是不會觸發的事件。
也就是說，AdMob 會知道你安裝後打開《明星三缺一》的前 24 小時，或是最長距離使用者開啟 App 後、連續 64 個 24 小時內的定義內使用行為。64 個 24 小時代表每次都是時間到 23:59:59 使用者才突然又有了一個定義內的行為、更新了 Conversion Value，讓 24 小時重新起算。
你可能也會注意到一件事：如果使用者是在 24 小時之內就一口氣消費到了 5,000 元、直接到 63 呢？這樣還會繼續延長 24 小時嗎？
答案是不會。還記得我們說重起算 24 小時的定義是「更新 Conversion Value」嗎？到最大值 63 的時候 Conversion Value 事實上已經無法再往上加、無法更新 Conversion Value，意味著追蹤活動停止。所以根據不同使用者的行為，每個使用者被追蹤的期限都不同，如果在短時間內快速觸發所有動作反而會更快結束追蹤，期間可能是 24 小時、也可能長達 154 天（StoreKit-rendered Ad →30 天 → 下載 → 60 天 → 首次開啟 → 64 天 → SKAdNetwork Postback）。
簡單來說，就是有兩種結果都會讓蘋果 SKAdNetwork 停止這次的廣告歸因追蹤行為：
- 計算的 24 小時內使用者沒有發生定義的行為事件
- Conversion Value 封頂達到 63
只能知道每個廣告活動大致成效、而非透過單一用戶組合出整體用戶畫像
蘋果會把最終的 Convesion Value 值和歸因廣告資訊綁在一起、回傳給 Ad Network。但是在上面的故事中，Ad Network，也就是 AdMob 無法知道確切這個 Conversion Value 是 20 的人具體到底是哪個使用者。
只會知道：「這個在《Dcard》上的 Campaign 總共有 100 個達到 Conversion Value 是 20 的人，也就是給《明星三缺一》貢獻的總收入是 2,000元*100人 = 200,000 元」。另外這部分資訊《明星三缺一》與《Dcard》什麼都不會拿到，過程只會發生在蘋果和 AdMob 之間，意味著 Advertised App 或 Source App 如果想要知道相關資訊還得去跟 Ad Network 申請。
傳統上廣告主 App 可以透過 IDFA 來做分析並組合成用戶畫像，廣告投放也可即時地針對單一用戶的行為來做即時調整。但這個這個邏輯在 SKAdNetwork 出現之後徹底無效，無法即時蒐集到使用者數據，畢竟最少要等 24 小時、最長要等 154 天之後才能拿到回傳的數值，也無法隨時改變廣告投放方式。
更嚴重的是，即便把消費金額定義為 Conversion Value 的更新方式，最後拿到的也不一定就等於最終實際金額；這得看更新金額顆粒度的設定大小，如果設定是每多消費 20 美金才往上加一、那如果時間內只消費 5 美金的呢？其中的可能誤差非常大。
也因此，廣告主除了要面對延遲問題，還得針對 Conversion Value 更新的方式有自己獨到的想法──如何不浪費這 64 個事件？
可以單純用消費金額來定義、或用使用者活躍留存的表現、還可以用行為漏斗來定義，比如：註冊會員 → 訂閱方案 → 分享付費內容 → 註冊並分享。
換個角度想，你也可以犧牲幾個 bit 來故意延長追蹤的時間，比如「只要使用者在 24 小時之內沒有做任何操作、那我就更新 Conversion Value」來故意觸發延長追蹤時限。這當中的操作空間都非常大。
SKAdNetwork 參與者角色總結
總而言之，我們重新回顧一下這張流程圖：
SKAdNetwork 當中的三種角色和各自的職責不言而喻：
- 廣告平台（廣告平台, AdMob）的工作
- 在蘋果上註冊自己的 Ad Network ID 並提供給 App 開發商
- 為展示廣告的 Source App 提供經數位簽章的廣告
- 透過註冊蘋果時填寫的 URL 接收安裝驗證通知
- 驗證蘋果給的 PostBack 通知
- Source App（展示廣告的 App, Dcard）的工作
- 將 Ad Network ID 放到 Info.plist 文件
- 展示經過數位簽章過的廣告
- Advertised App（被廣告的 App, 明星三缺一）的工作
- 透過呼叫
registerAppForAdNetworkAttribution()或updateConversionValue(_:)回傳應用安裝通知驗證給蘋果 - 呼叫
update更新 Conversion Value （可選）Conversion Value(_:)
- 透過呼叫
SKAdNetwork 對於廣告主和廣告平台的新困難與挑戰
我們也簡單總結 IDFA 消失、 SKAdNetwork 出現之後，對行動廣告主在可以視為挑戰（悲劇）的因素：
- 蘋果回傳數值有延遲問題，可能 24 小時或最長 154 天
- 蘋果只會把數據給 Ad Network、如果廣告主想知道結果還得跟 Ad Network 對接
- Conversion Value 不一定等於最終消費者行為加總（比如不等於消費金額）
- 以單一面向作為 Conversion Value 的定義後，難以同時追蹤其他面向的指標（比如很難同時把活躍時間和消費金額同時設為定義事件）
- 每個 App 在每個廣告平台上最多只能設置 100 個 Ad Campaign、超過的廣告也無法追蹤歸因
- 廣告主和 Ad Network 掌握單一用戶行為來調整個人的客製化廣告
SKAdNetwork 完全顛覆了過往平台們對廣告歸因的做法，也是蘋果對於「保護單一用戶隱私的同時要又能追蹤廣告成效」顛覆數千億行動廣告產業的創舉。可能會有很多的流量在無法精確被追蹤之下，比如第三方歸因廠商 Appsflyer 即稱在這個架構下預估有 1.5% 的廣告流量將因為歸因失敗而被計為自然流量。當然廣告主可以因此少付一些錢，但對於廣告變現的 App 或是廣告平台也會蒙受不小的損失。
結語：蘋果爸爸有夠狠
我們今天介紹了傳統進行廣告歸因的三種方式：
- Google Install Referrer：僅適用於 Google Play，Google 官方針對安裝的歸因
- IDFA/GAID：適用於 iOS / Google Play，但蘋果 iOS 14 出現之後 IDFA 滅亡
- Fingerprinting：適用於任意裝置，最直接但有一定誤差的做法
也針對蘋果把 IDFA 滅掉的情況下，談討了最新 iOS 14 政策出來後針對用戶隱私保護的 SKAdNetwork 的創新歸因辦法──以廣告 Campaign 後續的用戶群體行為，來取代追蹤單一用戶。
當然在未來廣告廠商們還是得面臨各式各樣的新挑戰，只能說用戶隱私畢竟是大勢所趨、只是誰也不知道蘋果會做這麼絕，畢竟蘋果不靠廣告營利、但 Facebook 和 Google 等互聯網廣告巨頭這波衝擊之下都蒙受不小的損失。（最狠的商業步數不是你覺得對方只有很小的機率會採取這個行動、而是完全沒辦法想像到對方會這麼做的程度）
另外，Appsflyer 等第三方歸因廠商向來仰賴 IDFA 來做用戶歸因，在這一波衝擊下的戰略性產品調整和新解決方案也是很值得關注的議題，我們會在下一篇文章與大家做說明。請大家敬請期待！
