Notification Volume Control and Optimization System at Pinterest 小記

Notification Volume Control and Optimization System at Pinterest

論文地址：https://labs.pinterest.com/assets/paper/notifications-kdd18.pdf
在最優化長期用戶活躍度的目標下，決定每個用戶的推送量
推送量控制和最優化系統 減少推送量而且提高了我們關注的DAU等指標（而不是CTR）

推送相關

推送的內容相關是提高用戶體驗的基石，實際中還有很多需要考慮

1. 什麼時候發送推送通知
2. 哪個渠道(e.g. 郵件、手機推送、桌面推送)發送推送通知
3. 以什麼樣的頻率向用戶發推送通知（這幾點中這一條最重要）

直接提高推送量會導致的問題

想要提高用戶交互度的方法最簡單的辦法是提高推送量，用戶的點擊率等指標會迅速飆升，但是存在幾個問題

1. 用戶可能取消郵件訂閱或者卸載app，那後續就推送通知就無法抵達用戶了
2. 郵件服務提供商和手機操作系統將網站判爲垃圾發送者且屏蔽推送的風險會大大增加
3. 用戶對網站的信任會大打折扣，傷害品牌信譽

推送面臨的挑戰

1. 需要有一個能夠考慮推送對用戶長期影響和短期影響的目標函數
2. 顯著增加推送目標效用函數會減小，需要非線性模型來捕獲這個影響
3. 推送最優化算法需要高效可擴展，以便面對大量用戶
4. 怎麼處理多個推送渠道、怎麼協調推送量控制模塊和內容排序模塊（有新的推送方式出現可以方便的開發和測試）

和topic相關的三個領域

1. 郵件垃圾分類與檢測
2. 推送後用戶行爲預測
3. 最近推送量最優化的相關論文

當前垃圾檢測聚焦於負面行爲（取消訂閱or把郵件標記爲垃圾郵件），最近也有正面行爲預測（郵件打開、回覆）。正面行爲預測和topic相關，因爲作爲消息發送者，需要建模預測點擊率等指標並以此爲依據來決定推送量

相關論文提出解決方法的一些缺陷

1. 正面行爲和負面行爲被當做單獨的約束條件，需要調優一個全局的參數去控制正負面行爲的影響；這個論文提出一個新的方法，爲推送對用戶的長期影響建模，自動學習正面和負面行爲的權重
2. 相關論文有一些簡單的假設，假設每個郵件推送是獨立不相關的，k個郵件對用戶的影響是每個郵件的影響之和，但是實際情況不是這樣，發多個郵件給用戶可能會顯著減少用戶的反饋，而且相關論文使用的是線性模型來預測用戶的交互度；這個論文提出使用非線性模型來捕獲這種非線性影響並且提高預測的準確率
3. 效率問題也是非常突出的；這個論文提出的一個框架高效可擴展
4. 不同推送渠道的ctr模塊與推送量控制模塊耦合嚴重；這個論文將ctr模塊、推送量控制模塊解耦開來，方便新的渠道測試推送效果

系統詳情

1. Weekly Notification Budget
每週對每個用戶計算一個推送“預算”，也就是這個用戶這周能收到的最大推送量；這個模塊是論文與其他論文最大的區別，也是系統最核心的概念

2. Notification Service
這個模塊決定是否需要向用戶發送通知，以及什麼時候發送通知
① Budget Pacer
決定用戶當天是否需要推送
用戶每週budget算出來之後存在kV系統中，key是用戶ID,value是該用戶本週的budget，如果用戶當前還有預算纔會收到推送，最簡單的是平均分配budget，例如這周budget只有3個，那麼週一、週三、週六一天1個
② Ranker
如果用戶當天需要推送，決定用戶需要推送改動內容
根據通知類型、用戶歷史行爲、用戶畫像特徵選擇最合適的推送
③ Delivery
在用戶最有可能點擊的時間發送推送消息
用戶可能有多個接受渠道，最簡單所有渠道都發送，也可以按照特定順序發送

3. Volume Optimization Workflows

1. Date ETL
   根據推送日誌計算用戶歷史特徵以便於模型訓練使用
2. Model Scorer
   按照推送量最優化的目標訓練幾個模型並保存
3. Global Optimizer
   根據模型對用戶的預測分數和全局推送量限制計算每個用戶新的每週的budget，並存入KV系統中

都是離線模塊

新系統設計初衷

歷史推送量最優化系統，如果用戶有更高的概率與推送互動，用戶接收到的推動會更加頻繁。全局的推送頻率規則和不同的推送渠道的ctr、用戶活躍度有關
例如，用戶在推送渠道A的ctr屬於top20%，那用戶在渠道A接收的頻率就至多每三天就收到一次渠道A的推送，如果用戶在渠道B的ctr屬於bottom20%，那麼用戶在渠道B接收的頻率至多每14天接收到一次渠道B的推送
這對於系統來講需要考慮這樣幾個問題：①系統要決定哪個推送渠道適合推送給用戶②怎樣找到一種最高pctr的推送

