推送系统从0到1(三):推送任务的建立

21 评论 25137 浏览 147 收藏 13 分钟

如何保证把内容准确无误地投递给想要投递的人,这将会是推送系统通信层面的难点。

上一篇文章已经讲述了如何选择推送服务,并梳理了用户与设备、Token之间的关系,用设备号才能精准的标识用户。如果还无法清晰的了解这三者的关系,可以回顾上一篇文章:推送系统从0到1(二):了解你的用户

本篇主要为大家剖析推送任务的建立,如何在搭建推送系统中设计任务建立的过程,同时也可以了解各大推送平台的运作方式。作为系统的设计者,我们除了知道给什么用户在什么时间推送什么内容以外,更重要的是如何保证把内容准确无误的投递给想要投递的人,这将会是推送系统通信层面的难点。

一. 建立自带过滤及净化器的用户池

为了实现把推送内容准确无误的投递给想要投递的用户,需要满足以下几个条件:

  1. 用户是不变的
  2. 用户的‘通讯设备’(设备)是不变的
  3. 用户的‘联系方式’(Token)是不变的

这也是大多第三方推送平台的弊端,当用户‘通讯设备’或‘联系方式’发生改变的时候,部分第三方推送平台会把该用户当成‘失联’的用户,再也无法联系上该用户,此时用户变成为无效用户。因此运营童鞋经常会发现,推送效果越来越差,到达率、点击率越来越低,其实是其中的许多用户已经失联,再也无法把消息发送给该用户。这些无效用户既然收不到推送,也自然不会产生点击,但是却会让推送的目标用户数虚高。所以这三点在推送任务建立之前,必须通过产品设计的角度,让其成为“不变的”。

建立用户、设备、Token的绑定机制

如果阅读过我上一篇文章就会知道,我把用户、设备、Token的关系比喻成用户、电话、电话卡之前的关系。想要用户永远不换电话或者不换电话号码似乎并不现实,所以改变是必然存在的,重要的是通过我们对其关系的梳理,即便发生了改变,我们仍然知道这个用户是谁,用的是哪个设备,如何联系该用户。所以首先我们建立三者的绑定机制。

以上三种情景在实际过程中经常会出现。除此以外还有第四种情景,即设备及Token未发生改变,但用户发生了变化,此情况多出现在用户在同个设备上登陆多个账号时出现,该方式主要的处理办法为账号信息同步,在此不做过多的阐述。以上方式能够解决大部分情况下由于设备或Token发生改变时,该用户变成了无效用户的问题。那么综合以上三种情况,我们在设计用户绑定机制时,应当设计成以下方式。此方式可以最大程度的保证你推送的用户是有效的,真实的,且是你认知的那个用户。

  1. 一个用户对应多个设备,一个设备对应唯一的Token。
  2. 当Token发生改变,则用新的Token替换原来的Token,并与设备绑定。
  3. 当设备发生改变,Token未变时,则用新的设备绑定旧Token及用户。
  4. 当设备发生改变,Token发生改变时,使用新的设备(及其对应Token)绑定用户,同时旧设备可做有效性检测(如模拟发送测试等),若旧设备无效则解除与用户绑定。

具体流程可见下图:

按照以上方式,即可尽可能的保证用户的“不变”,不管用户设备或‘通讯方式’如何更换,该用户仍然是原来认知中的用户,并且有‘最新最有效的联络方式’。该方式如同一个自带过滤和净化器的池子,尽可能的保证池里的‘生物’健康有效的存活。但是即便如此,在建立推送任务时,还是需要做有效用户的筛查。因为仔细研究上述方式,就会发现一个弊端,不管哪种方式重新绑定或者替换,都建立在用户‘主动’告知其设备信息发生改变的前提下。若用户不告知,则系统仍无法进行过滤和关系的重建。所以有效用户的筛查就很有必要。

二. 有效用户的筛查

在建立推送任务时,进行有效用户的筛查就是针对类似于用户卸载APP后,Token已经失效,但是用户无法回报该信息。此时我们仍把这个用户当作是有效用户进行发送,最后的结果就是该用户收不到。这是大多数推送系统在建立推送任务时一定会做的有效用户的筛查(甄别)

