中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：在今年的蘋果開發(fā)者大會上，蘋果發(fā)布了iOS 14等軟件的更新，并且特別強調(diào)iOS14將支持AppTrackingTransparency（簡稱ATT）和SKAdNetwork。本文作者從這一消息出發(fā)，對?iOS 14 ATT和SKAdNetwork展開了全面解讀，與大家分享。

在2020年的WWDC20上，Apple發(fā)布了iOS14，并且特別強調(diào)iOS14將支持AppTrackingTransparency（簡稱ATT）和SKAdNetwork，看似微小的更新，對互聯(lián)網(wǎng)廣告行業(yè)的影響則是7.0地震級的。

ATT的更新使開發(fā)者獲取用戶的IDFA需要彈窗并經(jīng)過用戶的同意，提高了用戶隱私透明度。而根據(jù)歷史經(jīng)驗，至少40%的用戶不會同意，更不用說權(quán)限申請彈窗上還要提示為了向用戶提供更精準的廣告推薦。當然，某些APP會讓用戶必須同意授權(quán)IDFA，否則不提供服務，這種容易被Apple以用戶歧視的理由下架，更不可取。目前，iOS上的廣告生態(tài)中從定向到歸因都是基于IDFA之上，影響面可想而知。

SKAdNetwork2.0是由1.0升級而來，以解決上文中提出的IDFA帶來的安裝和轉(zhuǎn)化歸因問題。簡單來說，廣告平臺需要注冊成為Apple的一個廣告網(wǎng)絡并提供一個回調(diào)地址，當用戶通過此廣告網(wǎng)絡的廣告下載并打開了廣告主的APP之后，Apple會把安裝等信息傳到回調(diào)地址。整個流程中有很多細節(jié)問題，具體看下文。

ATT和SKAdNetwork2.0的更新，不僅代表著Apple更注重用戶隱私透明度，也代表著Apple開始插手廣告歸因，想作為應用商店在廣告歸因中分一杯羹，并為未來更大的廣告業(yè)務做準備。

先說影響面：

此次更新，主要影響的是通過設備號跟外部進行交互的事物上，包括以下：

1. 安裝和轉(zhuǎn)化歸因，在獲取不到IDFA時要有新的方案，例如SKAdNetwork2.0；廣告主要更注意歸因
2. 延遲深度鏈接，廣告主基于IDFA廣告點擊的延遲深度鏈接方案不可行，要有其他方案
3. APP拉新時，已安裝用戶的判斷在獲取不到IDFA時要有新的方案，用Apple提供的方法去查詢是否安裝某個APP
4. APP拉活、老客喚醒時，基于IDFA的用戶定位方案也不再是主流，在獲取不到IDFA時要有新的方案

再說ATT和SKAdNetwork2.0結(jié)論：

1. 通過讀取簽名中的廣告展示ID，廣告平臺仍然可將安裝和轉(zhuǎn)化歸到某一次廣告展示中
2. 安裝和轉(zhuǎn)化回傳的實時性大大降低，會延遲1天到64天之間，且最多傳64種轉(zhuǎn)化，轉(zhuǎn)化價值無法回傳
3. Apple未說明具體歸因邏輯、時長和周期，且給廣告主的信息幾乎為零，未說明如何杜絕廣告平臺作弊
4. 未提供除了IDFA以外其他定向方案
5. 依賴于點擊監(jiān)測和IDFA的延遲深度鏈接不可實現(xiàn)
6. 用戶禁止APP訪問IDFA的概率較高

最后提出幾種解決方案：

1. 通用id方案
2. Id Mapping 方案
3. IDFA+IDFV加密方案

01 ATT

ATT全名是AppTrackingTransparency，是Apple為提高用戶隱私透明度提供的解決方案，獲取IDFA也要符合ATT的要求。目前IDFA需要申請的場景，包括但不限于精準廣告推薦、與數(shù)據(jù)第三方共享設備位置、與廣告網(wǎng)絡共享ID來定位或者lookalike、應用中放置一個第三方SDK用于第三方廣告網(wǎng)絡定向。很明顯，Apple不希望IDFA未經(jīng)用戶允許就用于任何的廣告定向。

此外，Apple還說有兩種情況下，可以跟蹤用戶且不需要獲取用戶許可：

