push消息推送是我们生活中最常见的功能和现象之一。每天我们都被各种各样的消息推送干扰着，那么作为产品设计师消息推送该如何设计？当我们作为运营时又该如何使用？我将从消息推送的介绍、优缺以及设计决策几个方面进行梳理文章。

PMTalk产品经理社区

一、push消息推送的组成

push又称消息推送、消息触达。叫法有很多但目的只有一个，就是通过各种渠道或方式将指定内容告知到指定用户。所以我们也可以称之为通知、提示等等（我个人认知哈，名词而已关注核心需求就行）

综上所述，消息推送的核心目的在于将指定内容告知指定用户，那么我们将消息推送看作一个对象，这个对象由内容、渠道和终端组成。

1）内容（什么是内容）

内容部分，主要是推送实际内容的设置。常见又​标题、内容、链接或deeplink等内容组成。这个内容可以是人为进行创建，也可以是系统依据事先设计好的策略，再根据实际​触发​时间，将指定内容进行收集生成。

由标题、内容描述、图标icon、链接和提示音组成。

2）渠道（什么是渠道）

渠道上主要分管内容触达用户的形式。在以前我们常见的触达形式是线下​在先​去门口架一张桌子，面对面地推。通过直接与用户面对面来确保信息能够真实有效的触达用户。

互联网时代，我们能够触达用户的方式越发的多样性，我们需要了解现在主流触达渠道，以便明确我们能够做到什么地步。这类触达一般以微信、短信、电话和邮件作触达方式。

主流触达：短信、通讯

次流触达：各自APP（微信、QQ、支付宝等）、邮件

3）目标终端（什么是终端）

最后，是消息触达用户前的最后一步，终端。触达终端有以安卓和iOS为首移动终端，常见的是手机，其中也包含了watch、iPad和手环等电子产品。而固定终端因为需要区分Win、liunx和Mac等系统，我们直接称呼PC端方便理解。

最后，其实所有实体的电子设备我们可以统称为终端。

二、触达方式的差异

大部分文章触达差异喜欢从触达时间、主题选材、文案优化和推送频次上进行讲解。告诉你在什么时间推送效果好。不同的时间段适用那种主题内容，以及我们应该推送那种话术和频次这样可以提高打开率等。

首先，这确实是需要我们了解掌握的，但是毕竟我们不是运营，我们需要了解消息推送的本质，掌握不同渠道的优缺以便辅助我们完成相关能力的设计。这才是我们前期需要了解掌握的。如果连这些都不知道，那如何思考出最优的解决方案了？

因此我会依据我的理解直接讲述不同触达方式的差异和优缺。

1. 短信、通讯触达

通讯触达：短信、通话

优点：触达及时、曝光率高

缺点：成本费用高，打扰性强

服务提供商：阿里云、腾讯云等。

计费标准：按量收费 0.030元-1元/条（短信、语音验证码等）。

终端渠道我们接触最多的就是手机，其次是各种智能设备。现在手机几乎也是现在我们人人都有的东西，同时生活也离不开手机，所以手机作为我们首选触达方式；另外多数情况下，还有出现一种情况，用户手机上未安装应用或应用未运行，这就造成我们无法通过应用触达用户，所以我们采用短信和通话作为首选触达。

在采用短信和通话作为触达方式​是​，要想使用能力，我们需要通过第三方平台接入该能力。接入之前，我们需要注意以下事项：

兼容率；

送达率；

费用；

短信​模版​；

首先，是兼容性。我们需要了解当前使用的技术框架是否兼容该服务商提供的能力，尽量避免出现阿里服务器使用腾讯服务商的能力。并不是说不能实现，而是我们需要考虑研发调试成本。这样能有效的节约一部分调试时间。

其次，是送达率。短信服务商和短信服务商之间，使用的短信和通讯渠道是不一样的，这会造成服务器耗时和性能不同，可能会造成延时响应或直接响应失败，印象最终的送达率。

直接表现就是推送100条短信，只有70天送达成功。发送一条短信，响应时间需要500ms以上的时间。所以，出名的服务商并不代表他们的送达率一定有保障。我们一定要货比三家。

对此，我们可以在阿里云和腾讯云他们的市场里挑选服务商，或者使用互联网上较出名的服务商给较多的钱筛除低质量的服务商。但在使用前我们都可以要求对方提供测试名额，我们通过协调研发进行联测，简单测试他们各个环节耗时和​粗旷​的送达率。在都没问题后，我们就再进行费用的洽谈。

至于，为什么我说是“​粗旷​的送达率”，因为真实的送达率有多少，只有其他人告诉你才行，前面1-200天测试其实并不容易测试出来。这也是我建议大家不要太相信服务商自导自演说的99.5%的送达率，因为这个作假太多了。（费用和送达率，我们要更加看重送达率，就算价格贵几分钱和可以）

随后，便是费用问题。因为就算是几分钱的短信验证码登录，在需求量大的时候每天光靠验证码费用也是一笔大钱。所以我们需要针对所需业务规模来预估费用。预估的时候我们可以先从全量去计算。

比如，我们产品日活跃在10万人左右，我们只在验证码一处使用了短信验证。同时，对短信验证也做了限制，每个用户一天的周期内最多发送4次验证码请求，超出需要等待第二天。

