消息推送(push)作为在App运营中经常会使用到的一种手段，能够低成本、点对点的向用户传达明确的信息。但同样的，消息推送作为运营人员与用户间最近距离的一种接触方式，若使用或设计不慎，也可能会引起很大的负面作用。甚至会因骚扰用户而导致应用被卸载。

　　最近在做一款社交类微信小程序时，我也遇到了一个与推送相关的问题。在解决完自己的问题后，我想梳理一下自己解决该类问题的思路，一方面为了加深自己的理解，查漏补缺。另一方便也希望能够为需要的人提供一点设计时的建议。

　　一、内容优先级

　　需要推送的信息，一类是为了实现基本功能所必要的硬推送信息，一类是作为运营手段的软推送信息。前者在推送中的优先级是大于后者的，尤其是在有大量的需要被推送的内容时，设计者应懂得取舍和权衡。

　　合理分类好应用中涉及到的需要被推送的不同信息，并给予不同的推送方式，可以帮助我们有效的维护好与用户间的亲密关系，避免踩到雷坑。

　　从这一维度看，硬推送信息的优先度自然是大于软推送信息的。

　　其次，若按照与用户相关角度看，通知信息可分为：用户相关信息和用户不相关信息。前者的推送优先级自然是所有的信息优先级中最高的。而在用户相关信息中又可以划分出许多类别的信息层级。比如 ：

　　1、用户的敏感操作行为带来的反馈信息。这类信息在游戏和社交软件以及涉及到金钱交易的操作中最多见。比如探探的匹配成功，付款时的身份验证，clash of clans的建造完毕提示，订单的状态更新。

　　而如何界定“敏感”程度，还要看该项操作的紧迫性和应用核心功能的相关性。比如，投诉类信息虽然与一些应用的核心功能无关，但是作为牵动到用户情绪的敏感内容，一定要慎重对待，优先推送。

　　2、用户的一般性操作带来的结果通知。一般而言，能够在很短时间内得到结果的操作，尽量给予即时的通知。而对于需要消耗一定时间才能得到结果反馈的操作，比如媒体的下载，后台的处理结果等，也尽量在第一时间内向用户告知结果。总的来说，这类信息要做到即时通知，保证实时性。

　　二、推送形式

　　主要的推送方式按技术的实现方式上有三类：

　　轮询方式(Pull)：App客户端定期发起Push消息查询请求，来达到消息推送的目的。Pull方案的优点和缺点都比较明显，整体架构简单但实时性较差，我们可以通过加快查询频率，提高实时性，但这会造成电量、流量消耗过高。

　　基于短信的推送方式(SMS push)：通过短信发送推送消息，并在客户端置入短信拦截模块，能拦截短信，并解析后转发给App应用处理。这个方案实时性好、到达率高，但成本很高。

　　长连接方式(Push)：移动Push推送基于TCP长连接实现，消息实时性好，这是目前主流的实现方式，需要维护App客户端和服务端的长连接心跳，会带来额外的电量、流量消耗。

　　按具体表现形式上有：短信形式，系统推送，邮件发送，App内部提示。

　　其中，采用短信的形式，用户触及率最高(不考虑短信被拦截的问题)，但也最容易引起用户的负面情绪。所以短信形式应该用于涉及金钱交易类信息的推送，如行程订单，支付验证;或者频率需求低的安全类问题，比如与账户密改相关的一类信息。

　　个人认为，运营类信息特别是广告类信息，不适合采用短信通知的形式，除非该类信息里包含着对用户有着巨大吸引力的内容。与此同时，一定要在信息结尾提示用户退订的流程与做法。

　　系统通知推送，作为最常见，直接的信息传达形式，也是运营者最喜欢借助的手段。该类方式既可用于传达与主要功能相关的信息，又可传达与运营者意愿相关的信息。而实际上用户愿意主动接受的是前者。

　　所以，运营者要意识到每一次通过系统通知推送其他类别的信息，实际上都是要冒着引起用户负面情绪的一次尝试。只有真正和用户相关的信息文字才会吸引到用户的注意，否则无论标题文案多么精彩，也只能依附于用户片刻的情绪和好奇心。

　　对于采用发送邮件的形式，由于不同用户查看邮箱的习惯不同，导致部分用户无法在第一时间内浏览到邮件的内容(不考虑邮件被拦截)，所以这就意味着该方式不能用于推送时效性较强的信息。但正因为多数用户都有定期查看邮箱的习惯，所以根据这一点进行一些时效性较弱，且具有周期性更新的内容推送是合理的。同时邮箱作为用户的账号管理中枢，也适用于接受与账号安全密切相关的信息。

　　所以，我们在选择推送方式上，要从迫切度、频率需求、实时性这三个方面来考虑。

　　迫切度上：短信>系统推送>邮箱

　　安全性上：短信>邮箱

　　频率需求：系统推送>邮箱>短信

　　(以上排序为，由强→弱)