App Store Connect 一次只能运行一个产品页面优化测试，每个最长 90 天。如果流量一般，一年下来可能只能做寥寥几个真正有效的测试。每浪费一个测试，就要损失好几周。
以下是最常导致测试被浪费的错误，以及如何避免它们。
1. 一次改动所有东西 #
处理方式换了新的说明文字、新的背景、新的顺序和新的第一张截图。它胜出了。您学到了什么？没有任何能用在下一次设计中的东西，因为您不知道是哪项改动起了作用。
正确做法： 每个处理方式只改一处。如果有三个处理方式，就用它们来测同一个点子的三个版本：三种不同的第一张截图，或三种说明文字风格。
2. 测试小到无法测量的改动 #
改动说明文字中的一个词，也许只能让转化率变化 2%。在 3% 的转化率下，检测 2% 的提升每个处理方式大约需要一百万次展示，而大多数 App 在 90 天内达不到这个量。测试一直在跑，置信度始终到不了 90%，您最后什么也没学到。
正确做法： 开始之前先用 A/B 测试计算器算一算，如果流量一般，就测试大胆的改动。为什么测试始终达不到置信度详细解释了这些数字。
3. 一看起来不错就立刻停止 #
第四天：+25%，置信度刚刚突破 90%。您应用了它。但早期的数字波动很大，如果每天查看、一看到好看的时刻就停下，您常常会用一个根本没有更好的处理方式“胜出”。
正确做法： 开始之前就定好最短运行时间（至少完整的一到两周），在此之前无论数字如何都不要停止。
4. 在节假日或发布期间运行 #
跨越黑色星期五、App Store 推荐位或您自己的广告活动的测试，测量的是与平时不同的受众。胜出者在普通的一周里未必还能胜出。
正确做法： 避开不寻常的周份，或者至少记下测试期间发生了什么，以便判断结果。
5. 处理方式太多，流量跟不上 #
三个处理方式意味着流量被分成四份，而每个处理方式都需要完整的展示次数。对一个较小的 App 来说，这会把 40 天的测试拉长到 120 天，而 Apple 不允许运行这么久。
正确做法： 流量有限时，用一个处理方式对比原始版本。只有在流量足够时才使用三个处理方式。
6. 在错误的本地化语言中测试 #
测试只统计您所纳入的本地化语言带来的流量。只纳入一个小市场，您就要等上好几个月。把差异很大的市场合并在一起，一个市场的胜出可能会被另一个市场的落败抵消。
正确做法： 从最大的市场开始，只合并您预期反应相似的市场。参见如何对本地化截图进行 A/B 测试。
7. 忘了 App Review #
每个处理方式在测试开始前都要经过审核。违反 App Store 截图指南的截图，比如无法证实的说法或 App 中并不存在的界面，会导致测试被拒。此外，备用 App 图标必须已经包含在已发布 App 的二进制文件中，所以图标测试需要先发布一次 App 更新。
正确做法： 用与产品页面相同的标准要求处理方式，并围绕版本发布来规划图标测试。
8. 上传时出错 #
手动上传意味着要把截图集拖进每个处理方式的每种本地化语言、每种设备尺寸中。很容易把英文截图放进法语处理方式，或者弄错顺序，而您往往要等到结果看起来不对劲、或者过了 App Review 之后才会发现。
正确做法： 提交前检查每个处理方式的本地化语言，或者交给工具来做。Screenshot Studio 可以将处理方式直接上传到测试中：您只需选择测试和处理方式，每种语言和设备尺寸都会放到正确的位置。
9. 什么都不记录 #
六个月后：胜出的是更大的说明文字，还是深色背景？没有记录，您就会把同一个点子测两遍。
正确做法： 每次测试前，写下改动内容、您认为它会胜出的原因，以及最短运行时间。测试结束后，记下结果，包括“没有差异”。我们的 25 个 A/B 测试点子采用的正是同样的“改动 / 假设 / 胜出”格式。
让每一次测试都有价值 #
一个好的测试就是：只改一处，改动大到可以测量，运行时间足够长，并且在正确的市场中进行。制作和上传处理方式花的时间越少，您一年中就有越多时间用于真正的测试。Screenshot Studio 正是为此而打造的。