那我们全量计算一天短信使用量在40万（真实使用量一定没有这么多，但是我们作为预估时，可以用这个数据进行首次采购，后续根据实际使用量进行二次采购）。按在每天短信0.045计算，一天的费用就是1.8万。这样我们可以与供应商进行谈，将费用从0.045压到0.035，这样我们将节约4000元左右。

最后，短信模版是我们最后需要注意的地方。短信发送给用户前，我们需要先设置短信模型的内容。因此，我们理解短信​模版​的一些名词，以便我们进行约束设置。

短信示例：【${title}】 验证码${number}，${content}

短信示例：【阿里云】 验证码123456，您正进行支付宝的身份验证，打死不告诉别人！

另外，了解短信​模版​可以避免，没有合适的短信​模版​又急需上线使用的情况下，创建​模版​等待审核使用的情况。

短信签名和短信模板提交审核后，会显示具体的状态。

短信签名状态包括：审核中、审核未通过、审核通过。

审核中：当前已提交了短信签名，正在排队等待审核。1-2个工作日会审核完毕。

审核未通过：由于某些原因，签名审核未能通过。可以通过控制台“签名管理”来查看具体审核未通过的原因。

审核通过：已通过了审核，短信签名和短信模板都通过审核时，就可以通过接口调取开始发送短信。

短信模板状态包括：审核中、审核未通过、审核通过。

交审核：进入审核状态。

审核中：当前已提交了短信模板，正在排队等待审核。1-2个工作日会审核完毕。

审核未通过：由于某些原因，签名审核未能通过。可以通过控制台“签名管理”来查看具体审核未通过的原因。

审核通过：已通过了审核，短信签名和短信模板都通过审核时，就可以通过接口调取开始发送短信。

2. 系统触达

除了使用通讯方式作为我们的触达方式外，系统触达是我们第二选择的触达方式。

系统触达是指通过IOS（苹果系统）和Android（安卓系统）自身的消息服务触达用户。触达方式一般为通知栏提示。

1）ios

iOS的触达可以分为本地推送、远程推送和静默推送三种方式。

本地推送：

本地通知在iOS的使用场景主要适用于一些无网络情况下的提示，例如闹钟、任务提醒等。

另外iOS系统许多人喜欢设置禁止后台刷新，这也就造成app很难利用本地通知来触达用户。缘由就​是​app软件在后台被禁止刷新​是​，基本属于挂掉状态，无法利用后台程序去触发推送，也就造成无法触达用户，因此就有了第二种推送方式，远程推送。

推送名称：本地推送

推送方式：手机通知栏推送

推送类型：立即推送、延迟推送

前置条件：用户授权、后台运行

组成参数：

启动时间

启动时间参考的时区

重复推送时间

通知内容 alertAction

解锁滑动时的事件 alertLaunchImage

启动图片，设置此字段点击通知时会显示该图片

通知标题，适用iOS8.2之后

收到通知时App icon的角标

推送​是​带的声音提醒

发送通知时附加的内容等

优点：不需要网络。

缺点：后台运行耗电且容易被杀死。

远程推送：

苹果公司的远程推送服务是整个苹果推送服务的核心。这个远程推送服务，不光是服务iPhone手机，同时还服务Mac（电脑）、WatchOS（手表）、iPad（平板）等，所有苹果公司下的硬件设备。

苹果的远程推送服务（APNs）会与所有苹果下的硬件创建一个长连接。代表每过一小段时间推送服务（APNs）与苹果终端之间就会进行一次短暂的联系。每次联系的时候，终端设备都会询问推送服务（APNs）服务器上有没有自己需要推送的消息。

如果有，无论这条消息所属的软件app是否正常运行，苹果终端都会先接受推送任务，并给在终端的通知栏进行信息推送。如果没有就不做处理就行。

我们也可以按照角色进行里理解，他们可直接分为软件服务器、苹果推送服务（APNs）、终端设备（iPhone、Mac）和应用软件四个角色

软件服务器：是指我们自己的后端服务器。在整个消息推送环节中，由我们的服务器作为消息推送的请求开始。随着，我们的服务器去与苹果推送服务进行连接，我们按照苹果官方的文档规范，将推送内容进行填写，并通过指定接口或协议将内容上传至苹果推送服务。

苹果推送服务（APNs）：Apple官方统一的推送通知服务。他管理所有Apple旗下所有设备的推送通知服务。

终端设备（iPhone、Mac）：Apple自家系列的产品。

应用软件：基于apple开发的软件或应用。

静默通知：

静默推送不仅在定义上和其他的推送方式不同，在推送内容上也和其他推送不同。他主要是通过服务器向终端发送一条代码指令，让终端短暂运行该代码指令，就没了。

但是他却能够解决很多问题，比如当后台服务器检测到有人联系某个用户时，这个用户恰巧将应用后台运行了，我们无法通过软件告知用户，这时候我们可以采用远程推送来提醒用户。

这么做有个问题：会增加后台服务器的工作量，且浪费用户的流量；可以假设以下你是微信，你有4亿多活跃用户，当1亿用户同时进行聊天的时候，后台不仅需要发送消息，还要发送消息的推送，这相当于后台同时需要处理双倍工作量。当大量进行数据收发读写的时候，就会容易当机。

因此，可以先给用户发送一个静默推送，将用户的app唤醒，这个时候应用有20秒的时候可以用来处理消息；让应用在收到消息后，再去发送一个本地的推送，提醒用户有其他用户给他发了消息，这样就能减少后台的任务量。