建立推送任务时,我们会选择目标用户,此时根据条件在上述构建的用户池中捞出我们的目标用户。这些目标用户在我们带有过滤系统的用户池中已经拥有最新的联络方式了。但就像我所说,即便如此,仍可能存在用户的设备或Token已经失效,但无法及时汇报给系统的情况,例如APP卸载、APP重装但未开启、更换设备后未登录过等。所以把用户捞出来后,首先要做的就是有效用户的筛查。我们可以通过以下方式判断该用户的设备或Token是否有效:

  1. 查询设备的浏览情况,此方式需要提前埋点记录用户行为(后续做精准推送的必要条件)。
  2. 查询设备的账号登陆情况,若设备关联账号已经发生变更,可能该设备已属于其他用户。
  3. 查询该设备上次推送,上次推送服务返回的状态可以检测Token有效性的。
  4. 疑似无效设备的预推送,在与客户端预先约定好的情况下,发送推送测试来检查Token有效性,但需要在用户设备不会受干扰(不会显示)的前提下。

通过上述方式,可以把无效的用户进行标记,从本次推送任务中删除,并进入黑名单。关于黑名单机制在后续文章中将会详细讲解。此时便完成推送任务的第一步,从用户池中捞出用户,并进行有效性的筛查。在完成以上步骤后,推送消息的下发成功率将达到95%以上。(苹果返回的下发成功情况没有参考价值,部分第三方平台返回的下发成功情况也存疑)当我们尽可能准确的选出有效用户之后,如何把准确的消息发给这些用户呢。

三. 推送任务的建立

像小时候学习写作文,记事文的几个要素:时间、地点、人物、事情。那么建立推送任务也是如此,上述我们已经讲了人物的部分,我们已经把有效的用户确定了,如果想要给不用的用户发送不同的内容,后续文章讲解精准推送的部分将会详细讲到,本次不在阐述。那么此时需要确定的是发送时间、发送设备、发送内容。

  1. 发送时间:从发送时间开始,推送任务开始执行,批量/逐个发送到用户的设备上。
  2. 发送设备:上述筛出有效用户的设备,设备系统(Android、IOS、PC等),通知推送的方式(应用内推送暂不阐述)。
  3. 发送内容:推送通知的标题、内容、图片、其他富文本、推送的着陆页等

梳理上述内容及推送任务之间的关系,可以从下图中看出来,设置发送时间,将会作为任务执行时间,而发送设备决定了用户在哪个设备上接受什么类型的消息。发送内容中的通知信息将会在用户的设备上的通知栏展示。设置着陆页将会是用户点击之后跳转的页面。

此时在设置好这些内容后,推送系统将按照时间执行任务。用户收到消息将会看到你设置的通知内容,若用户有兴趣点击,将会跳转至你设置好的着陆页。此时推送任务的建立即完成。关于内容的设计,蕴含很多运营知识,将会在后续介绍推送运营的时间进行详细介绍。不过值得注意的是,推送内容如标题、内容、图片等等,会因为设备端的展示限制和系统支持的富文本情况将有所区别,如果IOS 10及以上系统支持富文本推送,Android系统支持自定义通知栏。运营人员在使用个性化的推送内容展示时需要与客户端有所约定,关于客户端所支持的通知内容展示情况,将会在下一篇中进行详细介绍。

四. 推送任务如何传输

在推送任务建立之后,通知消息经过推送系统的几个过程最终达到用户的设备上,消息是如何从推送系统到达用户的设备上的?通知消息在传输的过程中是否会遇到困难,消息在设备上是如何展示的?请期待下一篇“推送系统从0到1(四)通知消息如何达到设备”

五. 总结

本篇文章主要阐述了建立有效过滤机制的用户池到建立推送任务的过程,归纳成以下3点:

  1. 建立有效的用户池:获得用户最新的‘联系方式’
  2. 建立有效性筛查机制:无效设备统统剔除
  3. 建立推送任务的要素:推送时间、推送设备、推送用户、推送内容(标题、文案、图片、其他富文本、着陆页)

