为什么会有推送消息 

方面起到内容告知的作用，另一方面在一定程度上可以提高用户活跃，在用户流失后也许能够召回用户。

好处

1.信息告知与提醒

消息推送充当着信息分发渠道的角色，平台方有关产品更新、内容更新、活动消息等内容发布，均可以通过消息推送渠道 push 给用户，能够让用户第一时间知晓此类消息。

如果是线上活动类、电商大促等促销活动，用户也能第一时间知晓并参与进来。

2.促进活跃，增强粘性

消息推送也是用户运营的一块阵地，很多产品把它当作和用户交流与沟通的一道窗口。运用得当的推送消息，能够有效的促进用户活跃，提高用户粘性，让用户时不时打开你的 APP 玩起来。

3.唤醒沉默用户，提高留存

有些用户可能玩着玩着就流失了，几个月也不打开一次 APP。通过有趣的推送消息，也许能够唤醒起一部分流失掉的用户。甚至，在用户将要流失之际，作为流失预警机制的一道门阀，防止用户过早流失。

4.提高功能模块使用率

当产品更新版本时，可以通过推送消息第一时间提醒用户，引导用户打开并使用新功能，可以提高特定功能模块的使用率。

坏处

1.骚扰用户，提高卸载率

有些运营同学或者是单纯因为 KPI 的压力，或者是对于消息推送没有建立有效的运营策略，也不了解用户的行为习惯，只是单纯地从己方利益出发——只想要更多地提高用户打开 APP 的频率。

于是，频繁地给用户推送消息，打扰用户，很多时候往往得不偿失，加快用户流失速度，甚至导致用户直接卸载 APP。

2.透支信任，“狼来了”的故事

有些运营同学为了吸引用户的注意力，从推送标题上下功夫，想了很多歪门邪道，常常用虚假标题吸引用户，当用户打开 APP 一看内容，发现跟标题描述得相差甚远。

用户经常会有一种“被骗”的感觉，久而久之，他们明白了你的套路，便不再信任你，当你有真实的内容想要告诉用户时，他们也不再打开了。因为他们潜意识里已经认定——妈的一定又是骗我的！

3.过多无价值内容，造成用户反感与麻木

消息推送能够吸引一部分用户打开APP，但是怎样让用户在 APP 内开心地玩起来，并喜欢上你的APP，这是值得思考的问题。

当然，这取决于很多因素，产品功能层面的，内容价值层面的，视觉美感层面的，交互体验层面的……等等各种因素。

但有一点很重要，既然是内容的push，那么推送的内容当然得是用户喜闻乐见的，如果大部分内容对用户来说毫无价值，很容易导致用户反感。

是什么原理

（1）消息提醒的流程

输入消息》进入消息仓库》发送消息》消息流水》消息详情

（2）消息发送的时间

• 一般为上午9点-10点
• 中午12点-14点
• 下午5点-6点
• 晚上21点-22点

（3）消息推送的类型

• 优惠券到期通知
• 客服即时消息
• 抽奖商品到期通知
• 收藏降价通知
• 抽奖机会提醒
• 订单发货提醒
• 订单退货提醒
• 购物车商品过期通知
• 拼团到期通知
• 各大活动通知

（4）消息推送的规则

移动端获得消息通知主要有两种方式：pull（拉）方式和push（推）方式，下面分别对这两种方式做简要介绍。

pull方式：

pull方式即“拉方式”，这种方式中手机上的应用程序在启动时及经过一定周期会定时连接应用的服务端来获得服务器需要传递给终端的消息，因为此处是终端从服务端主动获得消息，因此称为拉方式。
此方式服务端实现简单，只需要在终端连接上之后把需要发送的消息发送给终端即可，但是此方式有如下弊端：

每个应用终端都需要建立到自己服务器的socket连接，移动终端需要维护多个socket连接，较为耗电，不易于管理。

采用拉的方式，应用在启动的时候会从应用的服务器上拉取消息；启动之后，应用会周期性的连接服务器去检查是否有消息需要拉取，这种方式并不实时，需要等到终端主动拉取的时候服务器才能把消息传递到终端。如果应用频繁检查是否有消息需要拉取，那么耗电会增加，如果检查周期过长，那么会影响消息的实时性。

综上，采用pull方式进行通知消息的传递并不是一个很好的方法。

push方式：

• 采用push方式，移动终端只需要和推送服务器之间保持一个长连接即可。这样移动终端用于推送的socket连接数量就与需要推送服务的应用数量无关了，只需要维持一个终端与推送服务器之间的长连接即可，所有应用的服务端都是直接连接推送服务器并通过推送服务器来把消息推送到终端。而终端也只与推送服务器进行连接即可获得推送的通知消息。
• 推送服务器通过长连接，在消息到来的时候可以立即把消息推送到连接上来的终端上，实时性比较高。

