iOS14.5正式上線，后IDFA時(shí)代買量投放、廣告變現(xiàn)、歸因分析的營(yíng)銷策略

4月27日凌晨，iOS14.5正式線上，蘋果將強(qiáng)制執(zhí)行ATT隱私框架，并將推行SKAdNetwork作為歸因方案。從用戶的角度看，隱私保護(hù)進(jìn)一步升級(jí)，那么對(duì)于移動(dòng)廣告主、開發(fā)者、廣告平臺(tái)與歸因平臺(tái)各有什么影響呢？各方如何協(xié)作來(lái)更好的提升客戶的移動(dòng)營(yíng)銷效果呢？

3月4日，由AppsFlyer, Chartboost和Liftoff聯(lián)合舉辦的“聚焦iOS14更新，后IDFA時(shí)代的營(yíng)銷策略”線上研討會(huì)召開。

活動(dòng)內(nèi)容圍繞3部分展開，分別是：

1、iOS 14用戶隱私政策對(duì)行業(yè)帶來(lái)了哪些變化？

2、iOS 14新規(guī)對(duì)移動(dòng)營(yíng)銷各方面帶來(lái)的影響

3、廣告主、開發(fā)者及廣告平臺(tái)及第三方歸因平臺(tái)對(duì)于iOS 14的解決方案

以下為活動(dòng)內(nèi)容整理：

一、iOS 14 用戶隱私政策對(duì)行業(yè)帶來(lái)了哪些變化？

1、蘋果將強(qiáng)制執(zhí)行ATT框架來(lái)保護(hù)用戶隱私，那么ATT到底是什么呢？

Chartboost：ATT是App Tracking Transparency的簡(jiǎn)稱，是蘋果即將強(qiáng)制執(zhí)行的用戶隱私框架。開發(fā)者通過彈窗形式向用戶詢問是否授權(quán)廣告追蹤。它的前身是LAT，即limit ad tracking限制廣告追蹤。在iOS 14以前，蘋果設(shè)置中默認(rèn)用戶允許被追蹤的，而現(xiàn)在是默認(rèn)用戶不允許被追蹤。

收到ATT彈窗后，如果用戶沒有選擇允許廣告追蹤， 那么應(yīng)用就無(wú)法獲取其IDFA等個(gè)人信息。我們也建議開發(fā)者前往iOS開發(fā)者平臺(tái)了解一下如何優(yōu)化ATT的頁(yè)面設(shè)置，提高允許追蹤的比例。

據(jù)我所知，蘋果有一些規(guī)定，例如允許開發(fā)者自主選擇合適的時(shí)機(jī)彈出ATT窗口。所以是在新手教學(xué)階段出現(xiàn)還是在首次打開App時(shí)出現(xiàn)是可以選擇的。另外，蘋果允許開發(fā)者在ATT彈窗之前展示一個(gè)頁(yè)面，對(duì)用戶說(shuō)明為何希望用戶允許廣告追蹤。蘋果方面還是提供了一些解決方案的，但是因?yàn)闀r(shí)間較短，效果如何暫時(shí)不可知。保守估計(jì)，未來(lái)限制追蹤的用戶會(huì)占絕大多數(shù)。

2、iOS 14.5更新時(shí)間及流量增長(zhǎng)趨勢(shì)預(yù)測(cè)

Liftoff：目前蘋果公布的消息是2021年春，但具體時(shí)間未知。Liftoff預(yù)測(cè)iOS14.5更新最早會(huì)在3月中旬，但也可能會(huì)拖延。

iOS14更新之后，到底會(huì)有多少用戶更新到最新版本呢？如上圖所示，根據(jù)iOS14.2和14.3的更新數(shù)據(jù)，我們可以大致知道iOS14.5的更新速度。Liftoff預(yù)測(cè)在40天內(nèi)，會(huì)有65%的用戶更新到最新版本。同時(shí)，由于iOS14.5對(duì)用戶隱私保護(hù)更好，所以實(shí)際的更新速度可能會(huì)更快，65%只是保守的預(yù)估。