相关阅读

推送系统从0到1(一):是系统不是工具

推送系统从0到1(二):了解你的用户

 

本文由 @番茄那只羊 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的真好,刚好最近在研究推送系统,受教了!!!

    来自湖南 回复
  2. 牛逼!!!!!!

    来自广东 回复
  3. 【在完成以上步骤后,推送消息的下发成功率将达到95%以上。(苹果返回的下发成功情况没有参考价值,部分第三方平台返回的下发成功情况也存疑)】IOS不使用苹果返回的下发情况,那怎么才能准确统计下发成功率呢?

    来自四川 回复
  4. 设备发生改变,Token未变,这种情况怎么理解,不是设备对应唯一Token吗,若果设备改变了Token也会跟着改变吧。

    来自河北 回复
  5. 楼主后续的文章没有呢吗

    来自福建 回复
    1. 更新了哦~您可以点我头像进去~ 🙂

      来自广东 回复
  6. 我是做APP推送的(假设用户唯一标识是手机号就是会员ID),有些疑惑的是作者说了这么多设备号作为推送唯一标识,是不是大前提是与该设备绑定的手机号必须是我APP的有效用户,其实在筛选目标设备的时候,已经在用手机号作为唯一标识了,否则空记录设备号是无意义的;那么整篇文章的核心思想是否可以理解为以用户当前有效手机号绑定的设备作为唯一标识来推送呢?不论手机号改变,还是设备改变,仅扫描当前有效手机号绑定的设备推送即可?

    来自浙江 回复
    1. 您说的没错,假设APP是必须登录会员账号(如电商类APP),则使用会员ID作为唯一标识更好。同时这个推送系列文章同样适用,只是把我文中所述使用设备号替换成您使用会员账号作为唯一标识即可。感谢~

      来自广东 回复
  7. 哇 写的很系统很专业!楼主在哪里工作呀?要跳槽吗!!~~

    来自北京 回复
  8. 用户‘主动’告知其设备信息发生改变。
    请问这种“主动”是对应的什么场景呢

    来自四川 回复
    1. 这种“主动”体现在用户打开APP
      因为前端需要把“用户设备信息更变”这个消息告诉后端。
      只能通过APP的请求或者相关进程提交数据。
      如果用户不主动打开APP,除非APP自己在后台运行。
      否则前端无法把这个消息告诉后端。

      来自广东 回复
  9. 请问在筛选有效用户时,您提到token失效的情况,这时避免向无效token建立推送任务;
    可是在文章1中不是说使用设备作为唯一标志么,所以是不是有些冲突。如果用设备作为唯一标志,那么不就不用管token,直接按照设备推送就好了。

    来自四川 回复
    1. 1.使用设备号作为唯一标识。
      2.当token失效的时候,请将该token对应的设备号标记为“不可推送状态”,当这个设备号对应的token发生变化后,再重新标记为“可推送状态”。
      3.直接按照设备号推送也可以,如果避免向无效token推送有以下两个好处:
      1)避免因为token失效导致推送任务被中断,提高推送效率
      2)在计算推送成功率的时候,无效token会导致推送成功率被降低,与实际不符。

      来自广东 回复
  10. 请问一下。如果设备改变,Token改变,该如何判断该用户使用了新设备?

    来自北京 回复
    1. 如果有会员ID(登录)功能,可以通过会员ID绑定设备。当会员在新的设备登录后即可知道。
      如果没有会员ID,可以寻找是否有与网站相关,且可标识用户的凭证替代会员ID实现。
      如果都没有,那么相当于一个新用户,很难关联起来。即使通过对比两个设备的行为相似度,仍存在准确度和成本过高的问题。

      来自广东 回复
  11. 加油 等你更

    来自北京 回复
    1. 已经更到第七篇了哦
      http://www.woshipm.com/user-research/1413267.html
      感谢支持~~ 🙂

      来自广东 回复
  12. 写的很棒啊,感觉学到好多。加油加油 😉

    来自上海 回复
    1. 感谢支持~~ 😳

      来自广东 回复
  13. 😉

    来自广东 回复
    1. 😳

      来自广东 回复