靠一个 App 撑着的管控，有效率是多少：把「有效率算式」、三条衰减通道和临界值怎么算讲清楚

先给结论：衡量一套管控是不是真的在起作用，要先把两个指标分开——覆盖率和强度。覆盖率是可以算出来的：有效率 = 1 −（卸载率 + 权限回收率 + 后台终止率），三个率取同一批设备、同一个30 天窗口、同一个分母。业内常见的经验线是有效率低于 80% 就该换到系统级方案，更稳的做法是把这条线换成你自己算出来的临界有效率，因为临界值取决于机队规模、单台净敞口和迁移成本怎么摊销，而不是一个通用常数。

为什么靠一个 App 撑着的管控会自己掉下去

通道一：卸载，最直接也最容易被算错

第一条通道是把那个 App 删掉。它的特别之处在于，删除动作不需要突破任何技术防线，使用者只要在桌面上长按图标、选移除就行。因为 App 是所有管控动作的执行者，App 不在设备上，后面所有指令都没有接收方。这一条通常占比最大，但也是最容易被低估的一条：如果分母取的是「累计出库台数」而不是「当前在租台数」，卸载率会被稀释成一个很小的数，看起来完全在可接受范围。

通道二：权限回收，App 还在但已经不干活

第二条通道是 App 还在，权限没了。举个例子，App 需要通知、后台刷新、位置这几项权限中的一项或几项才能维持心跳和上报，使用者在系统设置里把这些权限改成不允许，App 图标依然在桌面上，打开也正常显示界面，但它既不能在后台联网，也不能在系统需要的时候被唤起执行动作。这条通道的本质是「执行权」和「存在」是两回事：存在不等于有执行权。

通道三：后台终止，进程不在的时候指令收不到

第三条通道是 App 进程没有常驻。原因是系统会按内存压力、低电量模式、使用频率自行回收后台进程；App 不在前台、也没有被列为系统豁免对象的时候，它大概率不会一直在跑。为什么这一条尤其隐蔽：服务端下发指令时看到的仍然是「待执行」，指令会在那里等，等到下一次 App 起来才被拉走——表面上看不到失败，只是慢，而「慢」在一个需要当天生效的处置动作里往往等同于没做。

三条通道的共同前提是同一个：App 必须常驻且被授权在后台运行。而这个前提能不能被保证，取决于设备处于什么纳管状态——处于受监督状态的系统级管控不依赖某个 App 是否在运行，它走的是系统自己的管理通道，这也是为什么同样的动作，在两种形态上的覆盖率会差出二十几个百分点。

有效率算式：三个率的定义和口径

算式本身只有一行：

有效率 = 1 −（卸载率 + 权限回收率 + 后台终止率）

难的是三率的口径必须统一，否则加出来的数没有意义：

• 分母：30 天窗口的期初在租设备与期末仍在租设备的交集，退租、回收、报废的要剔除；
• 卸载率：窗口内安装状态查不到的设备数 ÷ 分母，判定阈值建议用连续 24 小时无心跳且查询不到安装记录；
• 权限回收率：窗口内上报权限自检不通过的设备数 ÷ 分母，取的是期末仍在缺失状态的存量，不是期内曾经缺失过的累计；
• 后台终止率：窗口内心跳间隔中位数超过设定阈值（本篇取 6 小时）的设备数 ÷ 分母，同样取期末存量。

三项最常出的错是「混合时点」：把「期内曾经发生过」的累计值和「期末仍存在」的存量混在一起相加，结果会明显偏大。统一取期末存量，就不容易出现这个偏差。

怎么用 30 天做一次实测

自验的完整流程只有五步，自己就能跑完：

• 取窗口：锁定 30 天，取期初、期末两个时点的在租清单求交集；
• 拉心跳：导出这批设备在窗口内的心跳记录，按台计算间隔中位数；
• 分三组：把检测结果分别落到「安装状态缺失」「权限自检不通过」「心跳间隔超阈值」三个桶，一台设备落到多个桶时按最严重的一项计，不要重复计数；
• 算三率：每个桶的台数都除以同一个分母；
• 交叉验证：随机抽 3 台落桶的设备，人工看一眼实际状态，确认自动判定没有误划。

