App产品设计『运营工具』消息系统
这是《App产品设计指南》系列文章的第24篇内容,更多精彩可以点击下方链接查看。
本文是运营篇的最后一篇文章,会和大家聊一聊消息系统。前面说到的消息推送是特指push推送,而本文提到的消息推送针对消息系统而言,使用统一的管理平台向平台的不同产品,不同人群推送不同的消息类型。
消息系统的定义
消息系统是指传递消息给用户,让用户及时获取消息并处理的系统。
消息系统最重要的两点分别是:
1.及时提供给用户最新的消息,包括用户希望获知的和平台希望用户关注的消息。
2.引导用户做出下一步动作。
推送形式
1.push推送
上一篇文章有针对push的详细介绍,这里不再赘述。用一句话总结push推送就是曝光率极高,但是点击率极低。
2.站内信
站内信也叫消息中心,是聚合展示平台内各种消息的地方,一般会与小红点或者数字角标配合展示,引导用户来点击查看。和一次性的push推送不同,站内信是长期有效的。站内信也可以展示push推送的内容,至于是否需要是要根据平台属性来判断。
3.微信模板消息
公众号和小程序的用户在进行提交表单、支付等关键性操作后,平台可以按照微信提供的模板推送消息。平台是不能主动向用户主动推送消息的。
用户一般很少会拒收微信模板消息,所以平台一定要秉承不骚扰用户的原则,只给用户推送有必要的内容。
4.短信
使用第三方服务平台向用户推送短信。平台在短信服务商处设置模板,在使用的时候根据模板编号传递变量,短信服务商会自动发送短信给目标用户。单条短信的内容是有限制的,汉字限定为70字,英文字符限定为160个。部分行业监管比较严格,发送短信有严格的审核,比如金融,教育等行业。
5.邮件
目前使用邮件的场景相对较少,需要根据场景来判断是否合适。比如用户订阅的周期性报告就可以以邮件的形式下发。
消息类型
1.用户之间的消息
主要包括评论、回复、留言、私信等类型。
2.系统消息
主要包括系统推送的公告提醒(如版本更新,新功能发布等)、涉及到业务行为的通知(如订单物流进度,收益分成信息等)。
消息的种类是由业务决定的,网络上的经验仅仅是参考,决不能生搬硬套。
提醒对象
1.单方
消息提醒的对象涉及到一方,比如说用户订单的物流信息。
2.多方
消息提醒的对象涉及到多方,比如内容创作者生产品的内容被多人订阅,如果更新内容就需要向多个人推送消息。
提醒类型
1.手动推送
运营设置文案,选择目标人群,设定时间进行发送、
2.自动触发
系统自动给符合条件的人群推送短信,可能是实时的,也可能是在固定时间发送。
消息合并
消息合并是指将场景比较接近的消息进行合并统一发送,不但能减少骚扰,方便用户理解,还能减少服务器压力,提高效率。
消息合并的规则可以简单概况为:合并固定时间内容未读的消息。这里面包括两个因素,一个是固定时间;一个是用户未读,已经发出的消息在用户未读的前提下也是可以合并的。举一个简单的例子,在知乎的消息系统中经常会看看这样的消息“A、B回答了问题XXXX”。
消息已读状态
push推送、微信模板消息、短信、邮件目前暂时是不能判断用户是否已读的。
站内信则可以通过设计判断用户是否已读。在一些App中用户没有登录也是有站内信(消息中心)的。用户已读状态的判断一般有以下几种方案:
1.点击进入消息列表就视作已读,注意此时是把第一页置为已读,向下滑动才会把第二页置为已读。一般用于重要级别较低的消息,比如网易云音乐,知乎等产品。
2.用户点击点击单条消息,进行相关操作视作已读,比如王者荣耀的活动提醒。
3.使用“全部置为已读”将全部消息置为已读。
后台管理
消息系统的后台管理一般分为两个维度,一个维度是按照提醒类型划分,分别是手动推送和系统自动推送;一个是按照推送形式来划分,分别是push推送、站内信、微信模板消息、短信和邮件。
在后台中系统自动推送的消息模板是预先设定的;手动推送的消息则是预先填写文案,由运营人员来选择推送人群、时间等因素。
在根据不同场景设定模板后,需要对模板进行审核和测试。其中审核一般是由业务部门来完成,主要是对发送的文案、跳转目标、推送时间等因素进行审核。测试环节则是给内部白名单人员进行推送,测试推送环节是否流畅。如果发现有问题需要进一步调整。
消息系统是平台运营的重要补充形式。用户反感的并不是消息推送本身,而是无意义,纯营销性质的消息。给用户推送符合预期或者超出预期的消息往往能取得意外的收获。了解底层原理,设计出符合要求的消息系统是产品经理的基本功。希望本文能对大家有所帮助。
在写作过程中,如果有意见或者想法,欢迎有兴趣的读者添加我的微信一起交流探索,共同进步。