推送系统从0到1（十一）：不得不看的数据

　　前面我们从推送系统的构建出发，到上一篇观察数据并优化推送已经把整个系统进行详细的介绍。而本篇作为系列文章的最后一篇，希望把推送系统作为一个整体，为大家介绍与推送相关的数据。通过本篇的介绍，让大家了解推送主要影响哪些网站数据，真实的能量到底有多大，有哪些我们不得不看的数据。
　　网页数据
　　我们从小范围的数据开始介绍，推送最先影响的数据当然是与推送内容密切相关的数据。多数情况下我们推送的网页是希望获得推广效果，推送可以帮助运营者建立与用户直接沟通的渠道。那么对于单个网页的数据观察所，需要关注指标会是网页浏览量、跳出率、停留时间。
　　1。网页浏览量
　　无可厚非，推送是一个强大的推广渠道。足够大的曝光量会让目标网页的浏览量在推送后短时间内蹭蹭上涨，然后在接下来的几个小时内保持有大量的浏览产生，逐渐在天后仍有零星的访问并一般止步于7天（IOS通知保存7天）。
　　若未提供通知中心给用户反复浏览推送目标页，那么对一次推送的目标页浏览量观察周期为7天比较合适。
　　网页访问量的变化走势将会如下图所示：
　　确实对于这种来的快的访问量深受运营者喜欢，既然它这么有效，是否任何时候都适合使用呢？
　　这个时候我们就需要关注与此相关的两个指标：网页跳出率、用户停留时间。
　　2。网页跳出率
　　关于网页跳出率我们可以观察几种含义的跳出，如PC网页跳出率，即用户未与当前网页进行交互便离开网页，另一种定义为用户未访问同域名下的其他网页便离开。如APP屏幕退出百分比，即用户未与当前屏幕进行交互便离开，另一种定义为用户在此屏幕关闭APP。
　　不管是上述哪一种观察指标，相信对于推送的网页跳出率来说，都会比一般正常渠道访问的跳出率要稍高一些。类似于投放广告引荐来的流量跳出率普遍会比正常访问的跳出率稍高，当然并不是指渠道选择不好，只是我们从用户需求的角度来考虑这个问题。
　　用户是被推送标题（甚至标题党）所吸引，点开通知后的目标网页内容并不是用户强烈需求，那么用户跳出的可能性极大。
　　用户确实有所需求，网页内容也确实符合用户预期，但是由于推送路径是由站外直接进入，并不是按照正常访问渠道，那么由于惯性思维，用户浏览完后容易选择直接返回站外。
　　用户由于使用零碎的时间点击通知，进入查看只是想大致浏览，此时用户的动机与主动启动APP浏览不同，那么用户极大可能只是随意看一眼后关闭APP。
　　所以根据上面的分析，推送的目标网页跳出率普遍高于正常访问渠道，如果推送渠道的网页并未通过渠道标记或者链接标记，也就是同时与正常访问路径的网页一同统计，那么运营人员可能就会发现跳出率突然升高。所以在此建议运营童鞋需要把用于推送的网页进行单独标记或渠道区分。
　　3。用户停留时间
　　与上述关于网页跳出率的分析相同，由于用户多是通过零碎的时间或被通知标题所吸引进入目标网页。那么与正常渠道访问的用户比起来，用户的需求、心里预期、所处场景的不同均会让推送网页的用户停留时间普标低于正常访问渠道。
　　网站数据
　　看完单个网页的数据，我们从网站APP的整体层面再看看推送对哪些数据会产生的影响，是否能带给我们意想不到的惊喜呢。首先我们需要确定的是，推送在网站中的‘分量’有多重，这也意味着它对网站数据有多大的影响。
　　1。网页流量
　　我们做个算术题计算一下推送带来的流量占网站流量最大可能是多少。假设我们用户人数代替流量计算，网站APP一共100个活跃用户，每人每天产生1个流量，就是每天100个流量。假设给这100个用户推送，到达率90且点击率高达40，那么相当于36个用户贡献了新的流量。那么我们是不是可以假设最夸张的情况下，推送带来的流量占全站高达26。
　　通过推送让全站流量增长26已经是非常有价值的免费渠道了，别企图说通过推送让网站流量翻倍，毕竟网站人就那么多，不可能凭空造出来。但是需要注意的是，我们上面计算都是基于理想情况下，实际情况会比我们想的复杂的多。
　　例如：按照GA统计流量的定义，在某个会话时间内的多次访问均计为1个流量。所以当用户正常使用过程中点开的推送，此时带来的流量有可能与正常访问的那个流量合并为同个流量，那么推送带来的流量就比我们理想情况下的要少。
　　又例如说通过推送让用户留存增加，让网站的活跃用户越来越多，那么推送带来的间接流量让网站的自然访问流量也增加了，那么我们也可以说推送带来的流量比我们理想情况下要多。所以不管怎么计算都好，如果能发挥推送最大的效果，确实能让网站流量有所增加，并且能源源不断的为我们带来价值。
　　2。人均浏览量
　　关于推送对于网站人均浏览量的变化也非常有意思，按照我们的理解推送肯定会让人均浏览量增加，但是我对此有不同的观点，我认为推送并不一定会让人均浏览量有增加，甚至可能会下降。
　　如何理解这一点呢？
　　首先我们要注意人均浏览量是如何计算的，人均浏览量浏览总量（pv）独立人数（uv）。
　　所以想要人均浏览量增加无非是让浏览总数增加，或让浏览总数不变的情况下，独立人数减少，当然我们也并不希望独立访问人数减少。而对于推送来说，不用怀疑可以让浏览总量增加，但是需要注意的是独立人数同时也增加了。如何理解呢？
　　我们再做一道算术题。假设网站还是有100个活跃用户，还有100个沉默用户。这100个活跃用户每天浏览300个网页，那么此时人均浏览量就是3001003个人；此时我针对全站200个用户推送（含100个沉默用户）。
　　假设每个用户通过推送都增加了1个网页的浏览，那么浏览总量为100（31）1001500页，此时独立用户数也因为100个沉默用户变成活跃了，所以从100变成了200。那么此时的人均浏览量为5002002。5个人，确实降低了对吧？！
　　当然上面的算术题又是个理想情况中的假设，实际情况远比这个复杂的多，因为那100个沉默用户可能被唤醒也能多浏览几页，而且那100个沉默用户并不能保证全都被唤醒。但是无论如何我们可以知道的是，推送不一定能让网站的人均浏览量有所增加。
　　3。活跃用户数
　　对于APP来说，我们常常关注的指标是活跃用户数（日周月）。因为这才是APP能贡献流量的真实有效的用户数，除此之外还有一群潜伏的沉默用户。对于活跃用户来说，可以很明确的讲推送会让APP的活跃用户数有所增加。因为推送可以让原本沉默的用户被激活，原本活跃的用户仍能保持活跃。
　　我们常用的推送策略中，有一种为专门针对沉默用户的推送。即用户假设连续沉默X天，则尝试通过推送唤醒用户。当然这么做存在一定的风险，确实有一定比例的用户被唤醒，成功的加入活跃用户的行列。但是也有部分用户已经没有需求了，而这种打扰会让用户选择卸载。所以这条策略需要有所权衡才好，千万不能为了追求短时的效果过于激进。
　　用户数据
　　其实上面活跃用户数也属于用户数据，只是想到对于APP来说，日月活跃用户就如同网站的流量一般重要，所以放在上述网站数据进行分析，也便于有个对照。而下面将会剖析推送对用户数据的有什么影响，下面都以APP为例进行分析。
　　1。用户留存
　　用户留存是APP不得不关注的核心指标之一。按照业内流传已久FB的402010留存定律，分别对应次日、7日、30日留存。用户留存也是APP运营一直需要优化的重要指标，因为留存率如同经济学中的复利的概念。
　　巴菲特是用滚雪球比喻通过复利的长期作用实现巨大财富积累，同样留存率的提升与复利的作用是相似的。曾经我有通过用户留存模型做过以下计算，假设留存率为412513且每天新增1000个用户。那么一个月后获得的活跃用户数为7514人。
　　上面都在讲述用户留存率的威力，那么推送与用户留存有什么关系呢？
　　直接公布答案推送对用户留存有明显的提升，并且对次日留存的帮助是最直接的。
　　可以想象一下这么个场景，今天新增了100个用户，按照次日留存率40来算，明天应该只有40个用户继续活跃，而其余的60个用户变为沉默用户（或卸载）。此时给所有用户进行推送，那么原本活跃的40个用户继续活跃并且沉默的60个用户中有假设有20个被激活成为活跃用户，那么此时次日留存率从40提升至60。再按照留存率的模型计算，一个月积累下来的活跃用户将会超过你的想象。
　　当然我不得不强调的是，确实大规模给用户推送，并且唤醒沉默用户能让用户留存持续增长，带来大量活跃用户。但是请把握好这个阀门，因为推送也同样会让用户选择与激活相反的路，那就是卸载。
　　2。卸载量
　　这是我最希望大家保持关注的数据，因为上面的数据多数是积极的反馈，并且是我们会持续关注的数据，但是卸载量可能我们日常的关注程度没有其他数据关注那么多。并且该数据的获取较难，像itunesconnect中并未展示用户卸载量，那么很多产品运营对自己用户的卸载量情况是不了解的。
　　关于卸载量的统计方式，建议可以参考第三方平台的统计。因为APP卸载后是无法再通过APP把“用户已卸载”的消息告诉服务端的。而第三方平台的某些进程却可以用过别的APP获取这个消息。
　　多数情况下，我们会把推送运用的极致，那么难以避免会给用户带来干扰，此时卸载量就会飙升，这是一个危险的信号。当卸载量新增用户数时，虽然不会立刻失去所有用户，但是用户池却在不断的减少。这个时候我们需要密切的关注推送频率、时机、内容是否会对用户造成干扰，是否与用户的需求不一致。
　　如果推送是造成用户卸载的原因，可能会是以下几种：
　　推送时间、时机、频率打扰了用户，让用户反感
　　用户沉默很久，暂时没有使用APP的需求，推送让用户想起卸载掉
　　推送内容与用户需求不符，用户本身对该APP并没有足够的依赖
　　这三种情况中，由于第一种导致用户卸载的比例最高。也是希望运营人员引起重视，毕竟一个新增用户的付费成本越来越高，因为推送导致用户卸载实在不划算。
　　后记
　　至此，推送系统从0到1系列已经全部完成了，虽然整个过程断断续续持续了8个月。但是每次写的过程我都想尽量总结自己的经验，查找更多的资料，希望给大家呈现更准确更有帮助的文章。
　　关于推送，可以分析的内容还有太多太多，我也只是尽自己微薄之力，从更多的角度去看待这个系统。网上关于推送的文章确实非常多，但其实可参考的确实不多，这也是我想整理下来的初心。
　　由于自己文笔不好，也是初次写文章。文中若有描述不清晰或错误的地方欢迎大家留言，我一定仔细回复，也希望大家可以谅解我的写作经验不足。
　　在此感谢支持我的同事、领导，和留言打赏收藏订阅的小伙伴
　　相关阅读
　　推送系统从0到1（一）：是系统不是工具
　　推送系统从0到1（二）：了解你的用户
　　推送系统从0到1（三）：推送任务的建立
　　推送系统从0到1（四）：消息如何到达用户设备
　　推送系统从0到1（五）：推送消息如何丢失的
　　推送系统从0到1（六）：推送的着陆页设计
　　推送系统从0到1（七）：推送用户画像建立
　　推送系统从0到1（八）：个性化精准推送的实现
　　推送系统从0到1（九）：推送的运营策略
　　推送系统从0到1（十）：从数据上优化推送