• 當您的應用程序中的員工或設備數(shù)據(jù)僅連接到用戶設備上的第三方數(shù)據(jù)，并且不會以可識別用戶或設備的方式從設備發(fā)送出去
• 與您共享數(shù)據(jù)的數(shù)據(jù)代理僅將數(shù)據(jù)用于欺詐檢測，預防欺詐或安全目的，并且僅代表您使用。例如，僅使用數(shù)據(jù)代理來防止信用卡欺詐。

這兩種情況Apple單獨說出來蠻奇怪的，Apple如何能夠保證開發(fā)者是按照所述要求進行的，而非serve to serve來實現(xiàn)Apple不允許的。如果單從這兩種特殊情況來說，對Apple的ATT執(zhí)行力度是存疑的。

02 SKAdNetwork2.0

SKAdNetwork2.0的整體流程比ATT復雜一些，涉及到的角色也較多，它其實是Apple針對非IDFA的安裝和轉(zhuǎn)化歸因的整體方案，是要廣告平臺、廣告主、媒體共同參與才能夠?qū)崿F(xiàn)的。此外，SKAdNetwork2.0是由1.0迭代而來的，1.0用的人很少，2.0增加了一些參數(shù)和接口。

SKAdNetwork2.0的主要流程

上圖畢竟只是個流程，看不出來一些細節(jié)問題，例如能否把安裝歸因到某一次曝光？具體各個角色都要做什么工作？廣告網(wǎng)絡能否知道轉(zhuǎn)化的產(chǎn)生時間？接下來我們對流程中的每個節(jié)點用到的方法、參數(shù)等進行詳細梳理，才能解決上述問題。

SKAdNetwork2.0的交互流程

1. 廣告平臺去Apple中注冊成為一個廣告網(wǎng)絡，擁有一個廣告網(wǎng)絡id。除了id以外，有公鑰和私鑰一對，用以解密Apple在用戶安裝后回傳的信息，公鑰要發(fā)送給Apple，私鑰自行保存。還要提供一個URL，用以接收SKAdNetwork安裝驗簽回發(fā)請求。

具體請見：https://developer.apple.com/documentation/storekit/skadnetwork/registering_an_ad_network

2. 廣告平臺向媒體提供帶簽名的廣告。簽名是整個SKAdNetwork2.0關(guān)鍵點。

如何生成簽名？

首先，廣告平臺要根據(jù)所使用的SKAdNetwork版本來選擇參數(shù)，若是2.0，則擁有以下參數(shù)可供選擇，版本是指支持的版本：

• SKStoreProductParameterAdNetworkVersion版本2.0。使用API版本值“ 2.0”。
• SKStoreProductParameterAdNetworkIdentifier版本1.0和2.0。在Apple上注冊的廣告網(wǎng)絡id。
• SKStoreProductParameterAdNetworkCampaignIdentifier版本1.0和2.0。廣告系列編號。
• SKStoreProductParameterITunesItemIdentifier版本1.0和2.0。廣告主APP的App Store ID，即itunes-item-id。
• SKStoreProductParameterAdNetworkNonce版本1.0和2.0。是種UUID，是代表每次廣告展示的唯一值。簽名中使用的該隨機數(shù)的字符串表示形式必須為小寫。
• SKStoreProductParameterAdNetworkSourceAppStoreIdentifier版本2.0。媒體APP的應用商店ID。如圖source-app-id中的清單3。
• SKStoreProductParameterAdNetworkTimestamp版本1.0和2.0。代表廣告展示時間

其次，廣告平臺對參數(shù)和值按照Apple要求進行合并，合并成一條字符串。

然后，廣告平臺用密鑰和Apple提供的算法對合并的字符串加密簽名。

最后，將擁有應用調(diào)用和啟動驗簽所需的所有必需的“ 廣告網(wǎng)絡安裝驗簽簽名”值。把簽名放入廣告中，并把廣告推給媒體，因此廣告網(wǎng)絡提供給媒體的API或者SDK都要改動。

具體請見：https://developer.apple.com/documentation/storekit/skadnetwork/generating_the_signature_to_validate_an_installation

3. 媒體在應用中配置廣告網(wǎng)絡id。媒體要在一個文件中把需要支持的廣告網(wǎng)絡id填入，此文件支持多個廣告網(wǎng)絡id，若某廣告網(wǎng)絡id不在此文件中，則不會對此廣告網(wǎng)絡id啟動安裝驗簽。

具體請見：https://developer.apple.com/documentation/storekit/skadnetwork/configuring_the_participating_apps