3、蘋果還推出了SKAdNetwork歸因機(jī)制。那么SKAdNetwork有什么優(yōu)勢(shì)和挑戰(zhàn)？

AppsFlyer：剛才提到預(yù)計(jì)有65%的用戶會(huì)在iOS14.5版本發(fā)布后的40天內(nèi)更新系統(tǒng)。這就意味著在iOS14.5之后，大量用戶的IDFA是開發(fā)者無(wú)法獲取的。但在這個(gè)生態(tài)下，開發(fā)者依舊需要一個(gè)歸因方案。所以蘋果提供了一種新的歸因機(jī)制——SKAdNetwork。

簡(jiǎn)單介紹一下SKAdNetwork的歸因鏈路。用戶點(diǎn)擊廣告、下載App和之前沒有區(qū)別，接下來(lái)用戶在手機(jī)里激活A(yù)pp的時(shí)候，需要調(diào)用蘋果的兩個(gè)API，一個(gè)是Register API,記錄一次應(yīng)用激活。接下來(lái)如果想記錄用戶的行為事件如注冊(cè)和購(gòu)買事件等，需要調(diào)用SKAdNetwork的Update Conversion Value API，中文是更新轉(zhuǎn)化數(shù)值A(chǔ)PI，去記錄用戶的行為數(shù)據(jù)。

同時(shí)，蘋果在整個(gè)鏈路里引入了倒計(jì)時(shí)器的機(jī)制，當(dāng)你調(diào)用了一次API記錄了用戶的行為數(shù)據(jù)后，需要等待24小時(shí)的倒計(jì)時(shí)器結(jié)束。在這24小時(shí)結(jié)束后，設(shè)備會(huì)在24小時(shí)內(nèi)將歸因結(jié)果發(fā)送給廣告平臺(tái)。這里會(huì)有很多限制，稍后會(huì)詳細(xì)分享。

當(dāng)廣告平臺(tái)收到SKAdNetwork的歸因結(jié)果之后，會(huì)把數(shù)據(jù)發(fā)送給AppsFlyer，AppsFlyer會(huì)對(duì)用戶行為數(shù)據(jù)中的Conversion Value數(shù)值進(jìn)行解析，把它從一個(gè)數(shù)解讀成可讀的信息如login，purchase等。我們會(huì)把解讀出的信息返回給廣告平臺(tái)，供平臺(tái)做優(yōu)化。同時(shí)會(huì)把歸因結(jié)果展示在SKAdNetwork的面板上，供廣告主查看每條廣告的用戶后續(xù)行為效果如何。

大家可以看到，整條鏈路和以前多年來(lái)使用的歸因機(jī)制是有很大區(qū)別的。相信這樣一套有延時(shí)和數(shù)值解析的機(jī)制，會(huì)對(duì)廣告平臺(tái)和變現(xiàn)平臺(tái)有一定的影響。 

4、從廣告平臺(tái)角度，SKAdNetwork歸因機(jī)制對(duì)廣告投放有哪些影響？

Liftoff：過去的投放過程中，我們一直收到AppsFlyer的實(shí)時(shí)數(shù)據(jù)回傳。iOS更新之后，情況是反過來(lái)的——蘋果先傳數(shù)據(jù)給投放平臺(tái)，我們?cè)侔褦?shù)據(jù)傳給AppsFlyer。這會(huì)帶來(lái)幾個(gè)挑戰(zhàn)：

a、轉(zhuǎn)換值：轉(zhuǎn)換值只能設(shè)定64個(gè)事件，其中0默認(rèn)是install，其他事件可以設(shè)為注冊(cè)、加入購(gòu)物車、內(nèi)購(gòu)等。但是這些轉(zhuǎn)換值有24小時(shí)計(jì)時(shí)器的挑戰(zhàn)，也就是說(shuō)今天用戶安裝了App，在24小時(shí)內(nèi)必須完成另外一個(gè)事件，否則Liftoff只是會(huì)收到一個(gè)install回傳的轉(zhuǎn)換值，也就是 0。如果在24小時(shí)內(nèi)，用戶觸發(fā)了另一個(gè)事件，計(jì)時(shí)器會(huì)重新開始。

