雷锋网按：本文作者馒头（微信公号：PRODUCTER），阿里巴巴产品经理。
消息推送算是产品设计中最常见的功能点之一，但是这小小的功能点总是有人在不断犯错。那么，我们在设计消息推送的时候，都需要注意哪些点呢？
“喂，有个需求！这里我们需要发送一条消息触达用户，消息文案等会给你，麻烦尽快搞下。”
一句话需求，如果你是开发GG，你接这样的需求么？
不接，为啥？
其实，细细想下这个需求，有很多问题：
1、消息以什么渠道通知到用户？
2、发送的频次控制是多少？
3、合适的消息触达用户时间段？
4、消息文案是固定的还是半固定半配置的？
5、触达至哪些用户？
……
另外，上述的问题再作拆解，还会衍生出更多的细节问题，那这些将会在下面一一详述。
渠道？Channel。很简单，今天我要从出发地A到目的地B，选择交通工具：自行车，公交车，出租车，动车，飞机……那这些交通工具其实就是Channel。
同理，今天定义从平台侧发送至用户侧的一条消息，消息渠道：电话，短信，邮件，客户端。比如说，在使用钉钉的“Ding一下”功能时，会提供你选择消息触达的方式。
但有一个问题需要考虑，就是当渠道不单一情况下，如何恰当地选择渠道就要强依赖于消息的需求背景。比如，这条消息是交易相关，涉及到资金变动的通知，那么选择短信渠道则可能是最为合理和稳妥的方案，注意前提是你需要“知道”用户的手机号。
但如果消息对于用户侧的重要性来说较弱，可能选择客户端PUSH的方式更加适合，因为毕竟走短信渠道，还要涉及到预算控制。
消息什么时间触达至用户侧比较合适？事件即时触发还是定时消息推送。
即时触发，也就是当定义的“事件”发生时，系统直接推送消息至用户侧。优点是即时性强，尤其对于特别紧急重要的消息，会更倾向于选择这种模式。但缺点就在于可能会导致较差的用户体验。比如用户在深夜2点收到平台推送的消息，如果是你，你会不会抓狂？
定时推送，顾名思义，定义消息推送的时间。优点是过程可控，比如考虑到用户的工作和生活习惯，将消息推送的时间控制在10:00-20:00范围内，会降低用户对于消息推送的负面情绪。另外，当消息内容或通知渠道出现重大变更时，可控性和灵活性都是ok的。但缺点在于，往往会造成消息积压，队列往往会导致消息延时。
所以更合理的方案，就是视不同的消息需求背景，来选择不同的推送时间模式。
频次控制，又称疲劳度控制。什么意思？就是今天我要通知你一件事情，通知1次还好，但是同样的消息我在一天之内通知了你10次，你烦不烦？
同样，消息的触达频次上一定要作好合理控制。否则，久而久之，一是体验上的问题会引来投诉，从而造成用户体验损伤；二是引致用户对消息无感，无意或有意忽略消息通知。
就问你一个问题，现在手机垃圾短信泛滥的今天，你还会看短信内容么？或者一个微信群，积压的200+条会话，你还会点击进去滑屏浏览么？
这条短信发送给谁？群发还是单点传递。如果是单点传递，还要考虑如果线上维护的客户资料信息中，对于同一用户ID有多个手机联系方式，应该通知到哪个手机号码。
这种情况下，我们默认选择取第一个手机号码。那如果你问，假如该手机号码已作停用，用户接收不到消息怎么解决？不能解决。毕竟不可控制，哪怕做金融产品，也允许有一定的资损率出现。
但如果是通过客户端发送消息，可能这种问题出现的概率比较低，唯一的风险就在于用户把手机应用卸载了。
什么情况下会存在变量配置的问题？消息文案定义上属于半固定半配置。
举个例子。描述一个消息场景：当用户成功关注XXX公众号后，平台想要发送一条消息告知用户关注成功。那这条消息一定是有几个关键性变量需要配置的。
#Nickname#，你好。你已于#Operate_time#成功关注XXX公众号。这是阿里Mant.君的个人公众号，我知道你会陪我走下去。
注：变量参数Nickname代表用户昵称，变量参数Operate_time代表关注时间。
其实，给出消息文案并不是技术同学关注的问题，反而文案里的变量参数才是技术同学重点关注的对象。因为，变量参数的设定决定了事件的关键属性，影响着参数传递和获取问题。你现在Get到开发的点了么？
所以，下次开发再催你给消息文案时，为了不影响研发进度，先把参数变量给到他们，然后再慢慢思考短信内容如何定义，这是我总结的一条小tip。
当然，如果消息内容是固定的，变量配置也就无需考虑了。
嘚吧嘚了这么久，不难发现，其实一句话需求距离代码可落地实现，差的真不是一丁半点。
所以，多提靠谱需求，否则小船说翻就翻。
嗯，结合今天的文章内容，抛个“通信系统”给大家了解下。
下图表示了一个典型的通信系统，包含了Roman Jackson提出的通信六要素：发送者（信息源）、信道、接收者、信息、上下文和编码。
感兴趣的同学，可以自行了解。
本文由人人都是产品经理授权雷锋网发布。未经许可，禁止转载。
正在生成分享图...
木子