消息推送示意图

消息推送系统逻辑设计图

此图中，推送应用1，2，3为推送应用的服务端，其负责把需要推送的消息放入推送系统。这些应用服务端通过负载均衡服务器来连接到具体的推送服务器。

服务端是Socket.io的集群，供客户端（Web、移动端）连接。集群后面是一个Redis服务器，保存集群中每个节点（我们称之为Cluster）连接的客户端ID。同时Redis里面为每一个Cluster分配了一个队列，保存推送到这个Cluster的消息。

当有消息从某个客户端发出后，所连接的Cluster从Redis里面获取这个消息的目标客户端ID（由于我们同时支持一对一私聊和群组，因此一条消息可能会被推送到多个客户端），然后把消息Push到每个Cluster的消息队列里面。

每一个Cluster都会以阻塞方式读取它所对应的消息队列，一旦发现有消息，就获取并且查看其目标客户端ID是不是连接在这个Cluster上。如果是，就通过Socket.io发送，如果不是就丢弃。然后继续阻塞读取，直到下一条消息到达。

推送消息应该注意什么

推送消息需要分类

据产品形态和业务类型，从大的层面看，可以将消息类型拆分为“IM类”和“非IM类”，非IM类又可以根据其在实际场景中的应用细分以下不同类型：

、非 IM 类

1. 新闻资讯类：如网易新闻、今日头条、天天快报、ZAKER等新闻资讯；
2. 营销活动类：如天猫 APP 预售、大促、满返满减等营销活动信息；
3. 产品推荐类：如天猫、京东关联产品推荐、新品推荐等基于大数据和算法的个性化推荐；
4. 系统功能类：如天猫发货 or 到货物流通知、生日祝福提醒、优惠券过期提醒等与个人信息特征或行为属性相关联的系统内消息push。

推送消息的方式有哪些

推送消息设计的原则

如何推送更为合理

消息推送的时机与场景

时机

这里的时机我们是指每一天的推送时间段。一般情况下，有这样几个时间段可供参考：

1. 上午9点–10点：人们刚到公司，一般不会太忙，此时推送消息打开率比较高；
2. 中午12点–14点：这个时间段是午休时间，人们一般都会看看资讯啊、新闻啊、玩玩微信啊啥的，在 APP 的使用高峰时段推送消息，打开率也比较高；
3. 下午5点–6点：这个时间段人们处于准备下班的状态，比较懒散放松，有时间的话一般会选择玩玩手机，此时推送消息会吸引到用户注意力，不至于被忽略；
4. 晚上21点–22点：结束了一天的工作，吃完晚饭终于可以休息了，在人们看新闻资讯、处理聊天内容或者玩游戏的间隔，推送一条消息，打开率妥妥的。

当然，这些时间段也不是绝对的，肯定也存在例外，这个时间仅做参考。还有一种方法就是——我们可以根据用户的真实使用场景去反推 push 时机。

什么意思呢，也就是说，将自己代入真实的用户使用场景，比如中午吃饭的时候，你一般会做些什么呢？打开微信处理一下一上午没来得及回复的私信？看看群里面都聊了些啥？打开新闻 APP 看看今天都发生了哪些大事？或者撸一把王者农药？

借助真实自己的使用场景，来反推 push 时机，或许能达到不错的效果。

场景

这个是什么意思呢，其实是说我们要根据用户的历史行为去分析，在什么样的场景下去进行消息推送是比较合理的。

举个栗子，天猫的发货 or 到货通知。比如你昨天晚上在天猫买了一件宝贝，今天早上你想知道这件宝贝有没有发货，一般情况下你是不是得打开APP去自己查看，但是如果此时天猫 APP 给你推送了一条消息——“您的宝贝已经乘坐10086号专机来找你啦！”你是不是很开心？是不是感觉体验棒棒哒。

其他可能的应用场景，比如优惠券到期提醒，生日祝福提醒等，也是一样的道理。

Part4：消息推送的内容

这是消息推送机制的重中之重，能否第一时间抓住用户的注意力，吸引用户打开APP，一个好的标题显得至关重要。关于标题文案的设计，有以下几点建议和参考：

• 文案要简洁，直击重点，与用户自身强关联，刺激用户触发。
• 标题设计要遵循「AIDA法则」。（何谓AIDA法则：attention-引起注意，interest-产生兴趣，desire-唤起欲望，action-点击或购买行为）。
• 标题可以采用「数字+表情」的形式，数字的表现力要远远大于文字本身，表情则能够提升用户的新鲜感和愉悦感，吸引用户打开查看。
• 内容要与产品属性，业务形态相关，注意别盲目轻易蹭政治敏感，八卦新闻热点。
• 形成场景化文案范式，比如小红书：「场景+关联用户+数字+判定词=一条小红书push」。