舊系統存在的問題

1. 一段時間裏面沒有總的推送量控制
2. 頻率規則和渠道類型的ctr耦合嚴重
3. 推送頻率參數非常難調優

如果有新的推送渠道，總體的推送量會顯著增加，用戶交互度（CTR等指標）可能會增加，但是無法說明到底是推送量增加還是新的推送渠道的質量好導致的效果提升

新系統設計解決上述痛點

1. 每個用戶每週有一個推送總量的控制
2. 解耦推送量控制模塊和推送渠道、排序模塊，這樣當新的推送渠道實驗是，推送量不會有顯著變化，實驗結果就更嚴格
3. 去掉了各個推送之間相互獨立的假設，新系統是直接優化推送總量

目標函數的考慮

1. 哪一個指標是想要去提升的，這個指標和推送量之間的關係是什麼
2. 怎樣去對推送給用戶的長期影響建模，需要同時考慮正面行爲和負面行爲
   問題形式化：給定一個總的推送量，找到用戶在最優分佈模式，使得指定的目標函數最大化

推送效用和總目標的關係

以前的系統指標都是以更高的交互度例如ctr爲目標，但是實際我們希望提高的是網站的總目標例如DAU或者MAU，這兩者是相關的，但是提高交互度指標不一定就能提高總目標，因爲更活躍的用戶更有可能去點擊推送。
用戶來到網站有兩種方式：
① 直接進入網站
② 收到推送然後點擊推送進入網站 假設兩種方式相互獨立
$p(a|u) = p(a_0|u) + (1 - p(a_0|u)) \times p(a_n|u)$
其中 $p(a_0|u)$ 是用戶直接來網站的概率，$p(a_n|u)$是用戶推送通知的點擊率，公式的第二部分$(1 - p(a_0|u)) \times p(a_n|u)$不僅僅是點擊率，如果我們想提高總的用戶活躍度，我們可以增加推送提高第二部分（論文叫做utility of notification，可稱爲推送效用）的分值，而不是僅僅提高推送通知的點擊率，用戶活躍度和推送效用的關係是一個凸函數。因爲實際中去到網站的兩種方式不一定是相互獨立的，精確的推送效用是無法知曉的，上面僅僅是來說明提高交互度指標不一定能提高總目標。

直接對推送總量和網站活躍度進行建模

預估一個用戶在給定的每週budget下成爲活躍用戶的概率，有2個好處：
① 可以藉助非線性模型捕獲推送交互度和總目標的關係
② 不用再假設各個推送之間是相互獨立的
推送量最優化可以形式定義如下：
$\max \limits_{k_u} \sum \limits_up(a|u,k_u)$
$subject \ to \ \sum \limits_uk_u \leq K$
這裏的概率$p(a|u,k_u)$可以很方便的替換爲我們希望達到的總目標，例如DAU、WAU等等，論文作者發現優化DAU要好些，因爲WAU會提高不活躍用戶的表現，但是會抑制活躍用戶的表現，但是網站收入都是活躍用戶貢獻的，因此使用DAU相比WAU要合適些

對長期影響建模

目標函數應該考慮證正面和負面影響，以前的論文解決方案如下：用戶對推送的正面行爲設定一個下界，用戶對推送的負面行爲設定一個上界。但是存在兩個問題

①在調整這些參數的時候，不清楚目標函數在做什麼優化
②不同的用戶組中用戶負面行爲造成的結果差異非常大，部分用戶可能會取消訂閱或者離開網站

因此一個全局的負面行爲數量限制無法滿足捕獲這個差異，論文中提出一個對每個用戶的長期負面行爲的代價進行建模
$p(a|u,k_u) = \sum \limits_sp(s|u,k_u) \times p(a|u,k_u,s)$
其中 $\sum_sp(s|a,k_u) = 1$

$p(s|u,k_u)$表示用戶 $u$ 在本週的推送 budget 爲 $k_u$下采取的動作爲 $s$ 的概率，這裏 $s$ 可以表示爲取消訂閱和不取消訂閱兩種，也可以表示其他的，只要滿足$\sum_sp(s|a,k_u) = 1$就行。

論文這裏使用兩種可能採取的操作，取消訂閱和繼續訂閱兩種，那麼用戶取消訂閱的概率爲$p(s_{unsub}|u,k_u)$，用戶取消訂閱後會在一段時間後活躍度纔會保持穩定，因此論文使用 $p(a_L|u,s_{unsub})$來表示用戶取消訂閱後的穩定活躍度。也就是說，如果用戶繼續訂閱，使用當前的活躍度，如果用戶取消訂閱，使用一段時間以後的穩定活躍度，這樣就可以考慮到用戶取消訂閱的長期影響。因此，公式可以具體化如下：
$p(a|u,k_u) = p(s_{unsub}|u,k_u) \times p(a_L|u,s_{unsub}) +(1-p(s_{unsub|u,k_u})) \times (a|u,k_u,s_{sub})$

