大家好，今天来为大家解答友盟 卸载率这个难题的一些难题点，包括友盟推送服务怎样统计App卸载也一样很多人还不了解，因此呢，今天就来为大家解析解析，现在让大家一起来看看吧！如果化解了无论兄弟们的难题，还望无论兄弟们关注下本站哦，谢谢~

一、友盟推送服务怎样统计App卸载

首先需要澄清一点的是，友盟统计解析服务不会统计，也不能统计设备上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群组了，假设之前这个设备上只有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开发者和运营人员来做参考。

二、6 招降低 App 卸载率,减少用户流失

降低App卸载率、减少用户流失的6个决定因素方式为：优化推送策略、保护用户隐私、改善UX/UI设计、拉近和用户距离、定期更新App、创建用户社群并开展App内活动主题，同时做好监控优化。具体内容如下：

优化推送策略合适的时刻：推送消息需避开用户休息或忙碌时段，例如职业日的早8点前、午休及晚10点后，选择用户活跃时段推送可提高信息触达率。

有意义的内容：推送需聚焦用户核心需求，例如电商类App推送限时折扣、工具类App推送功能更新提醒，避免发送和用户无关的广告或促销信息。

推送内容本地化：根据用户地理位置推送本地化服务信息，例如天气类App推送区域降雨预警、外卖类App推送附近商家优惠，增强信息实用性。

保护用户隐私提供多种注册方法：允许用户通过邮箱、社交账号（微信、微博等）直接登录，减少强制手机号注册带来的隐私顾虑。

简化注册流程：若必须注册，需在页面显著位置说明注册特权（如数据同步、唯一服务），并明确告知信息运用范围，例如“仅用于账号验证，不会用于其他用途”。

数据最小化收集：仅收集功能必需的用户信息（如付款类App仅需绑定银行卡），避免过度索权（如阅读类App标准访问通讯录）。

改善UX/UI设计视觉设计优化：采用简洁直观的界面布局，例如运用高对比度配色、标准化图标（如放大镜代表搜索），避免复杂动画或弹窗干扰用户操作。

用户引导页设计：通过分流程教程引导用户完成核心功能操作（如电商App引导第一次购物流程），帮助用户快速熟悉App运用逻辑。

交互流程简化：减少操作流程（如一键下单、自动填充表单），例如外卖类App将“选地址-选商家-选菜品-付款”流程压缩至3步内。

拉近和用户距离

收集用户反馈：通过问卷、评分弹窗、点评区等渠道主动收集用户偏好（如功能需求、运用痛点），例如游戏类App在更新后推送“本次更新无论兄弟们最期待的功能”问卷。

及时回复差评：针对低分点评（如1-2星）需在24小时内回复，提供化解方法（如补偿优惠券、技术排查），例如用户反馈“闪退”后，回复“已定位难题，请更新至新鲜版本化解”。

建立用户画像：根据行为数据（如运用频率、功能偏好）将用户分类（如高频用户、价格敏感型用户），为后续特点化运营提供依据。

定期更新App

功能迭代优化：根据用户反馈修复已知Bug（如付款失败、页面卡顿），并新增实用功能（如社交类App增加“群聊”功能），例如地图类App更新后优化路线规划算法。

控制更新频率：避免频繁更新（如每周多次），提议每月1-2次重大更新，减少用户因更新疲劳而卸载，例如工具类App可集中优化性能后统一公开。

创建用户社群并开展App内活动主题

建立社群渠道：通过微信群、QQ群、论坛等平台搭建用户探讨圈，例如健身类App创建“减脂打卡群”，鼓励用户同享经验。

开展App内互动：配置即时聊天功能（如内置客服）、吐槽专区或任务体系（如每天签到领积分），例如阅读类App推出“读书打卡挑战赛”，提高用户粘性。

实时监控优化：通过数据解析工具（如Google Analytics、友盟）跟踪用户行为数据（如卸载率、运用时长），定位难题环节（如某功能运用率低），针对性优化产品。