1. 场景：国名、交通工具等地域环境或状态，如澳洲、飞机上、约会前···
2. 关联用户：与用户有关的名词、代词等，如女人、你、吃货···
3. 数字：普通数字、排名、百分数等一切与数字有关的词…
4. 判定词：如等于、就该、就够了等词（注意：新广告法规定，极限词不可用）…

定义好 push 落地页

用户打开消息去往哪个页面，这个要定义好。该去首页的去首页，该去详情页的去详情页，该去活动页的就去活动页。

如果你一开始期望用户去的是活动页，结果你定义错了 push 落地页，实际上用户去的是首页。这就比较尴尬了，不仅你的预期目的达不到，而且用户会觉得莫名其妙，也反射出你做事不够细心和专业。

Part5：消息推送的策略

消息推送频率

在讲策略之前，首先说下消息推送的频率。那么如何把握推送的频率才不会引起用户反感呢？有下面几点建议和参考：

1.坚守「克制」

记住一点，喜欢才会放肆，爱才是克制啊。反反复复给推送消息给用户，并不是什么好事啊。

2.根据用户使用频次决定消息push频率

产品形态决定使用频次，使用频次决定消息push频率。比如工具类APP（如高德地图），一般是在用户出门的时候才会打开，频次普遍会比较低；再比如通讯类APP，比如微信，你想想你一天得打开多少次你就明白啦。

所以，根据用户使用 APP 的频次去反推消息 push 的频率，从中摸索出一定的规律，提高消息推送在时间维度的精准度，不至于频繁打扰用户。

3.参考：一般保持一周 3-5 条

消息推送策略

在消息推送的运营过程中不断总结规律，分析用户行为数据，建立和完善一套比较规范的推送策略，可以起到事半功倍的效果。具体如何做，有以下几点建议和参考：

1.标签推送

即给人打标签。基础的用户标签分类主要有设备信息、用户信息、行为信息、优惠信息、其他信息···给每一个用户打上各种不同的标签，再按标签将用户分类，对不同类标签的用户进行差异化消息推送。

2.账号体系推送（alias推送）

利用平台方掌握的姓名、性别、年龄、受教育程度、地域等人口学属性特征，构建用户数据库。对数据库中的用户进行筛选与分类管理，并做针对性推送。

3.多维度推送

以友盟为例，有以下几个维度，供参考：

1. APP版本，分发渠道，地理位置（目前通过ip定位，支持精确到省，直辖市）；
2. 消费力、购买力，群组（华中华南，高富帅，白富美，矮矬穷，单身贵族，屌丝一族等）；
3. 用户活跃度（x天活跃，x天不活跃），机型（包含热门机型与全部机型），性别（男或女）；
4. 多维度组合，取交集或并集推送。

对沉默用户的推送

可以专门设计内容针对沉默用户推送，唤醒沉默用户，提高用户留存，又可以降低对其他用户的打扰。

升级版本的推送

当产品发布新版后，推送消息给到老版本用户，提醒用户更新版本，体验更多新功能。

限制发送速度

一次推送一般量比较大，高达几十万几百万甚至上千万条。为了减少服务器压力，避免高并发，推送时可以限制发送速度，每秒钟发送多少条。

A/B test

实际工作中，我们常常会有多种方案可供选择，但是我们无法确定到底哪个方案更合理。

于是，我们可以针对不同人群做A/B test。包括两个维度——人口结构数据与历史行为数据。

凡是 A/B test类测试，操作手法都是类似的。控制好其中一个变量即可。此处不赘述。

push人群

push人群包括定向push和全量push。其中定向 push 虽然覆盖面窄一些，但可以大幅度提高push匹配度；而全量 push 则覆盖面大，但精准度低。

可谓是各有千秋，具体怎么做，运营同学需要在日常工作中慢慢摸索，及时调整。

定义多类push优先级

上面提到了消息有多种类型，对应到实际工作中，我们也会有多种消息需要 push 到用户侧。那么怎么去评估这些消息的优先级呢。参考：一般系统功能类>营销活动类（有例外，如电商大促）

文案赛马机制

另一种形式的 A/B test。具体怎么做呢？

运营写出若干条文案（如5条），然后提前抽取部分实验用户出来（比如用户总量的10%），每一条文案发送实验用户中的一部分（10%÷5=2%，即每条文案发送给实验用户量的2%），观察一段时间内每一条文案的点击率，点击率最高的文案胜出，然后这条优胜文案再发送给剩余的用户（90%）。

Part6：消息推送的数据指标

关于消息推送，有以下几个数据指标供参考：

到达率（到达人数/发送数量）

这里需要注意下到达率低的原因，主要有两个原因：

1. 技术通道原因
2. 用户主动关闭消息推送权限

打开率（打开人数/到达人数）