模型和算法

三個模型：活躍度預測模型$p(a|u,k_u,s_{sub})$、取消訂閱預測模型$p(s_{unsub}|u,k_u)$、取消訂閱的長期影響模型$p(a_L|u,s_{unsub})$

一個算法：計算用戶之間的最優化budget分配

模型使用邏輯損失函數。根據用戶能接觸到的推送渠道，將用戶劃分爲了3類。這3類用戶的表現模式內部有差異，需要在每類用戶裏面都訓練下面3個模型。
① 僅接收emai的用戶
② 僅接收push通知的用戶
③ 既接收email又接收push的用戶

活躍度預測模型

用戶訪問網站可能來自不同的推送渠道，而且不是相互獨立的，這裏使用XGB捕獲這種非線性影響。模型這裏使用的訓練數據來源如下：給一組用戶隨機設定推送量，收集他們的反饋，這樣的話，相當於給定了用戶 $u$ 和 每週推送budget $k_u$，來直接預測用戶活躍情況 $p(a|u,k_u,s_{sub})$，如果這這一週裏面，用戶每天都是活躍的，那麼產生一條正樣本 $(+1,u,k_u)$，否則產生負樣本 $(-1,u,k_u)$ ，這裏不論用戶是通過哪個渠道（郵件、Push）訪問網站都算作當天活躍，這樣做的好處實際上是將不同的推送渠道考慮進去了。

取消訂閱預測模型

如果用戶本週取消了訂閱，生成一個正樣本 $(+1,u,k_u)$，否則生成一個負樣本 $(-1,u,k_u)$，這裏的 $k_u$ 是本週的 budget ，不是本週本週推送改動實際發送量，因爲用戶取消訂閱之後我們就無法向其發送推送了，如果採用實際的發送量，那麼在訓練數據中會出現一種情況，推送量少反而取消的概率較高，這與實際不符。

取消訂閱的長期影響模型

用戶在取消訂閱之後的第四周活躍度趨於穩定，因此使用第四周的是否活躍來生成模型 $p(a_L|u,s_{unsub})$ 的樣本，生成方法和活躍度預測模型一樣

特徵

① 用戶畫像特徵：國家、年齡、性別等等
② 歷史活躍行爲：不同時間窗口的用戶活躍天數、點擊率
活躍度模型和取消訂閱模型每週的budget也是一個特徵，也是有用的

計算每週budget算法

給用戶 $u$ 發送第 $k+1$個通知的效用增益爲 $p(a|u,k+1) - p(a|u,k)$ ，我們可以將效用增益最低的那部分推送去掉，減少推送總量同時保持活躍度穩定。論文的算法是這樣做的，有一個全局的關於最小效用的閾值 $\theta$ ，首先在一個區間 $[k_{min}, k_{max}]$ 裏面找到最優的budget $i_{max}$，然後逐漸從 $k_{min}$ 到 $i_{max}$ 開始增大，如果某一個更小的budget $i$ 與 $i_{max}$ 之間的效能差別不大，我們採用更小的 budget 作爲用戶本週的推送 budget

現在問題來了，怎麼找到全局的關於最小效用的閾值 $\theta$ ，使得所有用戶的推送總量小於 $K$ ，通過算法2實現

我們也是在一個區間中尋找，看每一個 $\theta$ 是否能滿足推送總量小於 $K$ ，我們取最小的 $\theta$ 即可。

實驗結果

根據A/B Test實驗，因爲push通知比emai通知更爲高效，所以系統會顯著的將email推送量轉移到push上去，但是作者希望保持email和push之間的平衡，這是論文解釋爲何將用戶分爲3類進行分別實驗的原因。

儘管降低了所有用戶的推送總量，但是目標函數有把活躍用戶的推送量轉移到不活躍用戶身上。活躍用戶的打開、點擊顯著減少，但是DAU和WAU沒有變化，非活躍用戶的打開、點擊顯著增加，同時DAU、WAU也是顯著增加

這個圖是相同推送總量上，和舊系統的對比，最優化的budget和實際推送量之間的關係。可以看到對於活躍用戶或者非常不活躍用戶（最左側的部分），最優化的budget是比實際要低的；對於不活躍用戶，最優化的budget是比實際要高的。這也解釋了系統會將活躍用戶的推送量轉移到非活躍用戶的現象。

同時，系統能夠cover住不同推送渠道（push、email）的影響，所以對於email & push 的分組中，活躍指標都是顯著提升。

綜合來看，論文直接使用我們關注的最終指標（DAU、WAU）作爲優化目標，不再侷限於CTR等指標，這個角度的確非常新穎，值得借鑑。而且論文考慮了推送對用戶的長期影響，長短期影響同時兼顧，能保持推送系統長期健康穩定。論文對最終指標進行分解，分解爲3個模型，分別進行訓練，然後使用簡單高效的每週 budget 分配算法，能夠在大規模推送系統中落地和應用，這一點也是非常讚的。