发表于： 2019-06-25 22:27:10
1 537
今天完成的事情：
继续学习消息推送，昨天关于消息推送的方式了解了应用内通知和push，还有两种应用外的推送方式是短信和邮箱。
短信推送：
短信推送凭借着优秀的到达率，一度成为最受欢迎的营销工具之一。短信推送是通过正规短信供应商发送，发送率和抵达率高，短信内容需要提前报备，根据发送量不同价格不一样，越多越便宜。短信推送也是容易造成用户反感的方式，采用此方式推送消息，避免过于生硬地提示，直接把想要用户知道的内容用书面语言进行提示是会让用户感到不爽的，要保护好用户的情绪。
邮件推送
EDM邮件:EDM 是 Email Direct Marketing 的缩写，即电子邮件营销。企业可以通过EDM建立同目标顾客的沟通渠道，向其直接传达相关信息，用来促进销售。可以发送电子广告、产品信息、销售信息、市场调查、市场推广活动信息等。
EDM的优点是可以精准筛选发送对象，根据社群的差异指定个性化内容，并投递到特定的目标社群，同时EDM的信息丰富，文本、图片、动画、音频、视频、超链接都可在EDM中体现；缺点是使用EDM的用户量并不像app那么多；
推送平台的构建
推送的三种实现方式
1.轮询方式（PULL）
客户端和服务器定期的建立连接，通过消息队列等方式来查询是否有新的消息，需要控制连接和查询的频率，频率不能过慢或过快，过慢会导致部分消息更新不及时，过快会消耗更多的资源（流量、电量等），对用户体验有较大伤害。
2.短信推送方式（SMS PUSH）
通过短信发送推送消息，并在客户端植入短信拦截模块（主要针对 Android 平台），可以实现对短信进行拦截并提取其中的内容转发给 App 应用处理，这个方案借助于运营商的短消息，能够保证最好的实时性和到达率，但此方案对于成本要求较高，开发者需要为每一条 SMS 支付费用。
3.长连接方式（PUSH）
移动 Push 推送基于 TCP 长连接实现， 客户端主动和服务器建立 TCP 长连接之后, 客户端定期向服务器发送心跳包用于保持连接, 有消息的时候, 服务器直接通过这个已经建立好的 TCP 连接通知客户端。尽管长连接也会造成一定的开销，对于轮询和 SMS 方案的硬伤来说，目前已经是最优的方式，而且通过良好的设计，可以将损耗降至最低。不过，随着客户端数量和消息并发量的上升，对于消息服务器的性能和稳定性要求提出了非常大的考验。因此，就难度而言，此方式代价最高。
推送解决方案
基于 TCP 长连接的方式是主流的推送方式，基于该推送方式逐步发展出系统级、应用级一系列的推送解决方案。
系统级服务可分为三类：
IOS：APNs，IOS系统服务简单而有效，必定走向系统级服务APNs。所以IOS系统不需要选择。
Android：FCM/GCM，此为google官方的系统级推送服务，Chrome浏览器同样适用。不过必须依托google服务。
其他：如小米手机的小米推送服务、华为手机的华为推送服务。
应用级服务分为两类：
第三方推送服务
简单来说就是第三方服务商提供应用来解决推送问题，应用级和系统级服务有什么差别呢？一句话概括就是：应用级的服务会被杀死，而系统不会杀死自己品牌的推送服务。
所以尽量选择系统级服务，当用户群体广泛，设备类型较多且无法使用系统级推送服务时，只能考虑选择第三方平台，此时选择第三方平台则有一个简单的原理：第三方推送系统会共享一条推送链路。
也就是说选择一个服务于多款APP的第三方平台，越多越好。因为你会和软件A、B、C、D、E、…共享一条推送链路，若推送服务被杀掉后，可以通过其中一款软件来重新唤起链接。这样能减少你的推送服务被杀死的可能性，最大程度保证消息到达。
目前市面上常见的第三方推送：极光、信鸽、友盟、阿里云等等；
自建推送服务
第三方服务在开发成本和消息到达率上表现都不错，但所有信息会经过第三方服务器，对于信息敏感类 APP 而言，有必要考虑自建一套消息推送服务，能最大化保证安全，但对于自建推送服务，除了成本高，如果从零开始来做需要解决几个难点： 第一，移动推送服务器对 App 客户端海量长连接的维护管理。第二，App 客户端如何保证 Push Service 常驻，对于 Android 我们可以通过发现 push service 不存在可以定时拉起的方式。第三，通信协议的制定，我们可以采用开源的 XMPP 方式实现，也可以自定义协议，不管哪种方式我们都要保证消息传送的到达率的准确性。第四，在移动互联网网络环境下，经常出现弱网环境，特别是 2G、3G 等网络不稳定的情况下，如果保证消息在弱网环境下不重、不丢也是一个挑战。
推送任务的建立，推送消息是如何到达用户的设备上
首先了解一下用户、设备、Token的概念
用户：就是你的目标用户，也就是你的站台使用者的人数，他们就是活生生的人。
设备：一个人有多个设备，就像一个人可能有多个电话。因此用户与设备的关系是一对多的关系。
Token：用户的客户端在推送服务上注册的令牌，简单理解就是用来标识这个客户端的。对推送平台来说，就是根据Token来知道你要把消息发给哪个用户的客户端。类似于我知道你的电话号码，我就可以打电话给你。
但是需要注意，电话号码可能会被遗弃、更换，而且不同电信服务提供商的电话号码都是不同的，Token同样存在这种特性。 而采用设备号形式可能会由于一个用户拥有多台设备导致统计的数据不精准。
注册体现了极光、信鸽、友盟，极光和信鸽只能发应用外通知栏push，友盟除了push还可以发送应用内消息和自定义消息；
应用内的消息推送支持各种样式、目标人群、有效期、展示条件；后续行为可以添加页面或者跳转URL地址
通知栏push可以定制 样式和图标，推送时间分为立即推送、定时推送、重复推送；
立即推送是把编辑好的内容即时推送给用户，它的优势是可以快速将消息推送给用户，但是推送时需要手动触发，而且需要选好时机，不然会打扰到用户。这种一般用于定制消息的推送。在友盟推送，它的立即推送说的是在某个时间之前的设备可以接收推送消息，应该就是指的点击立即推送后，就开始进行推送，在设置的时段之后，设备就无法再收到推送消息。在腾讯信鸽推送，它的立即推送就不是选择日期时间，而是以小时计算，默认保存 24 小时, 该时段内联网的用户均可收到推送。
定时推送是把内容编辑好，然后到了时间自动发送，它的优势就是可以不用人为触发，到了定时时间自动进行推送，缺点是要管理好推送设定，不想推送的内容要取消彻底，不然可能误推送。这种形式一般用于需要定时通知用户时，比如各大软件的生日提醒。
重复推送可以将编辑好的内容在一段时间内重复推送，它的优势是可以在一定时间内周期性的进行推送，缺点是重复推送可能会对用户造成打扰。常用于活动倒计时推送和一些重要事项的推送。
消息列表页区分了进行中任务和历史任务，同时增加上下架的操作，可以增加消息任务的复用。
从推送任务建立之后，推送消息是如何到达用户的设备上，并且会展示成什么样式，那么归纳起来有以下四点：
1、推送消息首先会由服务端根据token发送给推送服务；
2、推送服务通过长连接把通知消息下发给设备；
3、设备把推送消息路由且显示出来；
4、推送消息的展示会根据设备和系统有所差异，需要有针对性的设计。
消息推送需要注意的点
1、明确推送目的，选择合适的内容
盲目地推送会遭到用户的反感。推送前，要明确推送目的，是要引导用户进行某项操作还是仅做信息公示？基于此目的，判断推送是否是最好的手段？是否可以通过邮件、短信等替代？只有推送用户感兴趣的内容，才有可能激发用户与你的互动。
2、选择触发时机
考虑用什么触点撬动用户，想在什么时候唤起用户，当触发点和时间更合理时，推送的效果才有可能更好。
3、结合业务考虑用户体验
除其他推送条件外，也结合业务的情况，考虑用户的其他体验
4、个性化推送
APP的众多使用用户除共性外，依然有很多个性的喜好，根据外部自然情况与用户的实际使用情况给用户推送内容，会让用户更喜欢
消息推送后要关注哪些数据
发送成功率：建立推送任务成功数/计划发送用户总数
下发成功率：推送服务实际下发数/推送服务计划发送量
推送到达率：推送实际达到设备数/推送服务下发量
推送点击率：用户点击推送数/推送实际到达设备数
明天计划的事情：
1、整体PPT，给出回家学习的设计方案，梳理框架结构，开始设计；
遇到的问题：
1、在调研第三方推送平台的时候，消息中心的推送，那么这一类的推送是通过什么方式推送的呢？
收获：
1、要下发消息到设备，需要先与用户设备建立长连接，只有成功建立长连接的设备可以进行下一步。无法建立长连接的设备可能由于Token变更、推送服务无法唤起等其他异常情况导致无法与客户端建立长连接。无法建立长连接的设备将无法进行推送，此时可以把该部分用户从推送队列中筛出来，并进行标记。防止推送队列在执行过程中，因为部分设备无法建立连接的原因，导致推送任务的中止。对下发不成功的用户可以加入重发机制，尝试将消息再次推送。当设备多次无法建立长连接时，该设备处于暂时失效状态，即可进入黑名单，以免浪费推送资源。
目前用户设备端都有对消息推送的控制权限，尤其是通知栏的推送，对安卓设备来说，在消息较多时就会被收纳起来，对于一些深度定制优化系统，比如MIUI、Flyme等自带的安全中心就可以轻易的将通知栏消息屏蔽或收纳，在这种情况下通知栏的推送就意义不大，因此推送时消息不宜推送过多，一旦被用户禁用相关权限，打入小黑屋，那就没法进行通知栏推送了，但是应用内推送不会受影响。应用被禁用通知权限时通常会告知用户影响正常服务而建议用户开启权限。
消息推送过程中，有很多因素会影响消息的到达率，往往推送1万个用户，可能最终收到的用户只有几百个了，总结起来大致是：应用被卸载或权限被禁用；Token失效，无法与设备建立长链接；网络问题，导致消息未正常送达；设备问题，进程卡死或者被强行停止。网络问题无法预见，由于推送进程被杀死或者用户Token失效造成消息丢失的情况才是我们需要重点考虑的地方。
返回列表
评论