转化率（转化人数/打开人数）

卸载率（参考：推送1小时后卸载人数/到达人数）

为什么是1小时呢，这个是有人根据实际工作中的数据分析和经验总结得出来的，忘记在哪看到的了。

接收 push 的留存率=2*未接收 push 的留存率

这是什么意思呢，意思是说在某一段时间内，接收消息 push 的用户留存率是未接收消息 push 的用户留存率的2倍。

Part7：技术层面

最后，简单说下技术层面我们可以做的事情，有以下两点参考：

半自动push

一开始产品不成熟，用户体量较小的情况下，没有数据可供参考，消息推送处于测试阶段，可以完全由运营同学人工push。

随着产品发展起来后，基于对用户的理解和用户历史行为数据的采集与分析，加之消息推送时间的限制，不可能全部都交由人工处理。

要把消息推送规范化一种机制，解放一部分人力——让 push 规范化、产品化，形成 push 事件，由半自动系统发送。

何为半自动化事件？

半自动化平台的「事件」描述整个运营行为，由「具体人群」、「触发条件」、「运营规则」和「调度机制」构成。事件具实时性、突发性的特点。

一个事件包含：满足什么条件，做什么事，这件事具体做什么，何时以及如何来做这件事。

调度机制：如调度 push 系统、用户标签系统、关联系统相关数据等。

去重过滤

上面提到我们会有多种类型的消息push，把握不好的话会导致一个用户每天收到很多条消息，造成用户骚扰。

因此，我们需要制定规则，确保一个用户每天最多收到 N 条push（N一般是2），且优先收到优先级更高的push。

举例：优惠券过期push、活动上线push、生日祝福push、个性化push等多类 push 需去重过滤。

结语

本文思路来源于日常 APP 使用观察与经验、笔者项目经验、跟同行的探讨交流、网上文章分析参考等。

旨在从多维度尽可能全面的整理出一篇关于 APP 消息 push 的文章，并非完全个人原创。请知悉。

最后的最后，把这篇文章的脑图分享给你。希望能帮到你。

以上，就是我想分享给你的。

推送内容怎么设计  有帮助，个性化，不要垃圾。

一、用户决定了推送平台的选择

为了实现消息的传递，搭建推送系统的第一步，就是选择靠谱的推送平台实现消息精准无误的传递到用户的设备上。

作为产品经理的我们，对推送的实现技术也许没有那么深入的了解，此时在做选择的时候，也许就会在网上查找各种资料，尝试各种推送平台。

但其实，你的用户已经决定了你该如何选择。

1.浏览器推送还是APP推送？

相信问题的答案非常显而易见，大家应该都会选择APP推送，因为在国内大多数站台其APP用户已经占站台80%以上的用户。

但这里还是要说一下，如果你的用户在浏览器（PC、触屏）有一定比例，也可以尝试进行浏览器推送，让整体推送效果最大化。

以我自己为例，我们站台主要面对台湾市场，而用户在PC和触屏端占比有近60%，因此浏览器推送也在我搭建推送系统的范畴内，并且也取得不错的成效。相信此时大家心中也有答案了，看那个设备端用户占比最多。

2.如何选择推送服务？

网上查资料，各种推送某光、某云、某鸽、某盟、某米等，还有推送自己建立推送平台。到底该如何选择推送服务呢？其实还是很简单，由你的用户决定了选择哪个推送平台。

(1).系统级服务与应用级服务

1).系统级服务

• IOS：APNs，IOS系统服务简单而有效，必定走向系统级服务APNs。所以IOS系统不需要选择。
• Android：FCM/GCM，此为google官方的系统级推送服务，Chrome浏览器同样适用。不过必须依托于google服务。
• 其他：如小米手机的小米推送服务、华为手机的华为推送服务。

2).应用级服务

简单来说就是第三方服务商提供应用来解决推送问题。需要注意的是，若选择小米推送在非小米的手机上也会属于应用级服务。

应用级和系统级服务有什么差别呢？一句话概括就是：应用级的服务会被杀死，而系统不会杀死自己品牌的推送服务。

所以尽量选择系统级服务，但是大多数情况下，用户的设备不会这么高度一致，而国内google服务行不通。在这种情况下就不得不使用应用级服务，也就是选择第三方平台进行推送。

(2).第三方平台的选择

当用户群体广泛，设备类型较多且无法使用系统级推送服务时，只能考虑选择第三方平台，此时选择第三方平台则有一个简单的原理：第三方推送系统会共享一条推送链路。

也就是说选择一个服务于多款APP的第三方平台，越多越好。因为你会和软件A、B、C、D、E、…共享一条推送链路，若推送服务被杀掉后，可以通过其中一款软件来重新唤起链接。这样能减少你的推送服务被杀死的可能性，最大程度保证消息到达。