轉化率模型之轉化數據延遲
前幾天在公司內網上看見有同事在討論《廣告演算法工程師的日常》這篇文章裡面提到的A、B、C三位同學在實際的晉陞中誰的優勢更大，其實當時舉這個例子，本意只是想說明廣告演算法工程師在迭代優化模型的過程中，要相信數據>特徵>演算法本身，在遇到問題的時候能夠優先從數據以及特徵層面考慮。至於說誰在晉陞中優勢更大，大家仁者見仁、智者見智哈。
好了，今天主要想和大家聊聊「劉西瓜」，話說這個劉大統領…;額，不好意思，串台了哈。言歸正傳，今天和大家討論一下轉化率模型中轉化數據延遲的問題。這個問題無論是在淺層轉化（如app安裝、app激活、app註冊等）或者深度轉化（app付費）等場景下都是十分常見的。
0.什麼是轉化數據延遲問題
我們知道，在廣告場景下，曝光發生後點擊基本在很短時間內發生，而點擊發生之後，轉化有時候會有較長時間的延時，或許是幾分鐘，或許是幾天，甚至一個月以上，所以點擊率CTR的預估模型的訓練數據基本是無偏的數據集，而轉化率CVR預估模型的訓練數據有可能是迴流不完全的有偏數據，所以轉化率CVR模型可能會因為轉化延時問題而導致預估偏差，並且當實時更新模型時，由於實時數據中有偏樣本更多，預估偏差會更嚴重;一般來說像前面講到的淺層轉化（app安裝、激活、註冊等）基本在1天內數據基本可以回傳，而深度轉化（app付費等）基本需要一周以上的時間回傳數據。
1.轉化數據延遲問題的常見解法
(1). 指數建模法，代表論文《Modeling Delayed Feedback in Display Advertising》，作者給出了一個指數分布的假設，對於未迴流完全的樣本，可以用指數分布進行約束；缺點是a.假設首先未必合理 b.對於有迴流時間窗口的問題，需要進行時間窗的校準 c.對於大數據集是個挑戰
(2). bias-adjusted建模，代表論文《Display Advertising: Estimating Conversion Probability Efficiently》，該方法的收斂速度快，NLL和bias都比較低；缺點是對於大數據集是個挑戰
(3). 非參估計建模，代表論文《A Nonparametric Delayed Feedback Model for Conversion Rate Prediction》，該建模方式不對轉化時間的分布做假設，更能模擬真實的分布；缺點是a.計算相當複雜 b.對於大數據集是個挑戰
2.我們的做法
在講我們的做法之前，大家可以回過頭來看下《廣告模型初探（三）》中提到的大規模離散DNN即SDNN模型，我們的轉化延時模型就是根據該框架實現的。首先給出模型整體的架構圖，分為兩個部分，一個部分是轉化率模型，另一個部分是迴流率模型。
根據我們的實際業務情況，一般數據會在5天之內迴流95%以上，因此我們事先設定迴流時間窗口為5天，我們最終的訓練策略是對於a.迴流完全的樣本：同時更新轉化率模型以及迴流率模型 b.迴流不完全的樣本：只更新轉化率模型。舉個例子最近30天的訓練數據，分為25天迴流完全數據+5天迴流不完全數據，此時轉化率模型是使用30天的數據訓練，而迴流率模型僅僅使用25天的數據訓練，轉化率模型的結果會受到5天迴流不完全數據的影響，此時迴流率模型會作用於轉化率模型之上，起到一個校正的作用。
在實際使用中，我們採用的是batch+delta的經典模型更新方式，即分為天級別模型訓練以及小時級模型訓練兩塊。在天級別模型訓練階段，我們每天會啟動一個調度任務，生成softmax天級別迴流模型（25天迴流完全數據同時更新轉化率模型和迴流率模型，最近5天只更新轉化率模型，迴流率模型作用於轉化率模型之上），存放在天級別hdfs的目錄下；在小時級別模型訓練階段，每小時會啟動一個調度任務，拉取天級別目錄下面最新的模型，使用小時級的數據生成增量的模型，存放在小時級hdfs的目錄下。當線上預估模組檢測到小時級模型目錄有模型更新時，便會自動拉取該模型推送到線上，用於線上的實時預估。
3.小結
本文主要介紹了劉西瓜（額，怎麼還有call back）。本文主要給出了轉化數據延時問題的定義，常見解法以及我們在實踐中的做法。說到底轉化數據延遲問題其實是模型的準確率與模型更新時效性的兩方博弈，希望大家都能在具體的業務中找到一個平衡點。話不多說，上圖
歡迎關注微信公眾號：計算廣告那些事兒
