如何体系化的优化消息推送

　　本文，按照时间顺序，来讲讲如何对消息推送进行优化。
　　对于消息推送优化，我们先有个明确的目标，是优化最终效果，但最终效果推送人群推送成功率触达率点击率用户与内容匹配度。
　　所以想要优化最终的推送效果，就得从以上每一步都进行优化，及优化公式右边的每一个元素，及增加推送人群、提升推送成功率、提升触达率、提升点击率、提升用户与内容匹配度，这样一拆解下来目标是不是明确多了？
　　那下面就将消息推送按时间顺序列需要的操作讲一讲，看哪些步骤可以提升上面的数字，按时间顺序可分为：
　　推送前：消息制作、选择推送人群、选择推送渠道；
　　推送中：消息推送；
　　推送后：消息收到、消息点击、数据反馈（根据数据反馈可进行优化）。
　　文章其实两条线，一条是将消息推送按公式拆分成触达率、点击率、转化率等，一条是将消息推送按时间维度拆分成每一步，然后可以在每一步来看，可以怎样优化第一条线的各种数据。
　　1、发送前消息制作
　　这个主要是运营的事情，我也不专业，只是提几个需要注意的点，推送的封面图怎么样？推送的标题质量是否能吸引？推送内容质量怎么样？标题、内容是否热点内容？标题、内容是否跟当下相关？标题、内容是否考虑手机尺寸来显示？是否定义好landingpage？
　　2、发送前选择推送人群
　　这一步要做到选择对应人群其实挺难的，需要在推送系统上创建各种标签，每次通过选择这些标签取交集、并集等来决定推送用户。也可以通过创建用户集，来避免每次都需要重新选中多个标签的交集或并集，例如选择等级大于3级男iOS系统最近三天有付费行为的用户，如果你常常会给这类用户发送消息，则可以将其创建一个用户集，每次推送时选择那个用户集即可。
　　再来说说这些标签应该如何来定义，网络上说的最多的当然是通过人口学角度来分，例如城市、年龄、性别等，但实际在做的过程中会发现，如果仅以人口学角度来分的话，会显得特别不合理，还需要增加很多和业务相关的分类，例如在直播中有打赏、在动态中有打赏、在私聊中有打赏。这些筛选条件一共可分为：
　　版本条件：可筛选具体的某个版本；
　　系统条件：可筛选Android、iOS；
　　用户条件：人口学的一些维度，如年龄、性别、城市等；
　　账户条件：总账户，或某个业务的账户余额，例如筛选钱包是否还有钱、背包是否还有礼物等；
　　付费行为：是否有付费，付费多少，在哪个渠道付费；
　　活跃行为：激活App，发动态等；
　　内容消费：进入直播间，动态进行互动等。
　　具体会怎么会根据你自己的产品来决定的，筛选条件一般由三部分构成：大筛选条件、子筛选条件、时间，例如付费行为可筛选有或无，可在子条件中筛选付费金额范围，以及付费金额渠道（例如直播间、动态、私聊），在时间维度可筛选1天、2天、3天以及自己输入天数。筛选条件的颗粒度是否要做的这么细，根据产品阶段以及具体产品来决定，没有一个通用的公式。
　　除了以上筛选标签推送，也需要支持输入ID进行推送
　　3、发送前选择推送渠道
　　推送渠道选择挺简单的，一般就那几个，短信、站内信、邮件、push
　　4、发送前选择推送时间
　　对于大一点的公司，发送推送消息可能需要审批好几层，而不是创建后就能立马推送出去。
　　还有就是对用户来说的时间限制，需要限定哪些时间段不能推送，哪些时间段可以推送，这需要根据自己产品的用户具体使用场景来决定，但一般是711点（想象一下凌晨两点收到一条推送通知把你吵醒了，你会说怎样的反应？）
　　对于发送时间的限制需要考虑哪些消息应该计算到限定时间中，哪些消息不应该计算在内，例如广告营销消息不能再237点之间推送给用户，但是验证码不会限制，你总不能超过23点就不让用户收到验证码吧
　　5、发送中消息推送
　　先来说下消息推送流程上是怎样到达用户手机上的，Android和iOS有些小差别
　　iOS消息推送流程：
　　运营手动推送：发起推送请求（自有服务器，或第三方）APNS（苹果服务器）iPhone（终端）弹出新消息（终端）打开App（移动应用）进入landingpage（移动应用）开始活动内流程（移动应用）
　　触发式推送：事件触发（自有服务器，或第三方）APNS（苹果服务器）iPhone（终端）弹出新消息（终端）打开App（移动应用）进入landingpage（移动应用）开始活动内流程（移动应用）
　　Android消息推送流程：
　　运营手动推送：发起推送请求（自有服务器，或第三方）Android（终端）弹出新消息（终端）打开App（移动应用）进入landingpage（移动应用）开始活动内流程（移动应用）
　　触发式推送：事件触发（自有服务器，或第三方）Android（终端）弹出新消息（终端）打开App（移动应用）进入landingpage（移动应用）开始活动内流程（移动应用）
　　对于iOS还好一点，都是苹果自家的产品，最多就是用户关闭了通知权限，导致无法收到；Android的幺蛾子可就多了，结束进程是收不到的，关闭通知权限也是收不到的，如果集成厂商推送（好处是结束进程也能推送到用户手机上），坏处是有可能如果只接入一家厂商，有可能其他Android手机品牌是接受不到的，例如接入OPPO，华为手机可能是收不到的
　　这里只是考虑了让Android用户在结束进程能收到消息，在消息推送过程中还有很多问题要考虑，但那些问题我也不太懂，只能列下来你可以去考虑下，例如：接入哪家第三方公司？接push的公司和im公司是否有冲突（我司接入的极光和云信是有冲突的，不能同接入）？支持多少并发量？用户接收到消息会有延迟几小时吗？各厂商的政策怎样？
　　6、发送后消息收到
　　主要是几个问题，先列出这几个问题，然后展开来讲一下
　　频率限制；
　　相互唤醒；
　　推送的影响；
　　App内引导打开通知权限。
　　（1）限制频率
　　举个极端点的例子，如果淘宝每天给你推送500条信息，你会怎样？可能就是直接卸载了，所以对用户的消息推送需要考虑频率，例如每天最多给用户推送两条，如果超过两条之后，自动推送不成功。但是需要考虑哪些消息应该计算到条数中，例如广告营销应该计算在内，验证码不应该计算在内，用户每天获取5条验证码可能都算是正常的。
　　一个注意的点，一些同学可能会想，别家的App都每天推送十几条，我只推送一两条，岂不是占用用户的时间就少了吗？消息推送可不能按照公地悲剧的思路来思考（可以去百度下公地悲剧），对于用户使用App来说，他是可以选择卸载或者关闭通知权限的，不想公地悲剧中没有选择。
　　（2）App之间相互唤醒
　　假设即刻App和他趣App都接入了同一家第三方push厂家，如果即刻没有结束进程，他趣结束了进程，在推送给他趣消息时，即刻会唤醒他趣，使他趣能收到消息。但是这种唤醒机制在AndroidN的时候，谷歌已经限制了不能这样做，所以这种方式可以不用考虑了，现在采用的更多是接入手机厂商，通过厂商推送比较靠谱。
　　（3）推送的影响
　　有好处也会有坏处。
　　好处：信息告知与提醒、促进活跃，增强粘性、唤醒沉默用户，提升留存、提高功能模块使用率
　　坏处：骚扰用户，提高卸载率、信任透支，狼来了的故事、过多无价值内容，造成用户反感甚至麻木
　　（4）存在的问题
　　这是一个iOS、Android都会存在的问题，如果用户手动关闭了通知权限，那是无论如何都是无法将push推送到用户手上的，所以在用户使用App是你需要尽量的引导用户开通权限。如果用户已经关闭了通知，则需要在某些地方判断是否已经关闭通知权限，如果已经关闭了则需要引导用户打开。
　　7、发送后消息点击
　　消息点击需要考虑的点：内容质量怎样？标题是否吸引？用户与内容匹配度？是否热点内容？通知中带有用户昵称等个性化内容？是否支持跳转对应页面？跳转是否流畅？落地页质量怎么样？
　　这里其实已经是结果了，这里的结果好坏会取决于发送前的几步，筛选用户时是否将对于信息发送给对于用户，消息制作时质量怎么样等
　　8、发送后数据反馈
　　发送后需要统计每一步的数据，在和行业内进行对比，以及和自己进行环比、同步看数据，需要统计的数据例如有应发人数、实发人数、发送成功用户数、触达成功用户数、点击用户数、跳转至落地页后的每一步转化人数，除了这些数据之外还需要关注下用户的卸载率（收到推送后1小时内卸载App的用户数收到推送的用户数）。
　　9、发送后推送记录
　　设计消息推送系统时，一部分是消息推送，还有另外一部分是推送之后的消息记录，这就是画画原型，很简单的事，只提一下需要注意的几个点就好
　　推送进度，例如创建成功（支持取消推送）、推送中、推送成功、已删除等状态
　　单条消息推送之后的数据，例如点击率、转化率、推送用户数等
　　10、文章没写的点
　　怎样监控卸载率；
　　怎样确定消息优先级，因为每天有限制消息推送的频率，那肯定是优先推送优先级高的消息；
　　怎样使每个用户都收到他能承受的最大条数（例如有的用户每天最多能接受2条，超过2条之后他就会卸载App，那就每天给他推送2条就好；有的用户每天最多能接受8条，超过8条之后他就会卸载App，那就每天给他推送8条）；
　　怎样做ABtest，例如抽10的用户出来，将写好的5条文案分别推送给2的用户（1052），较短的一段时间来看哪一条文案的点击率比较高，然后将这条文案推送给剩下的90用户；
　　区分手动推送和触发式推送，以上说的大多属于手动推送，还有一种分类属于触发式推送，也是满足各种条件（一个事件），就给用户推送一条消息，例如今天你生日、联系3天未登录App、充值成功、优惠券到期等场景；
　　如果移动端和PC端同时在线，推送逻辑是怎样的。