一、推送的重要性
推送是消息触达与用户召回的重要通道，推送通道能力的触达率、推送消息的点击率绝决定了推送的覆盖度，我们用一个公式来衡量推送效果： 推送效果=推送目标数推送触达率推送点击率用户转化率 1 推送目标数： 即将要推送的人数。那是不是推送目标量越多越好呢？——否！如果推送到非目标人群，会打扰到正常用户，甚至可能卸载APP或投诉模板消息，后果就比较惨了。所以建议还是选择合适的目标群，在优化部分会给出简单的小建议~ 2 推送触达率： 推送触达率主要是衡量消息通道的健壮能力的指标，一般来说，APP推送可尝试使用效果较好的三方渠道；微信内推送应建立适当的推送时间避免Formid过期。据了解，APP的推送触达率在75%左右， 微信 的触达率在90%左右。 3 推送点击率： 这个和推送人群、推送时间、推送素材紧密相关，后面做详细说明。 4 用户转化率： 这就是运营的能力，根据业务自行判断，不做赘述。
二、微信体系的消息推送
1 微信推送消息的介绍（详见微信官方文档）
基于微信的通知渠道，公众号/小程序提供了高效出大用户的模板消息能力，以便实现服务的闭环并提供更佳的体验。
模板推送位置：服务通知
模板下发条件：用户本人在微信体系内与页面有交互行为后触发
模板跳转能力：详情仅能跳转下发模板的该帐号的各个页面
模板推送流程：
有心的小伙伴可以看到，相较于APP推送，微信推送需要选择合适的模板ID。为了方便推送内容的规整与管理，微信体系下的推送（微信公众号推送、模板消息推送）必须要选择相关的模板标题，在模板下更替内容即可，具体模板内容可参考模板消息管理。
2 模板消息的规则与限制
介于模板消息建立在微信生态内，当然为了用户体验及生态健康，微信也是设置了较多的规则与限制： 21 下发规则 211 推送位置：服务通知。
212 推送下发能力：用户本人在微信体系内与页面有交互行为后触发，当然也是有时间的限制。微信公众号的服务通知限定在交互72小时内可以主动下发消息，小程序模板消息限定在交互7天内可以下发模板消息（小程序下发模板消息需要收集Formid，Formid的有效期是7天）。 22 限制与惩罚 221 贴一下官方给出的违规说明（请认真对待，不要以为是吓唬你或是开玩笑。身为腾讯干儿子的我们真的被严格的封过！是！真！的！）：
222 一般官方给出的惩罚原因比较模糊，我结合具体被封过的例子简单解释一下以及我踩坑过来的一些小tips：
1）
官方解释：不允许恶意诱导用户进行触发操作，以达到可向用户下发模板目的
话外解读：不能以利益刺激引导用户点击、不能引导用户做和订单/消息无关的行为反面案例，比如点击领钱、砍价等等
Tips：
利益点表述的委婉些：比如“点击可领1元”可改为“你有一份惊喜待查看”。
常规行为让用户选择是否需要提醒：比如签到提醒给用户设置开关，让用户选择是否需要提醒。
2）
官方解释：不允许恶意骚扰，下发对用户造成骚扰的模板
话外解读：把消息下发给了无关的人群、你的模板消息被用户举报了，比如给女性用户下发了无人机/游戏手柄等相关的内容。
Tips：认真做好用户分层，并且控制好推送频率。
3）
官方解释：不允许恶意营销，下发营销目的模板
话外解读：你把模板消息当做营销工具使用了，并且被用户举报了，比如有事儿没事儿搞个促销轰炸一通。
Tips：不要用模板消息推营销活动，早点囤些流量到公众号里推吧。
除了这些，没事儿常拜一拜小龙爸爸，祈祷不要被封。
3 推送后台的设计
在公司里我们作为基础部门，承接着各个业务方提过来的推送需求，以我们为例，推送后台应承载的功能主要有以下几块：
31 推送能力支持主要涉及到模板维护、推送申请与流量分发、A/B测能力支持、数据查询等基础功能。 32 防打扰策略 根据产品不同防打扰策略的设计会有差异，以电商平台为例，可以分为以下三类推送：
基础类：与核心业务直接相关的消息提醒，没有就会对业务产生影响或用户体验大打折扣，比如：订单消息提醒、买卖双方消息提醒等；
提醒类：不会影响正常的产品流程，有可能提升产品活跃或促进复购的消息提醒，比如：订单过程中的漏斗节点提醒、签到提醒、基于业务场景的提醒（降价通知、到货通知等）；
营销活动类：主要是运营使用，为用户创造需求的一类提醒，比如：大促活动提醒。
基于以上三种类型，对于用户的防打扰可以设计为底层防打扰、业务防打扰两个层面。底层防打扰用户保证消息通道“不轰炸”且有“存在感”，业务防打扰保证“推对人”“不泛滥”。
防打扰条件可以从防打扰时间、防打扰频次、防打扰场景等多个维度拆分，根据业务不同自行设计，不详细展开。 33 资源竞争&智能匹配 简单来说，这个课题要解决的问题是：A、B、C多个业务方都想给小明们推送，那么A、B、C三个业务推送的用户群的重合度有多少？到底应该由哪个业务方推给小明们呢？
我的解法主要是用户分层体系（主要是RFM模型）的应用，写起来也是比较多，感兴趣的话记得点赞留言，我得空了单独整理一篇。
三、消息推送的优化
这里讲的消息主要针对于 微信 模板消息推送，底层逻辑和APP推送是一致的，只是一些表现或者样式有些微调，我简单整理了一张表格对比一下，各位看官自行分辨取精去粕。
按照消息推送的过程，可以分为推送前的准备、推送中的监控、推送后的复盘三个过程，按照三个过程分别提供一些优化建议。
1 推送前准备
1）选择推送人群
这点非常考察产品运营同学的数据敏感度，以及公司底层的数据系统的搭建。中大型的公司会有严密的用户分层及用户行为监控，方便运营。比如推送双十一营销消息会根据用户去年参与情况、消费金额、近一年/近半年消费频次、最近一次消费的时间等因素划分不同的用户群，每个用户群组织不同的素材（可参RFM模型及用户运营策略）。
但是，数据不完整的小公司怎么推送呢？
简单来说，可以通过用户系统版本、用户性别、用户年龄、活跃行为、消费行为等做简单的推送即可。
2）选择推送时间 一般情况下，常规推送最好能够固定时间或行为后立即触发，营销类推送可选择通勤时间段、饭点儿或休息时间进行推送，以下几个时间段仅供参考：7:30~9:30、12:00~14:00、18:00~22:00。
3）设定推送文案 推送文案直接影响着点击率，这也是运营同学长久积累的功底，我就不班门弄斧了。说几个我写过的点击率还比较高的方向吧：热点事件、红包奖励、朋友介绍等等，欢迎补充。
4）制作landingpage
千万不要忽视落地页，不可一概而论，即使做不到千人千面，也要根据用户分群做一些区分。比如，对价格敏感的用户就一定要放优惠券；女生用户就要尽量打“占便宜”“少女感”这些点。
2 推送中监控
推送的过程中要实时监控两个点：推出的数据是否正常、 微信 后台是否有投诉消息，一旦发现有情况，立刻马上停掉后面的推送！
3 推送后的复盘
1）数据复盘 我会按照漏斗去看目标推送量、推送成功量、点击量、转化量、转化用户的留存这些数据。 2）防止被举报的小技巧 在与小伙伴交流时发现被封真的是一个很正常的现象，还是有一些“小技巧”是可以尝试的：可以在推送内容增加一条“回复DT不再推送”或者在文末增加“伪投诉”入口。
java程序与微信公众平台之间实现消息推送方法:
1、本地数据库中存放着小程序用户表和微信公众号的表，下面就是向某一个小程序用户推送微信公众号信息
2、在小程序用户表中任意取一个用户A信息，用户A的openId和unionId，通过unionId到公众号表里去检索对应的A用户微信公众号的openId
3、在微信公众号上选择一个模板消息，编辑完要发送的的内容后，再请求发送模板消息的接口
关于微信公众号不能推送的，或者推送报错的，推送的miniprogram下的appid对应的小程序必须是已审核并发布的才可以推送。
推送软件用极光推送，实现多种消息类型，开发者可以轻松地通过极光发送各个移动平台的系统通知，还可以在控制台编辑多种富文本展示模板； 极光还提供自定义消息的透传，客户端接到消息内容后根据自己的逻辑自由处理。
GCM应该是Google Cloud Messaging吧。。。
下面附一段摘抄：
作者：feng xixi
链接：https://wwwzhihucom/question/21514839/answer/18496706
来源：知乎
GCM Architectural Overview Google Cloud Messaging for Android (GCM)是一个能够帮助开发者从服务器端发送数据到运行在Android手机上的程序的服务。这个服务提供了一个简单，轻量级的机制使得服务器端可以告诉移动端的程序与服务器端建立直接的联系，来获取更新的程序或者用户的数据。C2DM服务可以处理所有的消息队列的问题并且可以把消息发送到目标机器上运行的目标程序。
GCM的主要特点：
1、它允许第三方的程序服务端发送消息到他们的安卓设备。
2、GCM不能保证消息的发送和消息的顺序。
3、手机端的程序不需要一直运行来接收消息。系统会通过Intent broadcast来唤醒程序当有新的消息到来时。当然程序需要设置适当的broadcast receiver和permission。
4、它不提供任何的用户界面或者其他的东西来处理消息。C2DM只是简单的把收到的原始消息传递给程序。这个程序提供了处理这个消息的方法。比如，这个程序可能抛出一个通知，显示一个自定义的界面或者只是同步数据
5、GCM要求手机必须运行Android22或者更高版本并且要有Google Play Store ，或者运行具有谷歌api 的Android 22虚拟机。但是，你不仅限于通过Google Play Store部署你的程序。
6、它使用一个现有的连接用于谷歌服务。对前置30设备,这要求用户在他们的移动设备设置他们的谷歌账户。Android 404或更高对于谷歌帐户是不要求的。
有的应用在国内市场和Play提交的安装包不完全相同，必须从Play安装才能实现GCM推送。
谷歌系大部分软件
大部分国外IM软件
微信
Pushbullet
CloudMagic（已改用Inbox，吐槽下第三方邮件客户端都支持GCM，居然自家不！支！持！！）
印象笔记
UBER
VSCO Cam
亚马逊
许多游戏
不过有的App从来没见他推过消息的说……
国内大部分不支持GCM其实也是好事…把BAT绿色化之后通知栏瞬间清净了
AesGCM是微信底层通信协议中使用的一种最为重要的加解密算法，在尝试使用OpenSSL库实现这套算法的过程中，遇到了以下几个值得注意的点：
在ECB/CCB模式下，补位信息是算法实现必须考虑的一个维度。但在GCM模式下，补位信息是完全不需要考虑的，明文与密文有着相同的长度。
在普通的Aes加解密算法中，需要从key/iv/padding/mode这四个维度来考虑算法的实现。而AesGcm算法中却需要从下面这几个维度来实现算法：
微信底层通信协议中，服务端下发的密文数据总是比明文数据长了16个字节，导致这种现象的主要原因是微信实现时将加密使用的tag信息拼接到了密文数据中，客户端使用JAVA接口解密时，在接口的内部能够自动的截取tag信息后再解密出明文数据。我并不能确认这种方式是BouncyCastle的固有实现还是微信自己的独有实现。关于拼接这块的逻辑，可以参见 这里 。
当使用OpenSSL实现解密微信下发的密文数据时，如果不知道拼接tag这层逻辑时，是不可能成功解密出明文数据的。
在以后安卓也是会依靠统一推送来给用户带来很棒的体验。
在统一的推动下，Android也不远了。在2010年，当苹果推送通知服务发布后不久，Android 22“云到设备消息”发布，其原理与苹果推送通知服务类似，从应用服务器发送的消息被发送到服务器，然后发送到设备。
该服务于2012年被谷歌云消息取代。GCM的最重要的优点是没有消息限制，可以节省更多的电力。
2014年谷歌收购Firebase后，将GCM更名为“Firebase cloud messaging”，进一步简化了推送服务的相关开发工作。
在国内，由于在大陆使用谷歌服务是不稳定的，法律渠道Android手机倾向于精简谷歌服务以获得更好的用户体验，统一的推送服务也被删除。因此，出现了各种第三方推送服务。
最尽职尽责的应该是他们自己的推送服务，比如华为和小米的这些推送服务被集成到高度定制的Android系统中，具有系统级的状态和更高的优先级。如果你的小米手机中的所有应用都使用MiPush，它就会像iOS一样流畅。
但这往往是不可能的，开发商不能照顾所有的供应商，并确保每个品牌都有相应的推送服务，而华为和小米已经做到了最好。虽然厂商的推送服务也可以在其他品牌的手机上正常使用，但不喜欢在他们的系统上实现系统级，推送通知服务后台进程仍然是永久的。
实现推送的处理步骤：
创建机器人：
1、登录企业 - 拉取创建3人及其以上的群组 - 点击右键群设置 - 添加机器人，如图：
新建机器人：
给机器人取名：
创建完成：
获取机器人webhook： 复制webhook
https://qyapiweixinqqcom/cgi-bin/webhook/sendkey=XXXXXXXXXXX
安装Python第三方库：requests。
pip install requests
按照对应的机器人文档说明，将包装后推送内容进行接口请求：
运行后即可得出类似下面的结果：
