从0到1搭建消息推送管理平台
一、推送的定义与价值
个人将推送的定义为消息发送方将信息传递给接受者的行为。结合到我们日常的场景,就是公司的运营同学或业务系统将营销消息或通知消息通过短信、push、微信等渠道发送给用户的行为。
每天针对用户的推送消息可以引导用户参加活动、阅读资讯、查看账单等行为,是一块重要的流量入口,推送是推动业务目标的达成的重要手段。
二、本文目的
搭建一套较为完善的公司内部消息推送管理平台,对公司内部各业务线、产品线的消息推送进行统一管理,统一发送;这样既提高了公司的运营效率,又保证了用户体验。
本文的目的主要说明系统的产品设计思路,对于深入的短信、push、微信各渠道的发送机制说明在后续文章进行介绍。
三、推送系统流程
一般来说,消息推送有2种发送方式,一种方式为运营活动批量定时投放,需提供系统功能方便运营筛选用户,然后编辑文案,经审核通过后进行发送。
另一种是需要实时触发的消息,比如支付成功通知、验证码获取、满足某种条件触发的营销活动等消息,这类时效性要求较高且每个用户发送的消息内容中涉及到差异化的参数,需要业务应用实时触发。
触发的消息需经过一定的过滤与拦截规则,针对于短期内已经覆盖过用户进行过滤,异常或者不合规的消息进行拦截,按照设定好的渠道进行推送。
四、数据准备
对于消息推送系统,需要获取投放的目标用户的账号数据,往往公司产品的customer ID和对应推送渠道的账号不一致,需要获取绑定关系,比如短信需要手机号,push需要SDK上报的token,微信需要使用OPEN ID,相关数据的采集在各个渠道的发送机制的文章里进行阐述。
五、消息创建
5.1 投放人群选择
日常的运营活动为了更加精准,提高活动转化率,运营同学会根据一些用户的特征进行筛选,比如北京地区用户,近3天内有登录过APP的用户等等,因此消息投放系统需与公司内部数据部门的标签系统进行对接,提供运营同学投放人群选择。
接口实时触发的消息,一般需要业务系统监控到用户行为,将用户账号与需要的参数通过MQ或者接口传递至消息推送系统进行发送。
也需提供用户账号文件上传功能,以便突发事件需要及时告知用户,避免来不及对涉及用户数据录入标签系统等问题。
5.2 消息类型与等级划分
消息的类型的应以消息内容的目的进行划分,大类可分为通知、营销、验证码等类型。
例如,短信行业内分为通知、营销、验证码类型的消息, 该类型的划分主要为方便路由短信至SP服务商不同通道,不同的通道触达率也不同,为了保证重要短信的触达率,需要将各个内容的短信路由至不同的通道发送。
结合个人经验,公司内部可以根据实际情况进行更细粒度的划分,比如增加通知+营销类型,可能场景为用户支付成功后,在表述完用户支付成功信息后,结合适当场景增加领取优惠文案,引导用户向其他活动转化。
对于金融借贷类的机构,也可增加还款通知类型,主要为用户产生逾期行为需要提示还款的消息;原因为特殊期间,还款通知类短信可能会受特别的管制,单独出来可以进行较好的监控与处理。
对于通知类的消息,也应该按照等级进行划分,比如用户支付成功提示消息和优惠券到账通知消息,显然不应该是同一等级。支付消息涉及用户资金变动,通知等级较高;优惠券到账消息更偏营销类型,通知等级较低。为避免对用户产生更多干扰,需要分级进行控制,必要的时候降低等级较低的消息的推送频率。
5.3 消息内容
不同的渠道的消息,所需要的消息内容不一样,短信内容仅需要短信对话框内的文案即可,PUSH需要展示标题与内容摘要;微信有模板消息与图文、语音等多类型的消息内容。
在产品设计时,选择了对应的投放渠道后,应展示对应渠道所需的字段,且为必填项。
5.4 消息跳转
消息触达到用户后,对于感兴趣的用户需要进一步了解信息,那么目前各类消息的载体不是有足够的空间来展示所有的信息,因此需要跳转到落地页进行详细信息获取。
短信类型的消息需要将长链转化成短链再进行发送,一是为了节省成本,因为短信是按照字符数进行收费的,二是为了用户体验,用户在手机上看到的不应该是一对长的乱码。
PUSH需要根据跳转的不同的页面设置不同的跳转类型,如H5页面和原生页面,跳转协议由客户端提供,消息系统只需要将其配置到系统上,运营同学可以选择就可以。
微信的消息内容一般模板消息条状到H5的活动页,图文消息跳转到文章详情,文本消息中也可以添加超链接,跳转到小程序。
5.5 其他需记录信息
消息发送部门:此数据是用来作为后期短信费用结算的依据,按照消息发送部门扣减公司内部各业务线的费用,对于PUSH、微信消息等免费的资源,也可分析关系各个业务部门对消息资源的使用情况。
转化行为口径:消息点击后的一个环节一般是转化,为了更好地衡量消息发送的质量,应该记录下每条消息下发的目的,比如:订单、实名、激活、下载、通知等,将消息与转化行为匹配起来进行数据分析。
产研负责人:在消息发送之前应该记录好每个任务或模板,对应业务线的产品、研发实际消息的负责人,当消息发生客诉时,通过消息记录查询功能,便可迅速定位消息的产研负责人,紧急确认对应消息是否有异常并解决。
5.6 推送时间设置
对于不同发送形式的消息,推送时间不同。创建的消息任务可以预定时间进行发送;对于已经固化下的营销场景,需设置周期性任务,设置初始执行时间与执行周期,降低运营操作成本。接口触发的时间一般为实时触发,触发时间由业务系统决定。
5.7 在线测试
当消息任务设置好后,需要验证消息投放出去后展示的效果与相关跳转是否正常,避免造成线上推送事故。测试需要发送运营设置好的真实内容,推送对象为内部消息创建者。为避免出现消息误发,测试发送的文案前应添加“测试”,或设置测试白名单,不在白名单内的账号无法进行测试。
六、消息审核
当消息任务或者消息模板创建好,需要经过谨慎审核后才能发送,避免出现工作失误产生不良影响。
审核级别一般需要业务线内部负责人审核与公司平台或者对应职能部门审核。审核要点主要为:消息文案是否符合广告法、消息跳转是否正常、发送频率、时间是否合适等。
七、消息过滤与拦截
消息过滤主要针对营销类型消息,时段限制(早上9点至晚上8点之间可发送)、频率限制(用户7天内只能收到1条短信,针对于周期性任务,同一任务触达过的用户可以进一步扩大过滤周期)、黑名单限制(用户退订)。
消息拦截主要为限制发送量级,比如每个业务线针对同一用户每日最多发送5条短信;公司整体对同一个用户最多发送30条短信;短时间(时间可设置,如300S)内同一用户重复内容过滤;量级的控制只要为避免由于业务系统故障造成的对用户消息轰炸,产生不良影响。
关键词拦截,如包含违法、暴力等词汇。
不同的场景使用的过滤频率可做适当调整,比如用户对短信消息的容忍度比push的容忍度较低,因此短信频率应该更加严格。
八、消息发送
目前经过种种逻辑的处理,消息终于到了发送环节。发送环节主要后台逻辑,重点要优化消息发送的性能,提高消息发送的稳定性,避免业务损失。发送环节应该添加监控并且适当打印日志,以便及发现异常并定位问题。
九、消息路由
短信、安卓push均可接入多个渠道,搭建分发集群。可以根据业务业务逻辑指定通道发送,也可以根据下游通道状态自动路由。
十、数据分析
对于触达系统来说,数据分析一般按照消息的全流程进行分析,包括发送数量——触达数量——点击数量——转化数据。
如果涉及消息对APP进行导流,提高APP活跃,也许统计各消息为带来APP唤起次数。
对于短信来说,涉及到短信费用,需要针对渠道和成功触达条数进行计费,设计对账看板。
短信退订、PUSH关闭等等用户行为数据也需要进行分析,便于调整后续触达策略。
十一、后台管理
通道路由配置
对于短信类型的消息,涉及到签名与通道,不同的业务场景需要不同的短信签名,需要将某些账号、某些模板的消息路由至固定通道侧。以及系统需要根据下游通道性能或状态自动路由消息。
消息发送记录查询
针对于近期发送出去的相关消息,需提供客服侧或运营侧一定的查询功能,以便用户来电咨询相关消息问题,比如未收到验证码消息、没有进行操作却收到消息等等情况。
黑名单
黑名单功能主要应用于消息过滤,当用户投诉或退订后,避免再给用户发送消息,屏蔽的粒度需根据消息类型进行屏蔽,可适当根据内部业务划分。
过滤与拦截规则配置
需针对同一用户设置消息发送上限,避免由于业务系统异常导致对用户造成轰炸。
重复内容拦截,需设置一定时间内,完全相同内容进行拦截,避免重复发送。
关键词拦截,需针对于违规、违法的关键词进行拦截,避免出现运营事故。
针对于营销消息,需根据不同的触达方式,控制触达频率,避免对用户造成干扰,反而让用户对品牌产生反感心理。
上行管理
上行管理主要应用于短信消息,用户回复退订或办理业务的关键词。由于从运营商到发送者的上行过程不能精确到用户回复的是哪条消息(也可能用户主动给某些号码发送短信),为了保证各场景不互相影响,需控制上行关键词唯一。
以上内容为个人经验总结,欢迎讨论指正。