直接结论
两家商店现在都提供了原生的 listing 实验能力——Apple 的 Product Page Optimization（PPO）和 Google Play 的商店 listing 实验——让它们真正有用的纪律是同一套：一次只测一个假设、选流量足够读出结果的表面、跑够能信任结果的时长。两个平台的范围不同：PPO 测的是视觉素材（图标、截图、预览视频）对比当前页面，Play 实验还覆盖简短描述和完整描述这类文本字段。但它们都不能替你判断该测什么：价值最高的实验来自第一张截图和图标（它们触达每一个访客），以及来自被观察到的问题——某个市场的转化缺口、评价用语和 headline 打架——而不是「试试蓝色版本吧」。
平台对比
| 维度 | Apple PPO | Google Play 实验 |
|---|---|---|
| 可测表面 | 图标、截图、App 预览视频 | 图标、置顶大图、截图、描述 |
| 元数据文本 | 不可测（标题副标题固定） | 简短描述和完整描述可测 |
| 变体数量 | 最多 3 个处理组对比当前页面 | 多变体对比当前 listing |
| 本地化 | 处理组可指定特定 locale | 实验可按 locale 运行 |
| 时长 | 最长 90 天 | 自定；读到显著为止 |
规划前在两个后台核对当前限制——平台能力会随时间调整。
推荐流程
1. 在流量所在的地方测试
实验需要量级才能收敛。如果你的 listing 流量一般，就测每个访客都会碰到的表面——图标和第一张截图——跳过那些要一个季度才能显著的细粒度测试（比如第 5 帧的措辞）。
2. 先写假设，再做变体
「在日本市场用协作功能开场替代速度主张，转化会上升」是可检验的，而且无论输赢都教你一课定位。「换张首屏截图试试」只产出一个数字，不产出教训。
3. 每个变体只改一个信息变量
一个同时换了 headline、版式和配色的变体赢了，你也不知道为什么赢。测信息时锁定视觉风格；测风格时锁定信息。
4. 让测试跑完
早期结果波动剧烈，看到第一个「看起来显著」的日子就停，是把噪声制度化的标准姿势。开始前根据流量算好读数窗口，不偷看、不提前停。
5. 把赢家滚动进整个信息系统
赢下的首屏信息是定位证据，不只是一张换掉的图：标题、描述开头、其余帧可能都需要向用户真正响应的东西对齐。大多数测试项目的价值就漏在这里——赢家上线了，系统没更新。
6. 记录每一次测试，包括输掉的
测试日志（假设、变体、结果、决定）能阻止团队把两个季度前输过的东西再测一遍，也会沉淀出「你的市场真正响应什么」的真实档案。
常见失败模式
在低流量上测鸡毛蒜皮
低流量 listing 上对深层帧或描述做微测试，会永远跑不完、以不显著收场。测试粒度要匹配流量现实。
提前宣布结果
任何实验的前三天看起来都很有说服力。把「早期赢家」直接上线的团队，采样的是自己的没耐心。
赢家和 listing 其余部分打架
上线获胜变体却不更新周围的信息系统，得到的是一个自相矛盾的 listing——那场胜利来自一个页面其余部分没有兑现的承诺。
没有基线问题的测试
「我们该测点什么」驱动的实验，和「观察到转化缺口」驱动的实验放在一起,后者赢面稳定更大——因为假设空间被证据约束过。
listing 实验清单
- 假设成文，锚定在被观察到的问题或机会上。
- 表面按流量选：流量一般就测高触达表面。
- 每个变体一个信息变量；风格保持不变。
- 读数窗口按流量提前算好；不提前停。
- 赢家传播到完整信息系统，不是只换一张图。
- 测试日志更新——假设、结果、决定——包括败绩。
执行原则
如果你说不出一个测试输了能教你什么，它就还不是实验——它是一台带分析后台的老虎机。
为什么这件事适合放进 App Store Helper
App Store Helper 保存着实验依赖的假设链：每一帧被分配的信息、当前的承诺层级、每次读数后改了什么。变体获胜后，把信息传播到元数据、截图和各语言版本是一次带 review checkpoint 的项目编辑——而不是在设计文件堆里寻宝。