这是《App产品设计指南》系列文章的第24篇内容，更多精彩可以点击下方链接查看。
《App产品设计指南》专栏目录
本文是运营篇的最后一篇文章，会和大家聊一聊消息系统。前面说到的消息推送是特指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推送、站内信、微信模板消息、短信和邮件。
在后台中系统自动推送的消息模板是预先设定的；手动推送的消息则是预先填写文案，由运营人员来选择推送人群、时间等因素。
在根据不同场景设定模板后，需要对模板进行审核和测试。其中审核一般是由业务部门来完成，主要是对发送的文案、跳转目标、推送时间等因素进行审核。测试环节则是给内部白名单人员进行推送，测试推送环节是否流畅。如果发现有问题需要进一步调整。
消息系统是平台运营的重要补充形式。用户反感的并不是消息推送本身，而是无意义，纯营销性质的消息。给用户推送符合预期或者超出预期的消息往往能取得意外的收获。了解底层原理，设计出符合要求的消息系统是产品经理的基本功。希望本文能对大家有所帮助。
在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。