b. 隨機(jī)延遲：24小時(shí)后，計(jì)時(shí)器會(huì)有一個(gè)0-24小時(shí)的隨機(jī)延遲，再把轉(zhuǎn)換值發(fā)送給廣告平臺(tái)，這代表我們無(wú)法實(shí)時(shí)收到用戶在應(yīng)用內(nèi)的行為數(shù)據(jù)，這會(huì)影響廣告平臺(tái)實(shí)時(shí)的優(yōu)化。但Liftoff已做好了準(zhǔn)備，稍后會(huì)詳細(xì)介紹解決方案。

5、SKAdNetwork歸因機(jī)制對(duì)廣告變現(xiàn)有哪些影響呢？

Chartboost：從廣告變現(xiàn)角度看，雖然我們是以eCPM付費(fèi)給流量供給端也就是開發(fā)者， 但eCPM的計(jì)算基于廣告展示到廣告激活的效果。我們預(yù)估在缺乏IDFA的情況下，可能轉(zhuǎn)化率和預(yù)估eCPM的精準(zhǔn)度會(huì)下降，也就是說(shuō)變現(xiàn)效率和收益都可能會(huì)有降低的可能。

今年程序化購(gòu)買是行業(yè)大趨勢(shì)，In-app bidding就是大家希望能夠解決收益問題的方式之一。從今年3月開始，F(xiàn)acebook要求在iOS開發(fā)者放棄在waterfall的變現(xiàn)，全面改用In-App bidding的方式來(lái)管理自己的流量。所以，In-app bidding是一個(gè)很明顯的趨勢(shì)，還未使用的開發(fā)者現(xiàn)在是很好的時(shí)機(jī)來(lái)加入程序化購(gòu)買的行列，有助于降低風(fēng)險(xiǎn)和提升效率。后續(xù)會(huì)介紹Chartboost的最新適配iOS 14變現(xiàn)解決方案。

6、在歸因方面，SKAdNetwork框架的優(yōu)缺點(diǎn)又是怎樣的呢？

AppsFlyer：首先SKAdNetwor是確定性歸因，蘋果是基于保護(hù)用戶隱私的前提下創(chuàng)建這套框架的，所以說(shuō)這套鏈路是可以最大限度保護(hù)用戶的。并且，由于SKAdNetwork不是基于IDFA做的歸因，所以這套框架的歸因結(jié)果不受限于用戶是否授權(quán)的。也就是說(shuō)，SKAdNetwork可以覆蓋全部用戶的歸因結(jié)果。

但是SKAdNetwork也有一定的局限性，對(duì)于廣告平臺(tái)、變現(xiàn)平臺(tái)、歸因平臺(tái)都會(huì)造成一些問題，主要為以下5點(diǎn)：

1. 未覆蓋所有歸因鏈路：目前最新版SKAdNetwork2.2僅覆蓋到應(yīng)用到應(yīng)用以及應(yīng)用到網(wǎng)頁(yè)的鏈路，很多廣告主會(huì)投放EDM營(yíng)銷，短信營(yíng)銷，二維碼，自有網(wǎng)站流量等，都是無(wú)法覆蓋的。

2. SKAdNetwork數(shù)據(jù)歸因回傳延遲：延遲時(shí)間至少24小時(shí)，如果多次記錄用戶行為，這樣轉(zhuǎn)換數(shù)值的API多次調(diào)用的話，回傳的時(shí)間會(huì)更久，最長(zhǎng)可能要兩個(gè)月以后才能拿到數(shù)據(jù)。

3. 作弊風(fēng)險(xiǎn)：SKAdNetwork框架里有很多節(jié)點(diǎn)是可以被操縱的，導(dǎo)致最終結(jié)果不準(zhǔn)確。

