Google Play Store Listing Experiments：截图 A/B 测试全解析（2026）
在 Google Play 上，你不必猜测新的第一张截图是否比旧版转化更好——可以直接用真实的 Play Store 流量来测试。Store Listing Experiments 内置于 Play Console 的「Test and release → Store listing experiments」菜单下（Google 不止一次调整过菜单位置，一些较旧的教程称之为「Grow → Store listing experiments」）。它免费、直接运行在你的真实列表上，流量分配和统计计算都由 Google 代劳。
如果你的应用同时上架两个商店，这正是 Apple 那套流程在 Play 端的对应功能。我们在用 Product Page Experiments 对截图做 A/B 测试一文中介绍了 iOS 端的做法——思路相同，机制不同。本文是 Play 端的补充篇。
Store Listing Experiments 的运作原理
创建实验时，你先选择要测试的素材（应用图标、截图、Feature Graphic、预览视频、简短描述或详细描述），再上传最多 3 个变体，与当前的真实列表（作为对照组）一起参与测试。之后 Google 会把这些变体展示给访问你商店页面的部分用户，衡量哪一个带来更多安装。
结果中有两个关键指标：
- 获客（商店列表转化率）。访问用户在看到某个变体后完成安装的比例。这是截图测试最重要的核心指标。
- 首次安装留存（次日留存）。某个变体吸引来的用户，第二天是否还在使用。如果某个变体拉高了安装量却拉低了留存，说明它可能「过度承诺」了。
Google 会为每个变体计算置信区间，一旦某个变体达到你设定的置信阈值，就会将其判定为胜出方案。你可以开启邮件提醒，无需时刻盯着仪表盘。应用胜出方案只需一键——但通常仍建议把胜出素材走一遍常规的发布/审核流程，以保持列表其余部分的一致性。
默认素材测试 vs 本地化测试
这是最容易搞混的部分，也直接决定了你能同时运行多少个测试。
- 默认素材实验（Default graphics experiment）。测试的是默认商店列表上的素材——也就是展示给未匹配到本地化版本用户的那份列表。已获得本地化素材的用户不会计入此实验的受众。同一时间只能运行一个默认素材实验。
- 本地化商店列表实验（Localized store listing experiment）。针对特定语言版本测试素材（和/或文案）。你可以同时运行最多 5 个本地化实验——例如德语、日语、巴西葡萄牙语各跑一个，互不影响。
实际影响：如果你的安装量集中在少数几个市场，本地化实验可以让你并行测试这些市场，而不必排队等待一个全局测试跑完。另外别把「语言」等同于「国家」——选择「English (United States)」并不会把受众限制在美国，它面向的是所有被分配到该本地化列表的用户，不论他们身在何处。
设置截图 A/B 测试
- 打开 Store listing experiments 并创建一个实验。选择默认列表或某个具体的本地化列表，起一个三周后你依然看得懂的名字（比如「首图截图——利益导向文案 v2」）。
- 选择要测试的素材。选择截图。每次实验只测一个元素——不要在同一测试里同时改图标和截图，否则你无法判断到底是哪个改动起了作用。
- 上传最多 3 个变体。你的真实列表就是对照组。每个变体都需要是完整的一套截图，尺寸符合 Play 的精确规格——详见 Google Play 截图尺寸指南。
- 设置受众、置信水平和 MDE。在各变体间分配流量（常见做法是均分——单变体对照组为 50/50，三变体则大致各占三分之一）。选择置信水平（90%、95%、98% 或 99%）和最小可探测效应（MDE）——值得检测出的最小提升幅度，可配置范围大致为 0.5%–6%。Play Console 会展示测试完成条件，让你在开始前就清楚自己承诺的是什么。
- 启动后不要打扰它。克制住偷看进度、在某个变体看似领先时就提前叫停的冲动。让它跑满你设定的条件。
样本量、持续时间与达到显著性
对于「应该跑多久」这个问题，诚实的答案是：跑到达到你设定的显著性条件为止——而不是固定的天数。但现实中确实存在一个下限和上限。
- 至少运行 7 天。安装行为在工作日和周末之间会有波动。任何短于整整一周的测试都会把「星期几效应」带进结果里。两周（14 天）是常见且更稳妥的默认值，低流量应用往往需要 28 天。
- 每个变体要有足够的安装量。显著性取决于你的安装量、变体数量、置信水平以及 MDE。作为粗略的参考目标，在信任测试结论之前，建议每个变体达到 1,000+ 次安装量级——如果你设置了较高的置信水平或较小的 MDE，需要的数量还会更多。
- 参数设置越严格，消耗的流量越多。99% 的置信水平或 0.5% 的 MDE，所需的安装用户远多于 90% / 3% 的组合。如果你的应用流量较低，过于苛刻的配置可能永远无法达到显著性——这时应放宽 MDE，或接受 90% 的置信水平。
测试以「无结论」收场是一个真实的结果，不是失败。它通常意味着各变体在你当前的流量水平下差异太小，难以区分，或者测试时间不够长。这两个问题都可以解决——让变体差异更明显，或者给它更多时间。
变体数量上限及其含义
每个实验最多只能有 3 个变体对照组。这是硬性上限，也是一个特性，而非需要对抗的限制：每多一个变体，流量就被摊得更薄，达到显著性的时间也就更长。有了三个挑战者，你的商店流量实际上已经被分成了四份（对照组 + 3 个变体）。对大多数应用来说，用一个大胆、明显不同的挑战者去对抗对照组，比同时测试四个含糊不清的变化更快得出结论。
把变体名额留给真正不同的假设——不同的核心卖点、不同的视觉风格、竖版对比宽幅多面板布局——而不是同一个想法的细微变体。
应避免的常见误区
- 同时改动多个变量。在同一次测试里既换新截图又换新的简短描述 = 一个无法解读的结果。请分离变量，逐个测试。
- 看到「胜出方案」就提前收手。早期领先往往会回落。第 3 天看到某个变体领先 8% 就下结论，正是「自信满满地上线了一个更差列表」的典型操作。
- 测试时间不足 7 天。你只会捕捉到一周周期中的一部分，错过其余部分。
- 在低流量应用上设置过于严苛的统计标准。在安装量有限的情况下要求 99% / 0.5% MDE，几乎注定会得到一个无结论、且耗时耗力的测试。
- 忽视次日留存。过度承诺的截图可能提升安装量却拖垮留存。两个数字都要盯着看。
- 忘记默认/本地化的区分。默认素材实验不会影响使用本地化列表的用户——如果你的受众大多来自本地化列表，就该在那里测试。
- 只测试最后一张截图。在 Play Store 上，前 2-3 张画面承担了大部分说服工作，应优先测试它们。（关于 Play 与 Apple 的更多差异，参见：Play Store 与 App Store 截图差异。）
Mokbi 的定位
Mokbi 不负责跑 A/B 测试——那是 Play Console 的工作，而且免费。真正拖慢大多数团队的，是从头制作变体本身：一个有说服力的挑战者，意味着一整套符合 Play 精确尺寸的截图，且文案和布局要有实质性改动。在 Mokbi 中，你在浏览器里设计出一套截图，然后复制一份，替换首图文案、布局或背景，就能做出变体 B——如果你要跨市场运行本地化测试，还可以一键翻译文案。设计免费，带水印预览；无限次导出无水印成品、并发布到商店则需订阅——Solo €29.99/mo（1 个应用）或 Studio €49.99/mo（最多 5 个应用），不再有一次性买断。它负责快速做出挑战者，Play Console 负责判定谁是赢家。