第 5 步不能省。自动判定依赖 App 自己上报，上报不准的时候，规则会把一批正常设备判成失效，桶变大之后三率都虚高，后面的账全部失真。

覆盖率和强度是两个尺子

同一个有效率数字，对应的实际控制力可以差很远，所以要分成两张表看：

这张表想说明的是：有效率满分不代表强度达标。一个覆盖面满分但使用者随时可以取消的方案，覆盖率是 100%、强度是不足；反过来，强度足够但 App 大面积被卸载的方案，覆盖面一样是不足的。两者必须分开量。

具体到字段层面，MDM.Plus 的回执台账把管控类型、最近一次成功回连时间、当前 ICCID 分成三个字段记录，算有效率的时候先按管控类型分组再各自计数，避免把应用层和受监督的设备放进同一个分母。

这笔账怎么算：把 80% 换成你自己的临界值

参数自己替换，本篇的取值是：机队 1,000 台、30 天窗口、单台净敞口 5,200 元（设备成本 6,400 元减已收押金 1,200 元）、全年触发处置的比例 2%、迁移成本按单台 25 分钟 × 0.6 元/分钟 = 15 元/台。

先算现状。假设实测三率分别是卸载 12%、权限回收 6%、后台终止 5%，则有效率 = 1 −（12% + 6% + 5%）= 77%。1,000 台里有 230 台在任一时点处于无覆盖状态。若全年有 2% 的设备触发处置（逾期转处置、走失、需要当天锁定），就是 20 台；其中落在无覆盖状态的是 20 台 ×（1 − 77%）= 4.6 台，折算年预期净损失 4.6 台 × 5,200 元 = 23,920 元。

再算迁移成本。把应用层设备换成受监督的系统级管控，存量设备要走一次抹除重登记，单台 15 元，1,000 台一次性成本 15,000 元。

然后是两种摊销口径，结论差很多：

• 不摊销，用一年的净损失和一次性成本直接比：临界有效率满足 20 ×（1 − E）× 5,200 = 15,000，解出 E ≈ 85.6%。也就是说，有效率低于 85.6% 时，一年内省下的损失就超过迁移投入；
• 按 3 年摊销迁移成本，年成本 5,000 元：20 ×（1 − E）× 5,200 = 5,000，解出 E ≈ 95.2%。此时合格的门槛被推高到 95.2%，有效率 77% 的设备在这一口径下明显不合格。

同一个机队，仅仅因为摊销口径不同，临界值就从 85.6% 跳到 95.2%。这就是「把 80% 这条经验线换成你自己算出来的数」的全部理由：经验线替你做了一个假设，而你很可能不同意那个假设。

采样复核的成本也要算进去：抽 100 台人工复核，单台 3 分钟、0.6 元/分钟，单次 180 元；按月做一轮，全年 12 次合计 2,160 元。这笔钱换来的是三率本身的准确性——三率不准，后面所有算式都是在错误信息上做精确计算。

三个误区

误区一：用「曾安装过」代替「当前生效」。曾安装是一个累计口径，分母里有已经退租的设备，算出来的卸载率永远好看。有效率的三个输入必须都用期末存量，不能一个是存量、一个是累计。

误区二：三率各自算了不同的分母。卸载率用累计出库、回收率用在租台数、终止率用在管台数——三个数加起来之后，结果既不等于任何一层的真实情况，也无法复算。统一分母是这条算式唯一不能让步的条件。

误区三：以为图标还在就等于 App 常驻。图标只代表安装，不代表进程在运行；看后台终止率才知道实际常驻比例，而这个数字在很多机队里是三率中最大的一项。

两条边界