4. 媒體APP顯示廣告平臺提供的帶簽名的廣告。當用戶在媒體APP上點擊廣告時，媒體APP調(diào)用App Store視圖并代入廣告網(wǎng)絡提供的簽名和驗簽信息，這樣Apple才能知道調(diào)起App Store的簽名，并把簽名帶到下一個流程中去。

具體請見：https://developer.apple.com/documentation/storekit/skadnetwork/ad_network_install_validation_keys

5. 用戶下載安裝廣告主APP。

6. 用戶打開廣告主APP時，廣告主APP要調(diào)用應用安裝驗簽信息方法。方法是registerAppForAdNetworkAttribution()，調(diào)用或者首次啟動時使用，無需填入其他任何參數(shù)，相當于廣告主告訴Apple說這人打開了我的APP了。Apple會等待廣告主APP24小時，若24小時內(nèi)廣告主APP未進入到下個流程，Apple會在之后的24小時之中的隨機時間點向廣告平臺發(fā)起回調(diào)，隨機時間點也是為了用戶隱私吧。PS：其實不需要廣告主調(diào)用，Apple應該也知道這一次的打開，可能有技術(shù)上的難題。

7. 用戶在廣告主APP上產(chǎn)生轉(zhuǎn)化，廣告主APP要調(diào)用更新轉(zhuǎn)化值方法。方法是updateConversionValue(_:)，在產(chǎn)生轉(zhuǎn)化時使用，需要傳一個int值，6-bit，相當于0-63中的某個值，調(diào)用此方法后Apple回調(diào)的時間會推遲24小時。此方法可多次調(diào)用，但是距離上一次調(diào)用安裝（registerAppForAdNetworkAttribution）或轉(zhuǎn)化（updateConversionValue(_:)）不能超過24小時，因為超過24小時的話Apple就會發(fā)起回調(diào)了。多次調(diào)用時，后一次的Value要比前一次的大，否則相當于不生效。因此最多會導致64次調(diào)用后才會回傳給廣告平臺信息。

我認為ConversionValue更像是轉(zhuǎn)化id而非轉(zhuǎn)化價值，廣告主可以基于自身漏斗設計最多64個轉(zhuǎn)化，目前在SKAdNetwork2.0中并不存在轉(zhuǎn)化價值這個參數(shù)。

8. Apple把安裝和轉(zhuǎn)化信息發(fā)送給廣告平臺注冊時填寫的URL上。此時就涉及到如何歸因，可惜這方面Apple在文檔中沒有說得很清楚，例如用戶看了兩個廣告網(wǎng)絡廣告后，在點擊后一個廣告去安裝廣告主APP，此時安裝信息的發(fā)送邏輯，類似問題還有很多。

9. 廣告平臺驗簽收到的安裝和轉(zhuǎn)化信息。此時廣告平臺要支持兩種版本的安裝和轉(zhuǎn)化信息驗簽，且只能通過收到的信息中的參數(shù)與解密后的簽名相驗簽。生成簽名時，用私鑰去加密；收到簽名后，用公鑰去驗簽和解密。具體參數(shù)如下：

• version版本2.0。與匹配的廣告網(wǎng)絡驗簽API的版本。
• SKStoreProductParameterAdNetworkVersionad-network-id版本1.0和2.0。廣告網(wǎng)絡id
• SKStoreProductParameterAdNetworkIdentifiertransaction-id版本1.0和2.0。此驗簽的唯一值；用于對安裝驗簽消息進行重復數(shù)據(jù)刪除。
• campaign-id版本1.0和2.0。展示廣告時提供的與匹配的廣告系列ID 。
• SKStoreProductParameterAdNetworkCampaignIdentifierapp-id版本1.0和2.0。廣告主的APP
  id
• attribution-signature版本1.0和2.0。要驗簽的Apple的署名簽名。
• redownload版本2.0。一個布爾值，指示值為1時用戶重新下載并重新安裝了該應用程序。
• source-app-id版本2.0。媒體的APPid。注意：僅當提供的參數(shù)滿足Apple的隱私閾值時，才會顯示。SKStoreProductParameterAdNetworkSourceAppStoreIdentifiersource-appid
• conversion-value版本2.0。轉(zhuǎn)化id，已安裝的應用程序通過調(diào)用提供的無符號6位值。注意：僅當已安裝的應用程序提供該參數(shù)并且提供的參數(shù)滿足Apple的隱私規(guī)則時，才會顯示。updateConversionValue(_:)conversio

