導(dǎo)讀：隨著互聯(lián)網(wǎng)紅利的消失，廣告主獲客越來越難且成本水漲船高，以前的粗放式投放不再適用于眼下的市場，精細(xì)化投放已經(jīng)成為廣告主不可或缺的選擇。在精細(xì)化投放的場景中，各大廣告平臺于19-20年紛紛推出了RTA，那么什么是RTA，RTA如何輔助投放，它跟之前的RTB有什么區(qū)別，本文將為你揭開RTA的神秘面紗。

RTA（RealTime API），中文解釋“實時廣告API”，廣告平臺在進行廣告檢索階段，通過RTA接口向廣告主詢問其廣告是否參與競價，廣告平臺在接收到該信息后再進行廣告檢索召回。

一、背景

任何一個新鮮事物的出現(xiàn)一定是伴隨著一定的需求背景的，讓我們先來了解下RTA產(chǎn)品的需求背景。在上文《Marketing API的那些事兒》中我們有提到廣告主投放廣告的三種途徑，除了自建DSP對接ADX是依賴于廣告主自身數(shù)據(jù)和技術(shù)之外，剩下的兩種：媒體后臺開戶投放和對接MAPI搭建Trading Desk方式都是依賴于廣告平臺的能力建設(shè)。由于廣告主自建DSP需要較深的技術(shù)沉淀，廣告主一般都會選擇媒體后臺開戶投放或者對接MAPI搭建Trading Desk方式來滿足自家App推廣需求。

在推廣前期，廣告主可通過廣告平臺提供的定向能力來獲客，但隨著互聯(lián)網(wǎng)紅利的消失，廣告主獲客越來越難且成本水漲船高，以前的粗放式投放不再適用于眼下的市場，精細(xì)化投放已經(jīng)成為廣告主不可或缺的選擇。結(jié)合廣告主一方數(shù)據(jù)和廣告平臺的技術(shù)能力來輔助投放是行之有效的解決方案。

那么，在沒有RTA之前，廣告平臺是如何實現(xiàn)通過一方數(shù)據(jù)彌補廣告平臺定向能力不足的？很簡單，在《Marketing API的那些事兒》中有提到，MAPI的一個很重要的功能是數(shù)據(jù)回傳。不論是DMP API還是用戶行為數(shù)據(jù)回傳API，廣告主均可通過這將所需定向數(shù)據(jù)回傳到DMP平臺，然后廣告平臺將自身的DMP和DSP打通，利用廣告主上傳的數(shù)據(jù)來進行定向投放。廣告主的一方數(shù)據(jù)，除了彌補定向之外，還有一個重要的應(yīng)用場景是OCPX，因此這也是為什么說廣告平臺推薦大家使用OCPX，這樣其可以獲取到后鏈路數(shù)據(jù)，豐富其數(shù)據(jù)特征，輔助優(yōu)化模型。

既然已經(jīng)有了數(shù)據(jù)回傳MAPI，那廣告平臺為什么又要推出RTA呢？考量點主要出于如下幾個原因：

1. 出于保護用戶隱私數(shù)據(jù)安全考慮，廣告主不再將數(shù)據(jù)通過API輸出給外部平臺，用戶數(shù)據(jù)只能在自身平臺發(fā)揮作用；
2. 通過MAPI回傳數(shù)據(jù)存在滯后性，無法保證數(shù)據(jù)的實時性；利用RTA接口可以來彌補平臺實時定向能力的不足。

二、RTA廣告流程

廣告平臺在進行廣告檢索階段，通過RTA接口向廣告主詢問其廣告是否參與競價，廣告平臺在接收到該信息后再進行廣告檢索召回，一個完整的RTA廣告流程如下圖所示。

