对一般的互金产品，用户打开频率低，因此应用内消息通常用于那些重要程度较低的通知。应用内消息在APP中一般有专门的入口。消息形式也可以是多种多样。在主Tab、消息入口图标中采用小红点或者红色数字以达到吸引用户点击浏览的目的。应用内消息往往与通知栏的推送互为一体。比如点击某个通知栏公告，进入APP应用内消息，自动打开该公告对应的详情页。

4.4 邮件推送

邮件推送的成本较低，但互金账户一般为手机号注册，用户必须完成邮箱绑定。邮件本身不能直接触达用户，且不易于读取，因此用户打开率比较低。多用于活动运营推广或者账户相关信息存档。

4.5 微信服务号推送

相比短信，微信服务号推送更廉价（基本没什么成本）。相比应用内通知，微信服务号推送更能触达用户。当然，推送的前提是要引导去完成微信端绑定平台服务号。

基于以上的总结，不同的消息推送方式在推送成本、限制条件、触达率和适用场景上均存在不同（见下表）。选择哪种或者哪几种消息推送形式就需要考虑不同的运营需求、开发资源的充沛性等来综合确定。

不同消息推送形式的区别

5 后端设计逻辑 5.1 梳理消息推送场景

后端设计的要点在于梳理好各种推送触发的场景。场景梳理目的是为运营提供“精准打击”。关于消息推送场景，本文在第3节有讨论。

下图为常用的推送场景。基础类推送包含了资金、账户、安全相关的推送，等级较高，推送手段采用触发式自动及时推送。扩展类推送包含红包到期、VIP升级等“贴心”的提醒。这类推送等级不高，可采用短信、通知栏自动推送的方式。对于运营类推送，针对不同推送目的采用不同的推送方式，推送手段为“手动+自动“结合。

5.2 搭建推送平台

消息推送的场景梳理好了，就涉及到推送消息平台搭建了。 “触发式”内容推送需要厘清推送的场景、场景对应的推送类型（短信、邮件、应用内消息），消息模板的设置。推送平台还需设置开启或者关闭某种类型。基于不同的产品需求，开发对应的管理界面，方便相关人员的维护与更新。

运营类短信推送一般有专门的第三方短信营销平台，但无法与平台的数据对接。第三方消息推送SDK提供丰富的推送后台，例如友盟提供（通知栏）推送消息和应用内消息推送（包括了启动页和首页插屏），并实现按照版本、渠道机型等维度的消息推送。

但接入第三方不利于统一管理，无法满足长远需求。为了方便统一推送，在开发资源足够的情况下应当将APP推送功能、短信营销平台置于自己的后台管理系统中（后期一定要自己做）。运营人员可以通过设置一定的查询筛选条件（如最近3天注册但未投资的用户），实现消息“定时”、“定点”精确推送。

5.3 限制推送条数

按照分组推送的原则，单一用户可能会接收到多条消息推送。不同的消息推送类别优先级有差异，为了防止对用户的骚扰，分别设置对应的限制条数。基础类推送每天不限制推送数量。每天用户的接收条增值类、运营类推送的条数限制为每天2或3条，每周4-6条。这种限制不是运营人员手动推送的“人为”限制，而是从后端限制推送给用户的条数。

6 前端设计逻辑 6.1 消息推送逻辑差异

作为PM应熟悉iOS与Android系统推送的逻辑差异（不懂的赶紧去补课）。iOS在用户不启动APP情况下依然可以接收到推送消息。Android则与iOS不同，只有APP相关进程（服务）在系统中运行才能收到推送消息。

若iOS用户第一次启动就关闭系统通知开关，则永远无法正常接收APP推送消息。由于iOS用户质量整体好于Android用户，所以这类问题要重点关注并解决（敲黑板！！！）。解决方法是引导用户打开系统底层的通知开关。例如，进入首页或者消息中心，采用通知开启提醒（框）与通知开启按钮（如下图）。

6.2 移动端消息入口