4. 匿名事件回傳：因?yàn)镾KAdNetwork是不基于IDFA做歸因的，意味著回傳的結(jié)果里是匿名事件回傳，也就是說(shuō)回傳的事件里沒有任何可用的用戶標(biāo)識(shí)符或其他信息。以前大家都是基于標(biāo)識(shí)符做廣告投放、數(shù)據(jù)統(tǒng)計(jì)，而SKAdNetwork是沒有這些標(biāo)識(shí)符的。

5. 數(shù)據(jù)回傳割裂：SKAdNetwork把數(shù)據(jù)優(yōu)先回傳給廣告平臺(tái)，如果廣告主想要獲得歸因數(shù)據(jù)，需要與每一家廣告平臺(tái)對(duì)接。這樣對(duì)廣告主的技術(shù)資源是一種浪費(fèi)。

二、iOS 14新規(guī)對(duì)移動(dòng)營(yíng)銷各方面帶來(lái)的影響。

通過幾位嘉賓的分享，相信大家已經(jīng)了解iOS14更新對(duì)于行業(yè)的新變化有了初步的了解。那么具體到廣告主與開發(fā)者、廣告平臺(tái)和歸因平臺(tái)分別有哪些具體的影響呢？

Liftoff：首先說(shuō)一下ATT對(duì)廣告投放的限制。因?yàn)閿?shù)據(jù)無(wú)法實(shí)時(shí)回傳，收入數(shù)據(jù)也無(wú)法非常準(zhǔn)確的回傳給廣告平臺(tái)，也就是說(shuō)ROI或ROAS的優(yōu)化難度會(huì)增加。其次，在沒有IDFA的環(huán)境下，以用戶為定向做投放是無(wú)法實(shí)現(xiàn)的。第三，再營(yíng)銷的投放在沒有IDFA的情況下也是不能做的。第四，增量測(cè)試會(huì)越來(lái)越困難，畢竟沒有IDFA很難做公平的投放效果比較。除此以外，新環(huán)境下的匿名事件回傳會(huì)省掉很多細(xì)節(jié)信息，報(bào)告收到的信息更少，導(dǎo)致在做廣告投放分析的顆粒度會(huì)更少。

Chartboost：從廣告變現(xiàn)角度來(lái)看，用戶級(jí)定向是提高eCPM的有效方式。廣告主的出價(jià)較高，轉(zhuǎn)化率比較好。隨著LAT流量變成主流后，用戶級(jí)定向的削弱會(huì)導(dǎo)致廣告主出價(jià)趨于保守，也就是說(shuō)轉(zhuǎn)化率低，出價(jià)保守的情況下，收益也有下降的風(fēng)險(xiǎn)。

如何降低損失呢？我們建議使用先進(jìn)的流量管理工具。當(dāng)前是使用in-app bidding的好機(jī)會(huì)，bidding可以幫助開發(fā)者獲取到主流廣告平臺(tái)廣告填充之外的其他更多類型的廣告源，如品牌、電商等更多類廣告主。in-app bidding對(duì)廣告主也是很好的方式，可幫助廣告主在公平的環(huán)境中競(jìng)價(jià)，對(duì)開發(fā)者來(lái)說(shuō)就是提高收益降低風(fēng)險(xiǎn)。面對(duì)用戶級(jí)定向的削弱，大家都在找解決方案。目前我們幾家廣告平臺(tái)傾向于使用上下文廣告來(lái)取代用戶級(jí)定向的廣告。

AppsFlyer：從歸因平臺(tái)角度看，iOS 14后可獲取的IDFA會(huì)變少，可能只有20%-30%的用戶會(huì)授權(quán)獲取。而在過去大概10年里，歸因都是基于IDFA。未來(lái)，IDFA的歸因方法會(huì)有更多的局限性，所以我們也想出了更多解決方案。