1. 前端發(fā)起廣告請求，請求后端廣告服務(wù)；
2. 廣告服務(wù)一般會經(jīng)過廣告檢索、廣告召回、廣告粗排、廣告精排等一些過程，最終將廣告下發(fā)給前端展示給用戶；
3. RTA請求時機：為什么沒有將RTA插入到上述的某一個流程中，原因在于RTA適合于廣告檢索到廣告下發(fā)之間的任一環(huán)節(jié)，但是處于不同的環(huán)節(jié)，對于廣告平臺和廣告主的處理邏輯是不一樣的；因此廣告主開發(fā)者在對接RTA時需要跟對方明確其RTA的請求時機是在什么階段；
4. RTA超時控制：RTA對時效性要求很高，所以當(dāng)一旦出現(xiàn)超時等問題時，不同平臺的處理機制不太一樣。有些平臺在超時后會默認(rèn)廣告主不需要本次流量；有些平臺則相反，會默認(rèn)廣告主需要本次流量。因此開發(fā)者在對接RTA時需要跟對方明確其RTA的超時時間和超時處理邏輯；
5. RTA控制維度邏輯：RTA的控制粒度可以到廣告賬號、廣告計劃等維度，但不同平臺的控制粒度不太一樣，粒度更細(xì)，廣告主可更好地進行精細(xì)化投放，目前大部分平臺都還在廣告賬號維度。開發(fā)者在對接RTA時需要跟對方明確其RTA的控制維度；
6. RTA出價：目前主流廣告平臺的RTA接口支持設(shè)置出價（或者價格系數(shù)），廣告主開發(fā)者可結(jié)合自身數(shù)據(jù)對本次流量進行價值預(yù)估，掌握出價的主動權(quán)。還有一些RTA接口支持質(zhì)量分，功能與出價類似，都是返回本次流量的價值；開發(fā)者在對接RTA時需要跟對方明確其RTA是否支持出價或者質(zhì)量分；
7. DPA廣告：目前主流廣告平臺的RTA支持返回商品ID（需提前跟廣告平臺對接商品庫），即可以投放DPA廣告，適合做remarketing，進一步對流量做精細(xì)化運營。開發(fā)者在對接RTA時需要跟對方明確其RTA是否支持DPA廣告；
8. 監(jiān)測鏈接：對于支持曝光點擊監(jiān)測的廣告平臺，部分平臺的監(jiān)測宏支持RTA_ID，這樣可以區(qū)分出哪些廣告是通過RTA策略勝出的，同時可以針對廣告流量質(zhì)量做監(jiān)控，例如曝光點擊監(jiān)測數(shù)據(jù)中出現(xiàn)了未知的RTA_ID，那么該流量可能存在問題。開發(fā)者在對接RTA時需要跟對方明確其監(jiān)測鏈接是否支持替換RTA_ID宏參數(shù)。

三、RTA接入

RTA，作為一個擴展實時定向能力的API，可以提升廣告投放效果，首先廣告主肯定是希望接入的，但廣告平臺出于數(shù)據(jù)安全和時效性考慮，一般都會設(shè)置接入門檻，這一點與對接ADX類似。

1. 消耗門檻：由于廣告平臺開放RTA功能存在數(shù)據(jù)輸出的風(fēng)險，所以廣告平臺一般只會針對KA客戶開發(fā)RTA能力；
2. 技術(shù)門檻：RTA是一個實時接口，對時效性要求很高，因此廣告主開發(fā)者必須具有較好的技術(shù)沉淀，才可以對接RTA；
3. 數(shù)據(jù)能力：RTA需結(jié)合廣告主一方數(shù)據(jù)和廣告平臺技術(shù)能力才能最大化發(fā)揮其功效，因此廣告主開發(fā)者需具備一定的數(shù)據(jù)能力，有能力基于一方數(shù)據(jù)對流量質(zhì)量進行評分，衡量流量價值。

廣告主在搭建RTA平臺時，需要關(guān)注接口超時問題，一旦超時比例過高，平臺有可能關(guān)停RTA能力。尤其是當(dāng)廣告主對接了各大平臺的RTA時，比如廣點通，巨量或者百度的流量，每次都對廣告主進行RTA請求的話勢必會導(dǎo)致廣告主服務(wù)器QPS的量很大，壓力很有可能扛不住。

那么，這個時候為了提升QPS，廣告主開發(fā)者可以設(shè)置緩存機制，優(yōu)先使用緩存數(shù)據(jù)。到這里需要考慮緩存過期問題，除了設(shè)置過期時間外，還需結(jié)合業(yè)務(wù)邏輯主動刪除緩存，比例用戶安裝激活了App，比如用戶購買了廣告產(chǎn)品等場景。廣告平臺側(cè)同樣可以設(shè)置相應(yīng)緩存機制，即對廣告主已經(jīng)進行“標(biāo)記”的用戶進行緩存或者記錄，下次無需再廣告主發(fā)起請求。隨著RTA數(shù)據(jù)的不斷積累，廣告平臺就能掌握更多廣告主用戶側(cè)的數(shù)據(jù)特征，從而減少RTA的次數(shù)。同時廣告主一方數(shù)據(jù)的積累對于廣告平臺的好處也是顯而易見的，比如用于訓(xùn)練OCPX模樣等。

廣告主在搭建RTA時，應(yīng)當(dāng)關(guān)注如下幾個指標(biāo)：

1. 超時率：過高的超時率對廣告平臺和廣告主開發(fā)者都是一種不好的體驗，平臺側(cè)有可能關(guān)停RTA能力；
2. RTA有效返回占比：有效返回RTA結(jié)果的比例，如果該比例過低，會導(dǎo)致RTA消耗過低，平臺側(cè)會認(rèn)為RTA并未給廣告主帶來較大的效果提升，有可能會關(guān)停RTA能力；
3. RTA消耗占比：參與RTA的消耗占大盤整體消耗的比例，與RTA參與率類似；
4. RTA匹配分析：通過結(jié)合監(jiān)測鏈接中的RTA_ID數(shù)據(jù)和RTA有效返回數(shù)據(jù)分析RTA最終匹配情況。
5. ……

