友盟是怎么统计卸载的

首先需要澄清一点的是,友盟统计分析服务不会统计,也不能统计设备上App卸载的信息的,友盟统计分析服务只会针对集成友盟统计分析SDK的App提供类似新增、日活、留存等基本指标,或者是开发者自定义的一些统计信息,如自定义事件等。

统计卸载信息其实是在友盟推送SDK里面做的,并且当前统计到的卸载信息也已经部分应用在了消息推送服务里面。接下来就提问者感兴趣的如何统计卸载设备,以及我们目前如何使用这部分卸载信息简单给大家讲一讲,太细节的东东就不便透露了。当然,我们的卸载只是针对Android平台来做的,iOS上由于苹果的限制,卸载统计从技术上是很难实现的。

先来说说友盟推送是如何统计卸载:

如果一个设备上有多个集成友盟推送SDK的App的话(注意,必须是集成了友盟推送SDK的App),我们把这些个App称为一个群组或者联盟,同一个群组内的App在推送的通道上是做了很多互保和优化工作的,比如长连接通道就是在这多个App之间共享的。

同一个群组里面的App,如果有某个App发生卸载行为的话,那么这个卸载事件就可以被群组里其它没有卸载的App所知晓,该卸载事件就可以上报给服务器端,服务器端就可以知道哪台设备上哪个App被卸载了。同一个群组内的App之间互相检测卸载是一种常用的手段,但是这个要依赖于设备上集成友盟推送SDK的App有很多个,形成一个群组,如果只有1个App集成了友盟推送的话,那么这种手段是无法捕获到卸载的。 群组内的App越多,卸载统计收集的效果越好。

写到这里,肯定有一部分开发者要问,如果设备上只有1个集成友盟推送SDK的App的话,那么如何统计到这个App是否被卸载了呢? 这种情况下,我们只能判断到一部分卸载的情况,外加一些其它的辅助判断信息。

那么哪部分可以统计到呢? 其实还是要依赖于App群组了,假设e799bee5baa6e997aee7ad94e58685e5aeb931333361306437之前这个设备上只有App A集成了友盟推送,并且A被卸载了,假设后续又安装了集成友盟推送SDK的App B,那么如果给App A发消息,消息送达设备后(因为App B在,所以消息走的是B建立长连通道), 会尝试投递给App A,因为A已经被卸载了,所以投递是不成功的,App B就能感知到这一事件,因此也可以把该卸载信息上报回友盟服务器,服务器也就知道该设备上A App已经被卸载了,其实还是要依赖于设备上的App群组功能。

如果该台设备上后续一直没能有集成友盟推送SDK的App被安装,那么我们只能通过粗糙的看多少天不活跃,比如180天不活跃的App,我们认为这台设备上App已经被卸载了(有一定的偏差,比如某些工具类App,有可能打开频率就非常低),这个不一定准确,但是根据活跃度做用户分层多少也能看出来App的健康度。

接下来再谈谈为什么推送服务要收集设备上App的卸载信息的:

这个其实是和推送的一个硬指标“送达率”戚戚相关的,对于卸载的App,消息肯定是下发不了的,所以在评估送达率的时候,得把这部分卸载的量踢掉,否则在评估和计算送达率的时候,会导致送达率的下降或者不准确。

举个简单地例子,假设某个App有100W的装机量,过了一段时间有20W的卸载(根据我们的观察,20%的卸载率就算平均水平了),那么一次发送任务加入送达了40W的App,那么最终的送达率应该是 40W/(100W-20W) = 50%, 而不是 40W/100W = 40%。 卸载设备的统计越准确,对于最终送达率的评估效果越好。

最后我们来说说卸载统计在友盟推送服务中的应用:

首先在每次推送任务的时候,对于提交过来的device-token,我们会做一次清理,把卸载设备清理掉,所以有时候App开发者或者App运营人员会发现,他们提交的发送总数和友盟后台显示的当次发送数对不上,那就是因为友盟后台已经剔除掉了当次发送任务中的卸载设备了。

其次,当前的卸载统计我们还在进一步的分析和评估中,如果我们收集到的卸载设备数量足够准确,足够全面的时候,我们会把这个功能开放出来,放到统计分析系统里面供App开发者和运营人员来做参考。

转自wy

你可能感兴趣的:(友盟是怎么统计卸载的)