假如可以獲得IDFA的時(shí)候，我們?nèi)匀粫?huì)用IDFA作歸因。當(dāng)無(wú)法獲取IDFA的時(shí)候，我們會(huì)采用IDFV做歸因。但I(xiàn)DFV僅在同一個(gè)開發(fā)者賬戶下才是相同的，所以它也無(wú)法完全解決這個(gè)問題。此外，AppsFlyer引入了概率歸因模型的方法，基于概率歸因模型我們?nèi)匀豢梢宰鰧?shí)時(shí)歸因，并且實(shí)時(shí)把廣告數(shù)據(jù)回傳給廣告平臺(tái)。此外還有蘋果提供的SKAdNetwork歸因解決方案，AppsFlyer也會(huì)使用這種方案為廣告主提供更多的歸因結(jié)果數(shù)據(jù)。總結(jié)來(lái)說(shuō)，AppsFlyer會(huì)使用4種歸因方案，做出更全面的數(shù)據(jù)解讀，更加清晰的了解廣告投放和變現(xiàn)的效果。

三、廣告主、開發(fā)者及廣告平臺(tái)及第三方歸因平臺(tái)對(duì)于iOS 14的解決方案

iOS 14帶來(lái)的變化和影響是必然的。那我們應(yīng)該如何應(yīng)對(duì)來(lái)迎接新的變化？

1、歸因分析解決方案

AppsFlyer：大家都知道蘋果提出新的用戶隱私保護(hù)政策是在2020年6月的WWDC，至今已有9個(gè)月時(shí)間。在過程中蘋果做了很多變更，包括推遲上線日期。在此期間，AppsFlyer組織了能力最強(qiáng)的研發(fā)團(tuán)隊(duì)，針對(duì)新的變化做解決方案。到2021年3月，我們把之前做的所有方案整合成一個(gè)完整的一站式解決方案——SK360。

從iOS14.5蘋果強(qiáng)制執(zhí)行新的隱私政策開始，SKAdNetwork的歸因鏈路會(huì)成為主流鏈路，所以SK360就是基于SKAdNetwork的歸因機(jī)制推出的解決方案，可以最大化解決這套鏈路帶來(lái)的局限性。

SK360解決方案主要包含5部分：Connect（連接），Optimize（優(yōu)化），Predict（預(yù)測(cè)）, Protect（保護(hù)）和Analyze（分析）。

Connect（連接）：SKAdNetwork的數(shù)據(jù)割裂是一個(gè)比較嚴(yán)重的問題。所有的數(shù)據(jù)蘋果會(huì)先傳給廣告平臺(tái)，廣告主如果想獲得歸因數(shù)據(jù)，需要和每一家廣告平臺(tái)對(duì)接。這樣相當(dāng)于把整個(gè)行業(yè)倒推回了10幾年，對(duì)于廣告主來(lái)說(shuō)，和每家廣告平臺(tái)對(duì)接是資源浪費(fèi)。所以AppsFlyer會(huì)和所有廣告平臺(tái)對(duì)接SKAdNetwork，包括收集數(shù)據(jù)、驗(yàn)證數(shù)據(jù)、并把所有數(shù)據(jù)解析成可讀的信息，共享給廣告平臺(tái)優(yōu)化。目前AppsFlyer已對(duì)接了30余家廣告平臺(tái)，并且還在不斷增加。

Optimize（優(yōu)化）：蘋果采用的是0-63的轉(zhuǎn)化值配置，AppsFlyer提供了一個(gè)面板，供廣告主直接在后臺(tái)選擇你想記錄的用戶事件。如果ROI對(duì)你很重要，那可以在后臺(tái)選擇Revenue，我們就會(huì)記錄用戶在SKAdNetwork里觸發(fā)了多少次購(gòu)買事件，及購(gòu)買金額是多少。

如果您關(guān)注用戶漏斗行為，那么可以選擇Conversion，所有選擇僅需在AppsFlyer后臺(tái)操作，廣告主不需要在App代碼做任何變更，所有變更都發(fā)生在服務(wù)端，不需要再用戶端做更改。