四、RTA應(yīng)用

RTA提供了實時定向的能力，那么在哪些場景可最大化發(fā)揮作用呢？下面羅列一下電商行業(yè)幾個常用的場景，如果讀者有更好的場景，歡迎一起探討。

1. 拉新

廣告主在推廣App時，一定會涉及到拉新，獲取新客戶。既然是拉新，那如果將廣告投放給老客戶，浪費預(yù)算的同時又會影響老客的用戶體驗，因此在投放拉新廣告時需要排除老客。如何判斷一個用戶是某App的新用戶還是老用戶，只有廣告主自己才知道，而且每個廣告主的判斷標(biāo)準(zhǔn)還不一致，因此廣告平臺無法屏蔽這部分用戶。通過RTA接口，廣告主可以自行判斷是否針對本次流量投放拉新廣告，從而提升廣告投放效果。

2. DPA

目前主流的廣告平臺均支持在RTA返回結(jié)果中返回商品信息，這就表示廣告主可以結(jié)合內(nèi)部推薦數(shù)據(jù)給本次流量推送最合適的廣告素材。廣告主開發(fā)者需要支持實時+離線的方式計算用戶的個性化數(shù)據(jù)，這里面就需要考量耗時問題，畢竟實時推薦可能達(dá)不到RTA要求的時效性。

3. 頻控

在廣告行業(yè)中，大家有一個共識，針對同一個用戶投放多次并不會提升效果，反而需要將用戶看到廣告的頻次控制在一定范圍內(nèi)。廣告主在推廣App時，一般都會渠道投放。在沒有RTA之前，廣告主一般只能設(shè)置單渠道的頻控設(shè)置。在有了RTA之后，如果投放的渠道均支持RTA，那么廣告主可以做到全局頻控，可以節(jié)省投放費用，同時提升投放效果。

4. 流量分層運營

在App運營體系中，不同活躍度用戶的流量價值是不一樣的，活躍度越高，相應(yīng)的流量價值也越大。因此廣告主一般都會針對不同的活躍度的用戶打上不同的質(zhì)量分，同時設(shè)置對應(yīng)的運營策略。由于RTA接口支持回傳流量質(zhì)量分，廣告主可通過此字段向廣告平臺傳達(dá)其對本次流量的打分情況，平臺在收到該信息后，疊加平臺側(cè)的動態(tài)出價能力，為廣告主更好的去競得本次流量，實現(xiàn)流量的分層運營。

五、RTA VS RTB

RTB（RealTime Bidding），中文解釋為“實時廣告競價”，廣告主可針對ADX的每一次流量進行流量價值、CTR以及CVR預(yù)估，然后決定是否參與競價，如若參競，需要返回對應(yīng)的廣告素材以及出價。廣告主通過自建DSP對接ADX，由于缺少平臺媒體側(cè)上下文信息（context）、用戶媒體的用戶行為（user）以及其他相同廣告主投放的泛化數(shù)據(jù)，因此相同技術(shù)能力條件下，廣告主的CTR和CVR預(yù)估模型也比較有限。

RTB和RTA，雖然兩者從名稱上看就一字之差，但兩者是完全兩個不同的工具，主要差異點見下圖。

1. 廣告歸屬：RTA的廣告創(chuàng)建位于廣告平臺側(cè)；RTB的廣告創(chuàng)建位于其自建的平臺側(cè)；
2. 出價：RTA的出價可以是平臺的出價*用戶質(zhì)量分，也可以是RTA的實時出價；RTB的出價是實時競價；
3. 定向：RTA的定向結(jié)合平臺側(cè)的定向和廣告主的實時定向；RTB的定向主要是其自建平臺的定向功能；
4. 定向粒度：RTA的定向粒度可以是賬號和計劃級別；RTB的定向粒度是廣告級別；
5. 數(shù)據(jù)：RTA利用了廣告平臺數(shù)據(jù)和廣告主一方數(shù)據(jù)；RTB僅利用了廣告主一方數(shù)據(jù)。

六、總結(jié)

RTA是這兩年興起的廣告技術(shù)能力，其核心要點在于通過廣告主一方數(shù)據(jù)并結(jié)合廣告平臺的技術(shù)能力來更好的實時輔助廣告投放，包含但不限于定向優(yōu)化、出價優(yōu)化、DPA優(yōu)化等，隨著各平臺對于RTA的深入探討研究，期望這個行業(yè)能給大家更多的玩法。

文章推薦：

Marketing API的那些事兒

商化廣告角色大盤點

App開屏廣告設(shè)計之禪

漫談廣告流量分發(fā)策略

一文帶你了解廣告GIVT&SIVT

?

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

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