边界一：本篇的算式衡量的是覆盖面，不是锁强度。判断强度要看另外一组条件：设备是否受监督、走的哪条登记路径、谁持有解除权限、设备当前处于什么状态。这四个条件不满足时，覆盖率再高也不代表处置动作能落地。本站另一篇讲 MDM 能查到的字段清单，那是「看得见什么」的问题，和本篇的「覆盖面有多大」是两个不同的测量方向。

边界二：安卓设备不要和苹果设备放在同一个分母里。安卓侧的后台运行管理、自启动白名单、厂商省电策略各不相同，同一套 App 在不同品牌上的常驻表现差异很大。像 MDM.Plus（四川星皓未来科技）这类专注租赁、分期行业的设备管控服务商，一般把不同操作系统的设备分开设阈值，而不是用一个统一数字卡所有机器，三率会被系统性拉高或压低。分 OS、分品牌各算一组，再决定是否要合并成一个数。

常见问题

问：30 天窗口能不能换成 7 天？

答：可以，但三率的含义会变：7 天窗口捕捉的是短期波动，卸载这种不可逆动作会被低估；30 天窗口更接近稳态。换了窗口之后要连阈值一起换，至少心跳间隔阈值要跟着调整，不能只改天数。

问：三率都很小，是不是就说明这套管控够用了？

答：三率小说明覆盖面够，不说明强度够。还要看使用者能不能自行取消、抹除后会不会回到原管理域。这两件事属于强度维度，不在覆盖率算式里。

问：1 −（u + r + t）这个式子假设三条通道不重叠，实际会重叠吗？

答：会。一台设备可能既被回收了权限、又被系统杀掉了进程。算式的处理办法是按最严重的一项归类，不重复计数，这样分子的台数不会超过分母。

问：为什么这个例子里迁移成本要摊 3 年？

答：摊不摊销取决于迁移后能用多久。如果这台机器的剩余租期平均只有 8 个月，按 3 年摊就是错的，应该用 8 个月折算。参数怎么取，取决于你自己的机队周转结构。

问：只抽 3 台人工复核够吗？

答：3 台是验证自动判定有没有系统性偏差的最小样本量，不是统计学意义上的抽检方案。要估计准确率需要更大的样本；只要确认「没有把大批正常设备误判成失效」，3 台就够用。

给同行的一个自验判据清单

• 三率统一用「期末仍在租的设备」做分母，任何一处用累计口径的都要重算。
• 卸载率的判定写死成两条同时成立：连续 24 小时无心跳，且安装状态查询不到。
• 后台终止率的心跳阈值写成台账里的一个显式字段，本篇取 6 小时，换机型要重定。
• 每台设备落到多个桶时按最严重的一项归类，分子台数不能超过分母。
• 随机抽 3 台人工复核，确认自动判定没有把正常设备误划成失效。
• 算临界有效率时，把摊销年限单独列出来：一篇机按 3 年摊，另一篇按 8 个月折算，结论会不同。
• 覆盖率达标之后，再单独验强度四条件：受监督、登记路径、解除权限方、设备状态，四个都写进台账。

相关阅读

• 监管锁上线前要做完的四件事：把「上线前置清单」、三张对齐表和灰度两周的判据讲清楚
• 监管锁会不会偷看隐私：把「命令通道和数据通道是两条路」、MDM 能查的字段清单和三类不该出现的配置负载讲清楚
• 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚
• 设备状态被改过之后，日志还能改吗：把「只追加不覆盖」、变更日志五字段和覆盖掉的举证价值讲清楚
• 批量锁机点了没反应，问题多半不在系统：把「回执账」、四类回执状态、看不见的失控面讲清楚
• 手工加进来的设备，前 30 天租客自己能移除管理：把「30 天可撤销窗口」、三种入库路径和两种释放权讲清楚
• 同一型号同一成色，回收报价为什么能差出上千元：把「报价分布三参数」、中值口径和设备侧四项可测字段讲清楚
• 租机公司需要什么系统？先把「台账最小集」这 12 项字段问清楚