上一篇从推送运营策略的角度介绍了如何提高推送的效果，而众所周知数据是最能反应问题和展示效果的。本篇将会从数据的角度，结合推送的整个流程。带领大家逐个环节排查问题，从而让推送效果更上一个台阶。
推送就像一个生产线，每个加工的环节均会有损耗。为了让最后生产出来的产品尽可能的减少损耗，我们需要对整个生产线的每个环节进行剖析，试图从中找到可以提高生成效率和质量的方式方法。所以下面我们从推送的整个流程开始看起。
推送的总用户池即为目标用户所在的池子，池子中有多少用户也就意味着最大可以触达多少用户，所以对推送用户池的数据监控非常必要。
理想情况下推送用户池的用户数=APP（网站）累计用户数，也就说从APP研发上架到现在所有累计安装的用户。但是大家都很清楚，累计用户的意义不大，因为累计用户中有很多用户早已卸载离开。所以可推送的用户池应该是仍安装APP的用户，包括沉默用户。
那么理想中“推送用户池总数=APP仍安装用户总数”，大家也很清楚的是“APP仍安装用户总数”很难获得，因为我们无法精准的掌控用户是否卸载，用户卸载并不会和我们“打招呼”。所以平时我们观察APP的数据多以活跃用户来观察。
假设我们的推送用户池=月活跃用户，这样也视乎把目标人群范围缩小了，因为也许用户沉默超过1个月。所以我们仍然以累计安装用户来作为推送用户池总数，以保证能包含尽可能多的用户，虽然其中包含了大量无效用户，我们后面可以做过滤操作。所以理论上：推送用户池>（月）活跃用户。
本系列开篇我就已经阐述，请使用设备号作为用户的唯一标识。非常非常多的APP或者推送平台以token作为用户的唯一标识，这样造成的后果就是用户池的冗余。
假设你的APP使用token来标识用户，你的用户小明重复卸载安装4次，此时产生了4个token。你会以为有4个用户，但其实只有小明1个用户。
因为他们获取不到用户设备号，毕竟设备号获取是需要权限的（Android）。
有效用户比例
上面讲到的是推送用户池的总用户，而有效用户比例才是我们要关注的重点。推送池中的有效用户指的是“同意推送权限”的用户比例。假设用户池有1万个用户，其中6,000个用户同意推送权限，则有效用户比例为60%。有效用户数更贴近于可推送的目标用户数。
当发现有效用户（同意推送权限）的比例急速下跌时，请敲醒警钟，你的用户正大量的关闭推送权限！请保持定期观察该数据。（如何知道用户是否同意推送权限，请见：推送系统从0到1（五）：推送消息如何丢失的）
但是请注意，推送用户池的有效用户并不能代表真实的可推送用户数。因为还是无法鉴别出其中“已经卸载的用户”，我们只能通过后续的手段判断用户疑似已经卸载，从而把该用户从有效用户中剔除。
假设想知道有效用户的比例多少是健康的，我在网上找了许多资料均无法获得该数据，我只能以自己的项目为例，最初有效用户比例85%~90%。当然随着推送频率越来越高，以及后期缺乏维护和引导，有效用户比例已经下降至60%左右，该数据仅供参考。
黑名单机制
在系列文章中，我多次提到黑名单机制。其存在的目的在于把有效用户中并非真实有效的用户剔除出来。刚才已经降到有效用户中也许包含着已经卸载的用户，但我们无法得知。在后续的甄别用户的有效性环节被疑似卸载或者在推送下发消息过程中被判定为无效的用户，均会进入黑名单。
黑名单的用户会被当作无效用户，当然小黑屋并不会永久的关着这些设备，当这些设备“诈尸”（token发生变更/持续活跃）的时候，会把这些用户从小黑屋中放出来。
根据上面的描述，因为有效用户中还包含着卸载的用户，所以与实际可推送用户是有差距。首先推送的目标用户尽量选择活跃用户，减少目标用户中已卸载的用户比例。可以根据用户活跃周期选择“7天活跃用户、30天活跃用户、60天活跃用户”等。
甄别方式有以下4种：
根据之前几次推送结果，若均未到达认定为疑似卸载；
给用户进行预推送，通过真实推送验证是否能达到，但需与客户端约定该类消息不展示；
分析用户行为，是否连续很长一段时间都未启动过APP，疑似卸载行为；
再次检查是否已经同意推送权限。
当然，除了这4种方式以外，大家可以根据实际情况制定甄别方式。目的都是在于验证用户是否可以收到推送。在甄别有效用户环节，如果推送频率高（经过多次甄别）且用户池的自我过滤机制足够完善，那么实际可推送用户/有效用户（用户池）=95%及以上 。
下发成功率
推送任务建立之后，就会通过第三方推送平台/原生渠道（如APNs）进行消息的下发，在下发过程中，由于平台的不稳定性或者通道堵塞（APNs经常这样），再或者token配置不正确等原因，导致推送任务到达推送渠道，却无法实现下发。
那么这个时候可以观察的数据就是“下发成功率”，那这个数据是怎么计算的呢？
我们需要根据下发渠道的返回状态判断是否下发成功，如第三方平台/APNs会给你返回消息下发是否成功。那么“下发成功数/实际推送目标用户=下发成功率”，下发成功率在95以上较为正常。
什么情况会导致下发失败呢？
上面大致也已经描述了几种可能性，可能是推送平台网络不稳定造成网络丢包，或者推送通道阻塞导致通道堵着了；也可能是推送平台建立的长连接失效了，给你返回令牌失效。所以下发过程中的损失难以避免。
我们可以做的是：
若返回推送失败是因为token失效，则把用户从有效用户池中剔除（进黑名单）。
若怀疑是网络不稳定或者通道阻塞，请稍后再使用重发机制。
若平台经常不稳定或无法下发，请更换推送平台。
我们往往把推送下发过程中的丢失当作是推送点击率低的原因，通过了解中间环节的情况，可以让我们获得真实的推送点击率。
推送消息到达率
影响推送消息能否到达的因素非常多，大家可以通过回顾<推送系统从0到1（五）：推送消息如何丢失的>了解消息为何会丢失。简单介绍下大致的原因可能是用户设备的网络状态不佳、推送通道堵塞、推送服务进程被杀死（主要）等等情况。我们可以通过分析推送到达率的情况，尽可能的减少该环节的消息丢失。
推送消息到达率=到达的推送消息数/下发消息数，可以通过客户端返回推送到达状态监控推送消息是否真正的到达（第三方平台的不准）。在此数据上Android的推送到达率普遍偏低，原因是Android设备多种多样，非常多定制化的系统会把推送服务杀死。而IOS系统推送到达率普遍较高，由于APNs为系统级推送服务，能让到达率在80%及以上，当然ANPs有时候也会不稳定。
针对Android推送到达率低的情况，可以通过大量重复实验验证，是否某款机型、系统无法收到推送通知。根据我自己的了解像OPPO、小米、华为这些定制化的系统，可能因为推送平台与系统问题，由于推送进程被杀死，导致消息到达率将会非常低。可以通过分析和实验之后考虑是否也接入这些定制系统的推送服务，当然也还是要根据用户设备情况进行选择。
推送消息展示
虽然我们不常观察推送消息展示比例，一般我们认为推送消息到达设备，那么就一定会展示，所以直接使用推送到达率观察到达情况。
但我还是想和大家介绍下，像Android系统消息到达和消息展示是两回事。这个发现是我在做消息重发机制时，为了防止重复发送导致用户突然收到多条消息，那么在Android系统上通过控制收到的消息是否展示出来，从而解决这个问题。既然如此我们也可以认为推送消息到达了，但有可能未能正常展示出来。
虽然这个比例会很低，而且未能找到官方的数据。但是我们有理由相信这里也会有一小部分的损失。
在此，我再次放出系列文章第五篇的图片，相信大家再次看到这张图的时候，能够明白我要逐个环节介绍的原因。
推送点击率
推送点击率是我们最常观察的指标，也是我们常误解的指标。推送点击率的计算方式为：推送点击率=推送点击数/推送到达数
而许多人常常把推送点击率误认为是点击数除以推送总数。所以有时候你发现IOS的推送点击率才不到1%，那么请你好好的检查下，你的计算方式是否存在错误。
那些根本没到达用户设备的推送通知，根本不存在点击率一说。所以我们需要分析每个环节的数据也是因为如此。我们要分析真正的点击率，就只能先确认消息都到达了。
通过查阅资料和自身项目的实验发现，确实很多时候Android的点击率会高于IOS的点击率。但是影响推送点击率更多不在技术问题，而在于推送运营策略上，详见<推送系统从0到1（九）：推送的运营策略>。
除此以外需要注意的是推送通知栏的特性，如IOS12会把消息进行分组折叠，Android7及以上也有分组的功能，还有消息的勿扰模式等等。
在这个环节我们可以通过横向和纵向比较数据分析点击率的情况。横向是指每次推送点击率的比较，通过运营策略提高自身推送点击率，如时间、推送文案等等。而纵向指的是与同业或竞品比较数据，通过分析推送消息的展示情况、系统特性以及相关技术问题，进一步提高推送点击率。正如我前面所说，影响点击率有非常多的因素，需要持续分析研究，才可能可以找到最大的问题点。
推送转化率
推送的本质还是把合适的内容主动呈现在用户面前，而内容才是其中的关键。通过分析用户点开推送进入到着陆页的转化数据，可以作为运营指标进行研究。这也是推广路径的一种，可以通过分析用户关键行为、交互数据、关键指标的转化等数据进行分析。我相信这一步营运都有非常丰富的经验，在此就不再复述了。
本章总结
简单总结一下，观察推送过程中数据指标，分析这些数据背后的原因，从而减少消息的丢失，并把推送的效果发挥到极致。这是本章通过数据优化推送系统的目的所在。那么本章介绍的主要数据指标为：
消息到达率：消息到达数/下发成功数；
推送点击率：消息点击数/消息到达数；
推送转化率：关键指标点击数/消息点击数（页面访问人数）。
大家可以通过分析以上几个关键指标，提出优化方案，让推送系统更完善。再结合上一章所讲的运营策略，那么我相信推送效果一定能有所增长。
下一篇是系列文章的最后一篇，会为大家介绍推送会影响APP/网站的相关数据指标，如卸载量、活跃数等，尽请期待。
相关阅读
推送系统从0到1（一）：是系统不是工具