Analyze（分析）：我們會(huì)把廣告平臺(tái)發(fā)送的SKAdNetwork數(shù)據(jù)進(jìn)行加工。SKAdNetwork原始數(shù)據(jù)的顆粒度非常粗糙，大概只有Campaign ID這樣的信息。而做廣告數(shù)據(jù)分析的話，需要知道具體的Campaign名稱和轉(zhuǎn)化情況等。這些指標(biāo)才是廣告主最需要的數(shù)據(jù)。

對(duì)此，AppsFlyer做了幾件事情。一是從廣告平臺(tái)收集數(shù)據(jù)，二是和每一家廣告平臺(tái)進(jìn)行單獨(dú)的API對(duì)接，把click，impression以及cost數(shù)據(jù)豐富進(jìn)來(lái)，并計(jì)算出當(dāng)前廣告平臺(tái)、campaign、ad set，site id對(duì)應(yīng)的數(shù)據(jù)指標(biāo)。把這一整套豐富過的數(shù)據(jù)展示在面板上，這就是Analyze的內(nèi)容。

Protect（預(yù)測(cè)）：剛才提到SKAdNetwork中很多地方可以做數(shù)據(jù)篡改，所以我們?cè)谑盏綌?shù)據(jù)后會(huì)驗(yàn)證，確保展示給廣告主的數(shù)據(jù)是沒有被篡改過的。

Predict（保護(hù)）：在SKAdNetwork中，如果想記錄用戶比較長(zhǎng)的生命周期的用戶行為，需要不斷更新轉(zhuǎn)化數(shù)值。每次更新都會(huì)生成一個(gè)倒計(jì)時(shí)器，更新次數(shù)越多，就會(huì)越遲收到這條歸因結(jié)果。大家都希望盡快收到歸因結(jié)果，進(jìn)而對(duì)campaign和創(chuàng)意進(jìn)行調(diào)整。但是記錄長(zhǎng)生命周期里的用戶行為，就要犧牲時(shí)效性。如果想保證時(shí)效性，就要犧牲收集數(shù)據(jù)的時(shí)間長(zhǎng)度。

Predict會(huì)基于應(yīng)用的歷史數(shù)據(jù)，對(duì)新增用戶進(jìn)行預(yù)估。在新增用戶激活A(yù)pp的1-3天內(nèi)，可以預(yù)估出這個(gè)campaign或用戶在全生命周期的情況，進(jìn)而幫助廣告主對(duì)所有campaign和廣告平臺(tái)進(jìn)行打分，協(xié)助廣告主更好的優(yōu)化廣告。

2、廣告平臺(tái)的解決方案

Liftoff：蘋果在2020年6月的WWDC宣布iOS14的消息之后，Liftoff已經(jīng)在同年的8月開始訓(xùn)練投放引擎和機(jī)器學(xué)習(xí)邏輯，實(shí)現(xiàn)在非IDFA的環(huán)境下，投放維持良好的成效。所以在去年的時(shí)候，我們已經(jīng)在限制廣告追蹤(LAT)流量方面做了充分的測(cè)試和準(zhǔn)備。因此，對(duì)于即將到來(lái)的ATT變化，我們也是同樣有應(yīng)對(duì)的信心。接下來(lái)，我們?cè)敿?xì)介紹一下應(yīng)對(duì)措施：

第一步：首先要確認(rèn)SKAN整合順暢。這就包括更新MMP SDK版本，確認(rèn)廣告平臺(tái)(比如Liftoff)支持SKAdNetwork。其次就是設(shè)定轉(zhuǎn)換值。前面提到廣告主可以設(shè)定64個(gè)轉(zhuǎn)換值，并且AppsFlyer還可以讓用戶選擇3種不同的模式(Engagament, Revenue, Conversion)；這些轉(zhuǎn)換值在設(shè)定后必須回傳給Liftoff，并且說(shuō)明不同數(shù)值代表的定義。廣告平臺(tái)會(huì)根據(jù)事件定義，更精準(zhǔn)的做廣告投放和優(yōu)化。

