本篇文章目标是通过以通俗易懂的方式向大家介绍消息通知的类型、设计到后期运营的过程，从而使大家尽可能系统的了解基本的渠道和使用方式，希望有用。

消息通知作为系统的基础功能，虽然很难察觉，却是完成产品用户体验的重要闭环，也是产品经理应该熟知的最基础功能之一。

网上关于消息通知的文章介绍已经有很多，有的关于样式，有的描述系统模块，有些以营销方式为入口，这些都是非常有参考价值的文章。不过对于我们现阶段要做的功能，这些内容相对零碎，我在整理的时候花了一些时间。

本篇文章目标是通过以通俗易懂的方式向大家介绍消息通知的类型、设计到后期运营的过程，从而使大家尽可能系统的了解基本的渠道和使用方式，希望有用。

主要适合：

（1）初步梳理消息通知

从来没有接触过消息通知的产品都需要花点时间去了解各个消息的渠道和形态机制，除了网上现有的文章，也需要去翻各个第三方或者平台的开发文档，了解功能设计的内容以外，也要了解技术的可行性，对于没有做过的产品和开发都需要花费一定的时间做取舍和沉淀，本文整理的一些主流的方式以及文档链接可以为这类同学节省时间。

（2）满足基本用户体验闭环需求 

设计完整的消息通知系统是较为复杂的，功能上：营销可以做到策略机制，考虑推送的类型和推送时机，进行个性化推送、精准营销；还需要考虑风控机制，如果部门较多，消息资源是统一管理的，需要设计后台的审核机制系统等。

产品上：可以是主营产品例如一些IM工具，可以作为系统的业务支撑功能，也可以作为CRM等其他B端产品的增值功能技术上：如果用户并发量大，为了保证消息的及时性和触达率，可能需要自己完成长链接开发，考虑性能优化等。

所以很难一篇文章很难完整的介绍整个消息通知，这篇文章仅以描述满足用户基本体验需求的消息通知设计。

（3）以移动端的消息通知为主

对于不同的产品类型，消息通知的表象差不多，但是内核却可能千差万别，甚至极具智慧。整片介绍我们将以最能及时收到信息的移动端通知为主。

文章主要为三个部分：

1. 消息通知的主流渠道和形态；
2. 消息通知的产品设计和维护文档；
3. 开发中需要注意的问题这些内容我将尽量在较少的篇幅完成说明。

一、消息通知的主流渠道和形态

通知渠道即可触达用户的各种渠道，他们的显示形态，应用方式各不相同，我将它总结为短信、PUSH、横屏通知、公众号模板消息、小程序模板消息、通知中心/站内信等，还有其他的通知消息形式，这里主要介绍常用的这六种。

1. 短信

（1）渠道定义

短信时是大家较为熟知的通知渠道，发送的条件限制较少。主要包含三种类型，某第三方的基本介绍：

• 验证码短信——接口可以实现给指定手机号发验证码短信，用短信验证码来验证操作者的身份，来确保是本人操作，或者是经由本人授权操作。
• 通知短信——短信在实用工具功能和修辞性事功能基础上又衍生出新的功能形态—文化评判与社会参与功能，而且在这种传媒体的引导和推动下，这种功能日益得到彰显和强化。
• 营销短信——发送一般用于不同行业、不同领域的企事业单位、团体组织机构对于自身产品的推广和介绍，达到加快速或加深沟通联系；提高服务质量；加快工作效率（包括商业销售效率）的手段。

（2）发送前置条件

用户手机号

（3）优缺点 

触达率高（触达率即指发起消息，用户能收到的概率）。另外未收到短信时主要是这些问题：当地区手机信号不好；手机号被拉为黑名单；获取较为频繁。后两个问题都可以在服务商那里进行对接解决，一般短信商可以设置同一手机号在一定时间内最多能收到多少次，建议将你公司的测试手机设为白名单。

时效性高（时效性则是从发起后用户收到的时间，收到的时间越短，时效性越高）。

前置条件要求较少，发送的内容限制较少（当然要热爱和谐，短信模板一般服务商需要审核，不添加模板也可以发送，不过可能会有延迟）。

需要收取费用，不同类型的短信费用不相同。

（4）交互形式 

营销类短信可以放置短链接，点击后可以跳转到指定H5页面。

（5）文档链接

建议查看第三方服务商的技术或设计文档，具体文档链件我就不放出了，以免广告的嫌疑，网上有很多渠道可以查看。

2. PUSH

（1）渠道定义

设备系统通知，使用PUSH推送技术，长见于移动端（Macos和ios的设备通知体验基本一致，Win也有各种形态的通知，这里不再扩展），通知形态包括锁屏、通知中心、横幅（顶部弹窗通知）等，也可以同时传达声音消息。

（2）前置条件

用户设备号

（3）优缺点

时效高；内容类型无限制，和短信的一样发送的内容类型无限制由开发方自行设置。

