Notification Volume Control and Optimization System at Pinterest
论文地址:https://labs.pinterest.com/assets/paper/notifications-kdd18.pdf
在最优化长期用户活跃度的目标下,决定每个用户的推送量
推送量控制和最优化系统 减少推送量而且提高了我们关注的DAU等指标(而不是CTR)
推送相关
推送的内容相关是提高用户体验的基石,实际中还有很多需要考虑
- 什么时候发送推送通知
- 哪个渠道(e.g. 邮件、手机推送、桌面推送)发送推送通知
- 以什么样的频率向用户发推送通知(这几点中这一条最重要)
直接提高推送量会导致的问题
想要提高用户交互度的方法最简单的办法是提高推送量,用户的点击率等指标会迅速飙升,但是存在几个问题
- 用户可能取消邮件订阅或者卸载app,那后续就推送通知就无法抵达用户了
- 邮件服务提供商和手机操作系统将网站判为垃圾发送者且屏蔽推送的风险会大大增加
- 用户对网站的信任会大打折扣,伤害品牌信誉
推送面临的挑战
- 需要有一个能够考虑推送对用户长期影响和短期影响的目标函数
- 显著增加推送目标效用函数会减小,需要非线性模型来捕获这个影响
- 推送最优化算法需要高效可扩展,以便面对大量用户
- 怎么处理多个推送渠道、怎么协调推送量控制模块和内容排序模块(有新的推送方式出现可以方便的开发和测试)
和topic相关的三个领域
- 邮件垃圾分类与检测
- 推送后用户行为预测
- 最近推送量最优化的相关论文
当前垃圾检测聚焦于负面行为(取消订阅or把邮件标记为垃圾邮件),最近也有正面行为预测(邮件打开、回复)。正面行为预测和topic相关,因为作为消息发送者,需要建模预测点击率等指标并以此为依据来决定推送量
相关论文提出解决方法的一些缺陷
- 正面行为和负面行为被当做单独的约束条件,需要调优一个全局的参数去控制正负面行为的影响;这个论文提出一个新的方法,为推送对用户的长期影响建模,自动学习正面和负面行为的权重
- 相关论文有一些简单的假设,假设每个邮件推送是独立不相关的,k个邮件对用户的影响是每个邮件的影响之和,但是实际情况不是这样,发多个邮件给用户可能会显著减少用户的反馈,而且相关论文使用的是线性模型来预测用户的交互度;这个论文提出使用非线性模型来捕获这种非线性影响并且提高预测的准确率
- 效率问题也是非常突出的;这个论文提出的一个框架高效可扩展
- 不同推送渠道的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
- Date ETL
根据推送日志计算用户历史特征以便于模型训练使用 - Model Scorer
按照推送量最优化的目标训练几个模型并保存 - Global Optimizer
根据模型对用户的预测分数和全局推送量限制计算每个用户新的每周的budget,并存入KV系统中
都是离线模块
新系统设计初衷
历史推送量最优化系统,如果用户有更高的概率与推送互动,用户接收到的推动会更加频繁。全局的推送频率规则和不同的推送渠道的ctr、用户活跃度有关
例如,用户在推送渠道A的ctr属于top20%,那用户在渠道A接收的频率就至多每三天就收到一次渠道A的推送,如果用户在渠道B的ctr属于bottom20%,那么用户在渠道B接收的频率至多每14天接收到一次渠道B的推送
这对于系统来讲需要考虑这样几个问题:①系统要决定哪个推送渠道适合推送给用户②怎样找到一种最高pctr的推送
旧系统存在的问题
- 一段时间里面没有总的推送量控制
- 频率规则和渠道类型的ctr耦合严重
- 推送频率参数非常难调优
如果有新的推送渠道,总体的推送量会显著增加,用户交互度(CTR等指标)可能会增加,但是无法说明到底是推送量增加还是新的推送渠道的质量好导致的效果提升
新系统设计解决上述痛点
- 每个用户每周有一个推送总量的控制
- 解耦推送量控制模块和推送渠道、排序模块,这样当新的推送渠道实验是,推送量不会有显著变化,实验结果就更严格
- 去掉了各个推送之间相互独立的假设,新系统是直接优化推送总量
目标函数的考虑
- 哪一个指标是想要去提升的,这个指标和推送量之间的关系是什么
- 怎样去对推送给用户的长期影响建模,需要同时考虑正面行为和负面行为
问题形式化:给定一个总的推送量,找到用户在最优分布模式,使得指定的目标函数最大化
推送效用和总目标的关系
以前的系统指标都是以更高的交互度例如ctr为目标,但是实际我们希望提高的是网站的总目标例如DAU或者MAU,这两者是相关的,但是提高交互度指标不一定就能提高总目标,因为更活跃的用户更有可能去点击推送。
用户来到网站有两种方式:
① 直接进入网站
② 收到推送然后点击推送进入网站 假设两种方式相互独立
p
(
a
∣
u
)
=
p
(
a
0
∣
u
)
+
(
1
−
p
(
a
0
∣
u
)
)
×
p
(
a
n
∣
u
)
p(a|u) = p(a_0|u) + (1 - p(a_0|u)) \times p(a_n|u)
p(a∣u)=p(a0∣u)+(1−p(a0∣u))×p(an∣u)
其中
p
(
a
0
∣
u
)
p(a_0|u)
p(a0∣u) 是用户直接来网站的概率,
p
(
a
n
∣
u
)
p(a_n|u)
p(an∣u)是用户推送通知的点击率,公式的第二部分
(
1
−
p
(
a
0
∣
u
)
)
×
p
(
a
n
∣
u
)
(1 - p(a_0|u)) \times p(a_n|u)
(1−p(a0∣u))×p(an∣u)不仅仅是点击率,如果我们想提高总的用户活跃度,我们可以增加推送提高第二部分(论文叫做utility of notification,可称为推送效用)的分值,而不是仅仅提高推送通知的点击率,用户活跃度和推送效用的关系是一个凸函数。因为实际中去到网站的两种方式不一定是相互独立的,精确的推送效用是无法知晓的,上面仅仅是来说明提高交互度指标不一定能提高总目标。
直接对推送总量和网站活跃度进行建模
预估一个用户在给定的每周budget下成为活跃用户的概率,有2个好处:
① 可以借助非线性模型捕获推送交互度和总目标的关系
② 不用再假设各个推送之间是相互独立的
推送量最优化可以形式定义如下:
max
k
u
∑
u
p
(
a
∣
u
,
k
u
)
\max \limits_{k_u} \sum \limits_up(a|u,k_u)
kumaxu∑p(a∣u,ku)
s
u
b
j
e
c
t
t
o
∑
u
k
u
≤
K
subject \ to \ \sum \limits_uk_u \leq K
subject to u∑ku≤K
这里的概率
p
(
a
∣
u
,
k
u
)
p(a|u,k_u)
p(a∣u,ku)可以很方便的替换为我们希望达到的总目标,例如DAU、WAU等等,论文作者发现优化DAU要好些,因为WAU会提高不活跃用户的表现,但是会抑制活跃用户的表现,但是网站收入都是活跃用户贡献的,因此使用DAU相比WAU要合适些
对长期影响建模
目标函数应该考虑证正面和负面影响,以前的论文解决方案如下:用户对推送的正面行为设定一个下界,用户对推送的负面行为设定一个上界。但是存在两个问题
①在调整这些参数的时候,不清楚目标函数在做什么优化
②不同的用户组中用户负面行为造成的结果差异非常大,部分用户可能会取消订阅或者离开网站
因此一个全局的负面行为数量限制无法满足捕获这个差异,论文中提出一个对每个用户的长期负面行为的代价进行建模
p
(
a
∣
u
,
k
u
)
=
∑
s
p
(
s
∣
u
,
k
u
)
×
p
(
a
∣
u
,
k
u
,
s
)
p(a|u,k_u) = \sum \limits_sp(s|u,k_u) \times p(a|u,k_u,s)
p(a∣u,ku)=s∑p(s∣u,ku)×p(a∣u,ku,s)
其中
∑
s
p
(
s
∣
a
,
k
u
)
=
1
\sum_sp(s|a,k_u) = 1
∑sp(s∣a,ku)=1
p ( s ∣ u , k u ) p(s|u,k_u) p(s∣u,ku)表示用户 u u u 在本周的推送 budget 为 k u k_u ku下采取的动作为 s s s 的概率,这里 s s s 可以表示为取消订阅和不取消订阅两种,也可以表示其他的,只要满足 ∑ s p ( s ∣ a , k u ) = 1 \sum_sp(s|a,k_u) = 1 ∑sp(s∣a,ku)=1就行。
论文这里使用两种可能采取的操作,取消订阅和继续订阅两种,那么用户取消订阅的概率为
p
(
s
u
n
s
u
b
∣
u
,
k
u
)
p(s_{unsub}|u,k_u)
p(sunsub∣u,ku),用户取消订阅后会在一段时间后活跃度才会保持稳定,因此论文使用
p
(
a
L
∣
u
,
s
u
n
s
u
b
)
p(a_L|u,s_{unsub})
p(aL∣u,sunsub)来表示用户取消订阅后的稳定活跃度。也就是说,如果用户继续订阅,使用当前的活跃度,如果用户取消订阅,使用一段时间以后的稳定活跃度,这样就可以考虑到用户取消订阅的长期影响。因此,公式可以具体化如下:
p
(
a
∣
u
,
k
u
)
=
p
(
s
u
n
s
u
b
∣
u
,
k
u
)
×
p
(
a
L
∣
u
,
s
u
n
s
u
b
)
+
(
1
−
p
(
s
u
n
s
u
b
∣
u
,
k
u
)
)
×
(
a
∣
u
,
k
u
,
s
s
u
b
)
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,ku)=p(sunsub∣u,ku)×p(aL∣u,sunsub)+(1−p(sunsub∣u,ku))×(a∣u,ku,ssub)
模型和算法
三个模型:活跃度预测模型 p ( a ∣ u , k u , s s u b ) p(a|u,k_u,s_{sub}) p(a∣u,ku,ssub)、取消订阅预测模型 p ( s u n s u b ∣ u , k u ) p(s_{unsub}|u,k_u) p(sunsub∣u,ku)、取消订阅的长期影响模型 p ( a L ∣ u , s u n s u b ) p(a_L|u,s_{unsub}) p(aL∣u,sunsub)
一个算法:计算用户之间的最优化budget分配
模型使用逻辑损失函数。根据用户能接触到的推送渠道,将用户划分为了3类。这3类用户的表现模式内部有差异,需要在每类用户里面都训练下面3个模型。
① 仅接收emai的用户
② 仅接收push通知的用户
③ 既接收email又接收push的用户
活跃度预测模型
用户访问网站可能来自不同的推送渠道,而且不是相互独立的,这里使用XGB捕获这种非线性影响。模型这里使用的训练数据来源如下:给一组用户随机设定推送量,收集他们的反馈,这样的话,相当于给定了用户 u u u 和 每周推送budget k u k_u ku,来直接预测用户活跃情况 p ( a ∣ u , k u , s s u b ) p(a|u,k_u,s_{sub}) p(a∣u,ku,ssub),如果这这一周里面,用户每天都是活跃的,那么产生一条正样本 ( + 1 , u , k u ) (+1,u,k_u) (+1,u,ku),否则产生负样本 ( − 1 , u , k u ) (-1,u,k_u) (−1,u,ku) ,这里不论用户是通过哪个渠道(邮件、Push)访问网站都算作当天活跃,这样做的好处实际上是将不同的推送渠道考虑进去了。
取消订阅预测模型
如果用户本周取消了订阅,生成一个正样本 ( + 1 , u , k u ) (+1,u,k_u) (+1,u,ku),否则生成一个负样本 ( − 1 , u , k u ) (-1,u,k_u) (−1,u,ku),这里的 k u k_u ku 是本周的 budget ,不是本周本周推送改动实际发送量,因为用户取消订阅之后我们就无法向其发送推送了,如果采用实际的发送量,那么在训练数据中会出现一种情况,推送量少反而取消的概率较高,这与实际不符。
取消订阅的长期影响模型
用户在取消订阅之后的第四周活跃度趋于稳定,因此使用第四周的是否活跃来生成模型 p ( a L ∣ u , s u n s u b ) p(a_L|u,s_{unsub}) p(aL∣u,sunsub) 的样本,生成方法和活跃度预测模型一样
特征
① 用户画像特征:国家、年龄、性别等等
② 历史活跃行为:不同时间窗口的用户活跃天数、点击率
活跃度模型和取消订阅模型每周的budget也是一个特征,也是有用的
计算每周budget算法
给用户
u
u
u 发送第
k
+
1
k+1
k+1个通知的效用增益为
p
(
a
∣
u
,
k
+
1
)
−
p
(
a
∣
u
,
k
)
p(a|u,k+1) - p(a|u,k)
p(a∣u,k+1)−p(a∣u,k) ,我们可以将效用增益最低的那部分推送去掉,减少推送总量同时保持活跃度稳定。论文的算法是这样做的,有一个全局的关于最小效用的阈值
θ
\theta
θ ,首先在一个区间
[
k
m
i
n
,
k
m
a
x
]
[k_{min}, k_{max}]
[kmin,kmax] 里面找到最优的budget
i
m
a
x
i_{max}
imax,然后逐渐从
k
m
i
n
k_{min}
kmin 到
i
m
a
x
i_{max}
imax 开始增大,如果某一个更小的budget
i
i
i 与
i
m
a
x
i_{max}
imax 之间的效能差别不大,我们采用更小的 budget 作为用户本周的推送 budget
现在问题来了,怎么找到全局的关于最小效用的阈值
θ
\theta
θ ,使得所有用户的推送总量小于
K
K
K ,通过算法2实现
我们也是在一个区间中寻找,看每一个
θ
\theta
θ 是否能满足推送总量小于
K
K
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 分配算法,能够在大规模推送系统中落地和应用,这一点也是非常赞的。