第二步是選擇對(duì)的事件?，F(xiàn)在的App里肯定有非常多的事件，但是蘋果設(shè)置了局限性，只能選擇64個(gè)事件。Liftoff現(xiàn)已支持不同的模式(Engagament, Revenue, Conversion)，同時(shí)我們也建議大家使用使用一個(gè)叫做“6位陳列”的策略：如下圖所示，廣告主可以選擇1個(gè)最終事件和5個(gè)中期事件去優(yōu)化。獲取率代表在蘋果限制內(nèi)，這個(gè)事件被抓取到的幾率，不同事件有不同的獲取率。我們建議無(wú)論選擇什么事件，這6個(gè)事件一定是獲取率最高的，而且是跟最終目標(biāo)緊密相關(guān)的。投放的時(shí)候，Liftoff會(huì)用CPA的方式做這些事件的優(yōu)化，從而也能夠繼續(xù)實(shí)現(xiàn)內(nèi)購(gòu)的優(yōu)化。

iOS14.5正式啟動(dòng)后，會(huì)有三類流量池。藍(lán)色是Pre-ATT，就是iOS14.4及以下，流量池是以設(shè)備OS和發(fā)行商App是否兼容SKAN這兩個(gè)因素來(lái)區(qū)分。假如用戶是iOS14.4以下，這部分用戶的投放還是可以用ROAS的模式，歸因可以用現(xiàn)在的模式做實(shí)時(shí)優(yōu)化。

綠色部分是iOS14.5開啟后Post-ATT流量。投放的開發(fā)者App需要兼容SKAN，歸因會(huì)用不同的方法記錄。對(duì)于藍(lán)色和綠色的部分，Liftoff已經(jīng)調(diào)整好優(yōu)化的邏輯，以不同的方式幫廣告主做投放。

黃色部分代表的是開發(fā)者沒有更新到最新版本、App還不兼容SKAN的情況下的流量。這部分的流量是廣告主通常無(wú)法投放的，所以建議大家更新到最新版本。當(dāng)然，如果想投放黃色部分流量的話，Liftoff也有辦法觸達(dá)這部分流量池，只是測(cè)量方面是一個(gè)技術(shù)挑戰(zhàn)。

在ATT開始后，藍(lán)色部分會(huì)逐漸減少，綠色和黃色部分會(huì)逐漸增加。綠色部分會(huì)在45天后占比最大。建議廣告主在選擇轉(zhuǎn)換值之外，還要考慮投放的預(yù)算分配。

目前Liftoff的系統(tǒng)功能更加智能化，可以檢測(cè)不同流量池帶來(lái)的成效，從而自動(dòng)分配花費(fèi)占比，確保廣告主在過渡期可以保持并提升回收。最值得一提的是，開發(fā)者需要和廣告平臺(tái)討論，為不同的流量池進(jìn)行的投放設(shè)定最適合的KPI。這是因?yàn)椴煌牧髁砍啬鼙O(jiān)測(cè)到的準(zhǔn)確度會(huì)有差別，所以不能用同樣的指標(biāo)進(jìn)行衡量，而是需要考慮不同流量池的情況下，最合理的KPI是什么。

3、廣告變現(xiàn)方面，開發(fā)者如何保證變現(xiàn)收益的穩(wěn)定？

Chartboost：在過渡期，大家應(yīng)該盡快把流量改為兼容SKAN的方式。第一是更新各大廣告平臺(tái)的SDK。目前各大廣告平臺(tái)的SDK都已經(jīng)做好適配，無(wú)論是獲取其他信息，還是適配iOS14.5等方面。只要更新好SDK，就會(huì)被判定為兼容SKAN的流量。

除了更新SDK外，還需要將廣告平臺(tái)及第三方DSP完整的SKAdNetwork IDs添加到應(yīng)用內(nèi)的Info.plist中。

接下來(lái)，從廣告變現(xiàn)平臺(tái)的角度來(lái)看，限制廣告追蹤的流量的趨勢(shì)。我們發(fā)現(xiàn)從2020年6月到2021年1月，LAT的廣告展示在iOS端全球的廣告展示占比從17%增長(zhǎng)到30%以上。未來(lái)還會(huì)繼續(xù)增加。

