头部数字:168
168 = 12 × 14。这是 Google Play Closed Testing 公布的要求。
但 Google 不是这么算的:"你累积了 168 个独立用户活跃天吗?"实际更严格:
要求:12 位独立测试员,每位连续 14 天每日活跃
不算:24 位测试员各 7 天活跃(虽然也 = 168)
不算:12 位测试员平均 14 天活跃(允许空隙)
不算:1-7 天 12 位 + 8-14 天另外 12 位
14 天连续窗口为什么重要
真人用户行为有周度模式 — 周末用得多,工作日少一些,因时区而异。14 天窗口正好覆盖两个完整周期,Google 有足够方差判断真人特征。
欺诈团伙难以伪造,因为:
- 机器人账号产生平坦的活跃模式(没有周末高峰)
- VPN 轮转账号产生不一致的时区活跃
- 付费农场账号会流失 — 多数熬不过第 5 天
Google 的机器学习反作弊模型针对此模式训练。匹配 = 通过,偏离 = 失败。
每位测试员每日活跃 = 重要
Google 准确定义(意译):测试员"第 N 天计为活跃",如果他们:
- 已经安装测试构建
- 在第 N 天 24 小时窗口内至少打开 / 使用 app 一次
- 第 N 天结束前未卸载
TestHive 的每日打卡机制对应 — 每位测试员每天交一张截图证明使用了 app。这张截图是可验证产物,你提交最终报告时给 Google 证明每日活跃。
测试员掉队的数学
如果一位测试员在 14 天窗口第 9 天退出:
第 1-8 天:该测试员计为活跃(8 天信用)
第 9 天起:不计入
你的组:第 9 天只有 11 位活跃测试员
第 9 天你低于 12 位,所以 Google 把 14 天计数器清零。8 天信用不会延续 — 你必须重新从第 1 天 12 位活跃开始。
这就是为什么 测试员可靠性比测试员招募更重要。凑齐 12 位容易;让 12 位连续 14 天活跃才是真正难的问题。
TestHive 怎么对齐 tester-day
每个 TestHive Campaign 1:1 对齐 Google 的 tester-day 模型:
- 12 位测试员凑齐才开始(匹配 Google 最低要求)
- 14 天连续窗口(匹配 Google 窗口)
- 每日发钱基于审核通过(激励每日活跃)
- 任何掉队 24 小时内补上替补测试员(你的计数器不会被清零)
最后这点是开发者容易低估的。哪怕 12 位测试员都很活跃,14 天里也有 ~15% 概率有人因私事掉队。TestHive 在第 N 天清零计数器之前就排队好替补。