基本免费，可以自行开发（开发成本较高，但触达率和时效性都很高，后期需求量大时可以使用刺中方式），也可以使用第三方，长用的有极光和友盟（如果用户量不大的时候接入免费服务即可，极光客服反馈如如果需要保证安卓触达（安卓厂商优化系统，在杀死进程后不能到达）可以接入付费，其他暂无收费项目，不过根据其他信息来源在单位时间内api的调用次数可能会有区别，这个可以根据需求机械能对接，另外这里赞一声极光的客服反馈特别迅速。

触达率不稳定，用户需要下载app并打开系统通知，才能收到，同时跟手机厂商，性能，以及网络等原因相关，极光开发文档给的触达率是80%。

（4）交互形式

安卓、苹果可跳转APP指定页面、安卓点击通知栏可下载软件，弹窗样式字数要求可以看各个开发文档；如果需要接入声音，例如语音播报，苹果和安卓有不同的处理方式，这里不再扩展，需要的话可以另外交流。

3. 横屏通知

（1）渠道定义

应用前台的顶部弹窗通知，使用的也是PUSH技术，样式比较多样，可由我方自行定义，应用场景是当用户在在用用前台时需要进行弹窗通知时，需要更多的通知内容和交互形式都可以使用此种通知类型，苹果和安卓都可以使用第三方推送，界面自行开发。

（2）前置条件

拿到用户的设备号

（3）优缺点

触达率高；时效性低，由于需要用户在前台时才能展示，内容类型无限制，交互可自行定义。

（4）交互形式

指定跳转，以及其他交互，交互以及界面样式多样。

4. 公众号模板消息

（1）渠道定义

模板消息仅用于公众号向用户发送重要的服务通知，常用于支付成功后，预约等服务类型消息通知。

（2）前置条件

用户需关注公众号，用户需与公众号有交互，才能发起通知。

（3）优缺点

由于微信的普及率，模板消息触达率高、时效性高、接口不需收费。

前置条件满足较难需要引导用户关注公众号由交互（可以通过活动公众号引流，有支付功能业可以通过微信支付后台设置支付成功后自动关注等等），内容限制较大（设置模板较麻烦、规则多，限制发送内容，如营销类信息）。

公众号通知开发需要进入公众号开发者模式，进入后公众号自带的导航栏、关键词等将不能使用且不能使用其他第三方，需要自行开发。

（4）交互形式

可跳转H5链接

（5）文档链接

https://developers.weixin.qq.com/doc/offiaccount/Message_Management/Template_Message_Interface.html

模板消息仅用于公众号向用户发送重要的服务通知，只能用于符合其要求的服务场景中，如信用卡刷卡通知，商品购买成功通知等。不支持广告等营销类消息以及其它所有可能对用户造成骚扰的消息。

1. 所有服务号都可以在功能->添加功能插件处看到申请模板消息功能的入口，但只有认证后的服务号才可以申请模板消息的使用权限并获得该权限；
2. 需要选择公众账号服务所处的2个行业，每月可更改1次所选行业；
3. 在所选择行业的模板库中选用已有的模板进行调用；
4. 每个账号可以同时使用25个模板。
5. 当前每个账号的模板消息的日调用上限为10万次，单个模板没有特殊限制。

可添加模板，但需要符合规则和通用性。

5. 小程序通知

（1）渠道定义

小程序提供的一种模板通知，基于微信的通知渠道，提供了可以高效触达用户的模板消息能力，以便实现服务的闭环并提供更佳的体验，使用场景例如拼团成功、下单成功等等。

（2）前置条件

拿到用户的openid，用户需在小程序完成支付或发送表单，需使用公众号已有的消息模板（新模板需微信审核）。

（3）优缺点

触达率高，时效高，前置条件满足较难，内容容限制最大（设置模板较麻烦、规则多，限制模板，限制发送内容，如营销类信息）。

（4）交互形式

可跳转指定小程序页面。

（5）文档链接

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/template-

（6）其他

小模板消息于2020年1月10号即将下线，小程序提供了另外的“订阅模板”，和小程序一致需要申请模板，如果在小程序已经申请过模板，很不幸，需要从头来过，另外通知的前置限制更加严格，需要用户同意订阅后才能通知。

https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/subscribe-message.html

6. 通知中心/站内信

（1）渠道定义

服务、业务、营销、即时通讯等各个类型的通知的应用内通知中心。

（2）前置条件

大部分需要用户登录查看，部分公共信息无需登录。

（3）优缺点

触达率高、时效低、前置条件较难满足需要用户下载且登录、内容无限制。

（4）交互形式

交互形式较为自由。

二、结语

以上的通知形态即可以单独出现，也可以组合配合，另外还有其他的通知渠道，例如电话（无障碍设计）等，具体运用和优先级产品形式定位相关。了解了相关的条件基础，只是第一步，重要的是怎么运用这些渠道形态，设计消息内容。

本文由 @笠槑 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议