分享嘉賓：周冰倩 哈囉出行 高階演算法
工程師
編輯整理
：趙二白
出品平臺：DataFunTalk
導讀：
廣告主不能像
廣告平臺一樣，獲取到比較多的使用者維度的曝光資料，並且在廣告主側獲取不到端外新使用者的特徵。
本次分享會著重講一下哈囉出行作為廣告主，是如何在這些挑戰下進行資訊流廣告演算法建模探索的。
本次介紹會圍繞下面四點展開：
資訊流廣告投放現狀
哈囉業務背景介紹
廣告主側的演算法最佳化方案
未來方向
01
信
息流廣告投放現狀
1。 發展歷程
我們在刷朋友圈、抖音、頭條時，應該都看過資訊流型別的廣告。它是一種嵌入在媒體內容流中的廣告形式，內容包括圖片、圖文、影片等等。它的主要特性是內容的價值性和原生性。對於受眾來說，資訊流廣告能夠為使用者提供更多有內容，有價值的東西，而不是單純的廣告。所以它的內容植入和呈現不會破壞頁面本身的和諧度，使用者角度體驗感也是比較好的。
上圖左邊的圖展示了資訊流廣告的發展史，資訊流廣告最早在2006年出現在facebook上，11年出現在twitter上，12年應用在微博，14年頭條，15年朋友圈。直到16年進入了全面爆發階段，百度、快手、UC等都相應地推出了資訊流廣告。上圖右側的圖展示了搜尋廣告、電商廣告、資訊流廣告在整個市場上的佔比。可以看出，從2015年到2021年資訊流廣告的佔比逐年增加。到了2022年預計可以達到40。8%。目前資訊流廣告被多數廣告主選用在拉新促活的使用者增長手段，所以哈囉出行也選擇了資訊流廣告作為站外拉新的主要方式。
2。 投放流程
上圖是平臺視角和廣告主視角兩個角度下的廣告投放流程。
平臺視角
，使用者在流量主側產生瀏覽行為，流量主會向ADX（ad exchange廣告實時競價交易平臺）傳送廣告請求，廣告交易平臺在接收到廣告交易請求，接著會向DSP（demand side platform，廣告投放平臺）傳送請求。DSP在接受到這個競價請求後，內部會進行一系列包括從流量篩選到廣告召回，然後排序、出價等操作。目前大家常說的廣告演算法，更多的是嵌入在DSP內部的召回，排序等演算法，並且這種廣告演算法在業界內也比較成熟。
廣告主視角
，這裡指的是廣告主針對線上投放所能夠做的操作。一開始會經過一個競價機制。當一個廣告請求過來，對於這個請求帶過來的使用者，我們來決定要不要參與對這個使用者的競價。這個競價機制在以下四個方面進行了考量：轉化情況，使用者價值，曝光情況，還有其他的干擾策略等等。在競價機制後就到了投放機制，投放機制更偏向於線上的實際投放，包含了賬戶設定、異常監測、資料監控和自動投放等等。
02
哈囉業務背景介紹
下面介紹一下哈囉出行外投業務背景。
1。 哈囉外投發展階段
廣告主投放能力的發展歷程會經過以下四個階段：
第一個階段是
探索階段
，在這個階段廣告主業務一般是剛剛起步，它需要透過投放廣告來摸索市場。此時廣告主所需要做的就是直接在平臺上面開戶。
經過前期的探索，驗證了廣告的投放效果之後就進入到第二階段，
投放初步階段
。這個階段的目的是迅速佔領市場，所以會在市場上投入大量的廣告，提升投放效率。在這個階段廣告主需要技術支援來進行後續的轉化歸因，監測體系，資料監控等等。
提效之後就到了以降本為目的的
發展階段
。經過前期的大量的市場投放後，廣告的獲客成本會越來越高，這個時候需要對流量做精細化運營，所以需要更多的技術能力來支撐和實現降本的目標。現在發展比較成熟的有DMP，平臺提供的人群管理API，包括後面我要提到的marketing API。
經歷過以上三步之後，就到達了
成熟階段
，成熟期的目標就是智慧化，擁有全鏈路的演算法和自動化實現，不再需要人工參與。
目前哈囉已經在發展階段，技術能力和資料能力都已經比較成熟。
2。 外投系統框架
上圖是哈囉的外投系統框架。在業務上對接的比較大的三個渠道是巨量引擎，廣點通和快手。
因為涉及到一些介面對接，所以在服務端要建立一個統一介面閘道器，然後進入到儲存層，儲存層使用了業界比較通用的元件包括：redis，MYSQL，HBASE，Elasticsearch等等。再經過資料層後，到達應用層。應用層主要列了三點，就是決策機制，自動化運營和歸因機制。決策機制也是我後面主要介紹的重點。因為演算法更多是作用在決策機制層。
03
廣告主側的
演算法最佳化方案
第三部分具體講一下上面提到的決策機制裡面的演算法最佳化方案。主要從三個方面進行介紹：廣告計劃維度，創意維度，以及競價前的預判機制。
1。 廣告計劃維度
首先是廣告計劃維度， 上圖的上半部分圖列出了使用者從被廣告曝光到完單的整體鏈路。以哈囉車主拉新為例，一個新使用者需要經過曝光、點選/三秒曝光、註冊成為哈囉使用者、提交認證成車主這幾步後，才能進行完單行為。對於廣告主來說，完單才是最終能產生價值的行為。但目前對接的幾家比較大的渠道，都是以提交認證成本來作為獲客成本。現業務上一個痛點是提交認證到完單的比例比較低，大概百分之二三十左右。這對廣告主是不利的，因為廣告主花費了錢來拉使用者，但使用者在端內並沒有產生價值，這部分就是無效的預算。上圖中下半部分的圖，結合了廣告賬戶平臺結構重新解釋了上面提到的業務痛點。平臺上面通用的廣告賬戶結構是一個賬戶下包含著不同的廣告組，不同的廣告組又包含著不同的廣告計劃。
為了比較形象地表示從提交認證到完單這部分比例比較低的情況，可以看一下上圖用紅框和藍框中的兩個廣告計劃。上面這個廣告計劃是質量比較低的廣告計劃。下面的是質量比較高的。可以看到這兩個計劃在提交認證，也就是轉化這一步都假設有四個人轉化。但上面的這個計劃，只有一個人完單，完單率只有25%。而下面這個廣告計劃的完單率達到了75%。很明顯，下面這個廣告計劃的質量比上面的質量要高。針對這個問題，我們進行了演算法方案最佳化的探索。
目前面臨的第一個挑戰是在線上起量的計劃的量級比較小。因為演算法建模是基於資料，如果能用的資料量少，就會直接影響到後續建模的精確度。第二個挑戰是我們不能獲得廣告平臺商的曝光點選和競價等明細資料。針對這兩個挑戰，做了一個問題的轉化，從計劃質量識別轉化為劣質流量識別，再轉化為使用者完單率預估的問題。
因為我們的使用者都是在廣告計劃下面轉化的，所以最初的目的是進行計劃質量識別。但因為資料量等原因，將問題轉化成了劣質流量識別。而對於廣告主來說劣質流量可以定義成沒有產生價值的流量，所以問題就變成判斷使用者在提交認證之後是否能夠完單。這樣問題會簡單很多，且雖然他可能在端外是新使用者，但他在提交認證之後，我們就可以取到他端內的畫像資料特徵，所以有足夠的資料來解決這個問題。
上圖是完單模型的建模思路。
由資料分析，樣本構建，特徵選取，模型訓練四部分構成。
在資料分析部分，我們透過分析發現，大部分使用者從提交認證到產生完單行為的時間間隔是在七天之內的。如果超過七天他還沒有完單，那大機率上就不會完單了，就變成了剛剛提到的劣質流量了。所以在樣本構建部分，透過提交認證之後，是否能在七天之內完單這個邏輯來構建正負樣本。上圖的submit_pt代表的是使用者提交認證的時間。
但是車主能否完單，其實是受很多外部因素制約的。並且樣本的資料量也是比較小的，為了更貼合業務情況，進行了資料增強操作。將原始的使用者維度取樣增強為以訂單維度取樣，具體為在使用者進行提交認證之後，將每次在發單頁面有過訪問或者點選行為的日期作為基點來預測它之後七天內完單的機率。
然後是特徵選取部分。特徵選取使用了使用者特徵，環境特徵，廣告特徵，時間特徵等特徵。時間特徵使用了使用者發生轉化到瀏覽的時間間隔作為特徵。
模型選擇遵循了奧卡姆剃刀原理，選擇了簡單高效的lightGBM。
2。 創意維度
在實際的業務下，廣告最佳化師會因為不確定廣告投放效果，在不同的賬戶或者不同的計劃下面堆積大量相似創意，去測試其效果。這就導致線上會存在著大量的無效素材，他們並不能起量，但是會產生一些小額消耗，浪費了預算。
並且相似的創意，因為不同的賬戶的歷史表現不一樣，所以廣告平臺的演算法對相似創意預估出的分值可能會不一樣，針對這個問題這邊構建了一個預估新創意能否起量的模型，來指導廣告最佳化師後續的方案調整。決定創意能否起量的因素是質量度。不同的渠道對質量度有著不同的側重，從上方的表格可以看出，巨量引擎可能更側重於效果的反饋。廣點通更注重eCPM，百度則側重於定向方式。對於廣告主而言，定向方式和效果反饋是沒辦法干預的，所以更多的是干預eCPM。從上面列出的ecpm的公式可以看出，預估創意是否能夠起量，更多的是偏向於ctr方面。所以這邊列了三點，定向，創意，“戶口”。“戶口”是指賬戶的歷史表現，比如說他在線上已經投放了多少天，使用者的轉化和完單等資料。
上圖展示了構建模型的挑戰，第一個挑戰點在最開始也介紹了，就是資料的制約，從左圖上的自定義列，可以看到廣告主能夠拿到的一些資料，計劃的預算以及左圖上展現的資料都偏向於廣告計劃維度。對於一些數值資訊，比如展現資料，轉化資料等，廣告主所能夠拿到的資料也都是相對粗粒度的。由右圖所示，我們只能拿到這一條廣告計劃下面的消耗、展示量、點選率等。針對使用者維度的詳細的資料，比如曝光、參競資料等，廣告主是拿不到的。
第二個挑戰是新創意只有剛配置完的配置資訊，缺少後續投放的相關資料。
針對以上兩個問題，主要是在構建樣本和特徵工程兩個方面進行解決的，針對新創意沒有相關投放資料的問題，解決方法是在樣本構建時同時選取了新創意和老創意，新創意是能夠學習到配置特徵的重要性。老創意可以學習到更偏向於右邊這張圖的投放特徵。透過這個方式讓模型同時學到創意維度或者計劃維度的配置資料和一些投放的數值特徵。
特徵工程中主要應用了特徵交叉去獲取更多的資料，由下圖所示：
上圖就是特徵工程，透過特徵交叉解決了數值型資料比較少的問題。這張圖的左邊是創意ID，中間框出來的是特徵工程比較核心的部分。主要是做了三部分內容：
第一部分是將ID特徵使用word2vector產生ID特徵序列。一個創意屬於一個計劃下。一個計劃則屬於一個廣告組下。所以從賬戶ID到廣告組ID到計劃ID，都是一對多的關係。而一個創意是由不同的素材構成的，不同的素材包含著不同的影片、封面、標題等。針對這部分ID特徵就是做了一個ID特徵序列，將他們展成文字序列，然後使用word2vector轉化成向量。
第二部分是針對投放的數值特徵的處理方式。對於投放的數值特徵部分以及配置引數特徵部分，主要是進行了不同維度的特徵交叉，比如說一個創意ID和一個計劃ID交叉來拿到計劃ID下相應的數值特徵。在做了各種交叉之後，就拿到了不同的影片、封面、標題、計劃ID下面的資料特徵。
第三部分是針對廣告配置引數特徵的處理方式。配置引數特徵其實就是廣告在進行投放時配置的定向引數的特徵，比如說投放時間，使用者定向，投放城市等。處理方式與第二部分類似，也是經過交叉拿到計劃的配置特徵和創意的配置特徵。
經過這整個特徵處理之後，會進行模型訓練，最後我們選擇了使用多分類模型。因為一開始在解決這個問題時，有嘗試過迴歸，但迴歸預測出來效果不是很好，MSE特別高，所以後面將問題轉化為多分類，相對來說多分類會比迴歸效果好很多，準確率也高很多。
上圖是整體模型框架圖，從下至上展示了資料從輸入到輸出，下半部分就是前面特徵工程的彙總，最下面是特徵輸入，包括剛剛說過的數值特徵，類別特徵和ID特徵。數值特徵經過歸一化，離散化後進行embedding。類別特徵也是進行embedding。ID特徵首先展成文字序列，然後經過word2vector產生向量。然後embedding產生的向量和word2vector產生向量這兩部分同時輸到模型裡面，再經過一個concat層，最後使用softmax輸出不同類別的機率。
上圖是人工賬戶與演算法操作賬戶的效果資料對比。藍色的是人工賬戶，橙色的是演算法操作賬戶。由圖所示，不管是在轉化成本或者首單成本，演算法操作賬戶提升比較高的，大概能夠降低到10~20%左右，效果還是比較顯著的。
3。 競價前預判機制
這個機制更偏向於前置策略，也就是說一個使用者過來，我們能夠決定對這個使用者到底進不進行曝光，或者說有一些其他的干擾使用者質量分。
從上方的左圖大家可以看到，現在業界比較主流的針對老客拉活的操作是RTB，RTB電商做的比較多。而對於新客主要是做RTA，因為RTA更偏向於流量遮蔽。對於老客和新客都適用的就是中間的交叉部分增強RTA，現在比較主流的媒體，像騰訊，頭條等都有介面能夠支援的。針對中間交叉部分，我們使用了因果推斷的uplift模型構建了促活模型。
在構建樣本時考慮到了使用者意願，選取選資訊流廣告下轉化的使用者為正樣本，自然轉化的使用者為負樣本。uplift分值可以體現使用者的意願度，它是有需要外部的廣告激勵才能轉化，還是它本身就有意願轉化。公式裡的T代表是否存在廣告干預。然後依據uplift的分值從0到5將使用者進行分檔，0是已經轉化的使用者，這部分使用者我們會直接遮蔽掉，不會對他們出價。1是自然轉化，2～4為營銷敏感度低、中、高使用者，5是新使用者，因為我們沒有辦法拿到新使用者的資料，所以我們會返回最高的使用者質量分。這個機制實現了使用者價值分層階梯出價買量，線上效果降本明顯。
04
未來方向
下面從前置策略和線上投放兩方面介紹我們的未來規劃。
前置策略拉新場景下的後續目標，更偏重於精準遮蔽的模型，目前我們只是針對端內已經轉化的使用者進行遮蔽，當我們接入曝光資料後，就可以深入挖掘曝光資料來制定策略，例如一個使用者最大曝光次數等，來進行精準遮蔽。
拉活場景下的使用者投放更側重於RTB，因為目前哈囉使用者體量比較大，也有足夠的資料支撐去做RTB。
規劃的第二個方向是全自動線上投放，閉環管理。透過演算法來選擇最優方案構建創意和計劃，減少人工手動配置。進行不同創意不同計劃之間的預算分配，以達到廣告計劃ROI最大為目的設定使用者定向。
右邊這張大圖可以看成是整個規劃的概覽圖。裡面左下角的小圖是演算法能力的建設，包括出價管理，跨渠道管理，RTB預算分配，DPA等。右邊的小圖列出了演算法能力的技術支撐，包括uplift，強化學習，在業務場景內融入業界比較成熟的ctr演算法，以及使用CV相關演算法實現素材的創新，針對不同的使用者展示不同的素材。
05
精彩問答
Q：如果存在多業務拉活，怎麼去避免惡性競爭抬價呢？
A：不同業務針對的人群大機率是不一樣的。比如做四輪車主拉新的人群一定是有車人群。如果是兩輪業務拉新，那麼更偏向的是沒有車的人群。在不同的業務線針對的使用者不一樣的情況下，中間的交叉應該不會特別嚴重。
Q：相似素材為什麼在不同賬戶下的表現會不同呢？
A：因為平臺方會從很多方面來判斷是否要給一個計劃或者一個素材放量。舉個例子來說，一個在線上已經跑得比較好的賬戶，它下面會有很多的使用者轉化，如果拿他跟一個剛起量的賬戶對比，那平臺的側重一定是不一樣的。所以相同的素材在線上跑得比較穩定的計劃下和在線上剛跑的計劃下，肯定是在比較穩定的計劃或者賬戶下更容易起量。
Q：在未來規劃的那頁PPT中，拉活部分的潛客模型是準備透過RTB而不是RTA來達到的？
A：RTB和RTA從本身的概念講是不可以互相替換的，RTB是一個實時競價的框架，而RTA只是一個介面，這頁PPT主要想表達的意思是將RTB的核心功能點整合到RTA裡面，透過RTA的介面，來實現實時競價。
今天的分享就到這裡，謝謝大家。
福利來了！月度十大金股，挖掘市場機會！點選檢視>>
開啟App看更多精彩內容