上述參數(shù)中，核心是attribution-signature簽名，若簽名被篡改或者非此廣告平臺的，就會驗簽失敗。通過公鑰對簽名進行驗簽和解密后，就可以得到廣告平臺帶入的簽名加密前的字符串，而字符串中包含了廣告展示ID，即可將安裝轉(zhuǎn)化與廣告展示ID關(guān)聯(lián)起來。（此處很關(guān)鍵，建議實際驗證或者找Apple確認）此外，還可用非簽名的參數(shù)跟簽名內(nèi)的字符串的參數(shù)核對，若有沖突即可舍棄此次回傳。

文檔請見：https://developer.apple.com/documentation/storekit/skadnetwork/verifying_an_install_validation_postback

03 疑問點

1. 歸因相關(guān)

Apple是否涉及到歸因？歸因運算邏輯？歸因時間周期？點擊廣告后沒有下載，在中途沒有點擊其他任何廣告，用戶自行去APP STORE 下載，歸因怎么算？先看A廣告點擊跳轉(zhuǎn)到AppStore，再看B廣告并點擊跳轉(zhuǎn)到AppStore，傳的是A還是B？

2. 參數(shù)相關(guān)

redownload 1和0的具體判斷邏輯是什么？廣告主APP版本跟redownload有啥關(guān)系？conversion-value 轉(zhuǎn)化價值的建議用法是什么？說要滿足的隱私規(guī)則是什么？

3. 簽名相關(guān)

在正常情況下，廣告網(wǎng)絡在生成簽名時候的簽名，跟安裝回傳中的簽名是否一致？若是，則廣告網(wǎng)絡是否要根據(jù)解密后的簽名和其他參數(shù)作對比？若是，則可以通過廣告展示的uuid把安裝和曝光關(guān)聯(lián)起來？若是，則有了廣告展示的UUID，campaignid還有什么用？

4. 反作弊相關(guān)

通過什么渠道向廣告主提供了哪些信息？整套機制是否能有效防止媒體或者廣告平臺作弊？若是，則整套機制為什么能防止？

04 解決方案

1. 通用id方案

這種方案本質(zhì)上是尋找IDFA的替代品，要根據(jù)媒體、廣告平臺、廣告主都能拿到的設備或用戶數(shù)據(jù)，根據(jù)這些數(shù)據(jù)和制定規(guī)則去生成一個IDFA的替代品”某某ID”。難點有兩個，唯一性和多方認可。要有普遍的唯一性，是作為一個ID的必備能力。而且此方案要受到多方認可，才能夠真正對外使用，否則只是另一個IDFV。

2. Id Mapping方案

這種方案本質(zhì)上類似PC WEB的cookie mapping，通過廣告平臺的ID和廣告主的ID Mapping，來解決IDFA的問題。難點也有兩個，如何mapping和如何提高mapping濃度。我有個方案是在A APP調(diào)起/喚醒B APP時進行mapping，但是mapping是要涵蓋拉新、拉活等多種場景的，我這種方案只能解決拉活，而且mapping濃度也無法保證。

3. IDFA+IDFV加密方案

這種方案是adjust提出來的，本質(zhì)上就是看Apple能不能睜一眼閉一眼。首先，在廣告主端的對廣告主的IDFA和IDFV組成一個hash。然后，把這個hash和廣告主的IDFV傳到媒體APP客戶端上。其次，在媒體本地上用媒體的IDFA和廣告主的IDFV組成一個hash。最后，在媒體本地比較這兩個hash是否一致。此方案就是用到了上文ATT標藍的內(nèi)容，認為這種方案不會以可識別的方式把IDFA發(fā)出去。Apple是否認為這種方案就是符合隱私要求的，這是要打個問號的。

總之，Apple的小改動對于整個iOS不算什么，但是在互聯(lián)網(wǎng)廣告中掀起了狂風駭浪，到目前也沒有業(yè)內(nèi)達成共識的解決方案。ATT和SKAdNetwork2.0的推出，確實對用戶隱私是利好，但是也會助長以頭部綜合廣告平臺為代表的圍墻花園態(tài)勢。經(jīng)此一役，大家又回到同一個起跑線上，有風險就有機遇，希望同行同業(yè)能夠一起面對。

#專欄作家#

Vency，公眾號：Vency不二，人人都是產(chǎn)品經(jīng)理專欄作家。海外商業(yè)產(chǎn)品經(jīng)理，關(guān)注海外、廣告、商業(yè)化、營銷等領域，追求用戶、技術(shù)、商業(yè)、社會價值的統(tǒng)一，喜好看書、逛館。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議。