在LAT流量變成主流的情況下，開發(fā)者如何保證穩(wěn)定的表現(xiàn)收益呢？

1. 我們建議開發(fā)者在iOS 14.5早期及時(shí)調(diào)整瀑布流的配置，提高廣告填充率。

2. 在iOS平臺(tái)外，我們建議開發(fā)者積極開拓其他平臺(tái)的變現(xiàn)機(jī)會(huì)。除Google以外，Amazon平臺(tái)的設(shè)備上用戶質(zhì)量非常穩(wěn)定，一直被視為藍(lán)海市場(chǎng)，競(jìng)爭(zhēng)沒有那么激烈。Amazon的用戶屬性也適合國(guó)內(nèi)開發(fā)者擅長(zhǎng)的游戲類型，比如解謎、三消、兒童游戲、社交博彩游戲等，在Amazon上的變現(xiàn)效益非常好，開發(fā)者可以聯(lián)絡(luò)Chartboost對(duì)接亞馬遜平臺(tái)的變現(xiàn)合作。

3. 測(cè)試新的廣告形式，開啟插屏、激勵(lì)視頻、banner廣告變現(xiàn)。

4. 使用最有效率的程序化廣告變現(xiàn)方案。Chartboost的in-app bidding解決方案叫Helium。Helium聚合了主流的程序化廣告平臺(tái)及其他品牌與效果DSP來(lái)公平競(jìng)價(jià)，獲取最高展示。使用Helium可以有效提升流量競(jìng)價(jià)，提升eCPM。

隨著用戶級(jí)定向被削弱，Chartboost會(huì)依靠上下文廣告做定向投放。上下文廣告就是讓廣告內(nèi)容和應(yīng)用內(nèi)容有一定關(guān)聯(lián)性。上下文廣告已經(jīng)行之有年，但一直不被重視。隨著iOS 14的到來(lái)，是上下文廣告重生的時(shí)代。廣告平臺(tái)收集到的上下文廣告的信號(hào)，都是基于App的使用環(huán)境的。例如App類型、語(yǔ)言ID，游戲類型等，所有獲取的信息都是圍繞App的使用環(huán)境的，并不與特定設(shè)備或用戶綁定。廣告主可以依據(jù)獲取的上下文信息，針對(duì)應(yīng)用做定向投放。

下面來(lái)看一下，上下文信號(hào)的分享，如何提高競(jìng)價(jià)方的競(jìng)價(jià)能力？開發(fā)者需要做哪些準(zhǔn)備？

Chartboost通過廣告請(qǐng)求，將SDK收集到的特定上下文信號(hào)發(fā)送給競(jìng)價(jià)合作伙伴和DSP, 他們會(huì)決定是否采用以上信號(hào)，輔助他們內(nèi)部的機(jī)器學(xué)習(xí)算法，針對(duì)某次廣告展示做更準(zhǔn)確的出價(jià)，更好的進(jìn)行上下文廣告投放。上下文信號(hào)也可以幫助DSP提高算法能力，將廣告投放給最匹配的用戶。

Liftoff：上下文信號(hào)對(duì)于DSP這類以機(jī)器學(xué)習(xí)做投放的平臺(tái)是很有幫助的。iOS14.5后，我們面對(duì)的競(jìng)價(jià)需求中所包含的數(shù)據(jù)會(huì)少很多。對(duì)于這種情況，Liftoff在投放邏輯上所采取的措施是兼容不同的數(shù)據(jù)點(diǎn)，以此進(jìn)行競(jìng)價(jià)。眾所周知，接下來(lái)蘋果對(duì)Campaign ID的數(shù)量限制為100；Liftoff對(duì)應(yīng)的做法是用其中75個(gè)Campaign ID留給上下文及其他因素，作為引擎學(xué)習(xí)的邏輯。這些邏輯加上上下文信號(hào)，讓我們有信心在不同Adx比如Chartboost上確保廣告成效可以維持在良好的水平。