白鲸出海昨天有个提问，我读了三遍。
提问的人做北美市场的 AI 写作应用，团队两个人——他自己加一个兼职运营，产品刚过冷启动，月流水 1 万美元上下。上个月他们把 Pro 档从 9.99 美元/月改成 14.99 美元/月，同时加了一个 99 美元/年的年付选项。
结果：首周付费转化率从 4.2% 掉到 3.4%，年付只占 11%，退款率还涨了 2 个百分点。
（他标题里写的是"跌 18%"，按 0.8 个百分点算其实是 19.0%。差一个点，不影响后面的结论，但这种口径差在定价这种精细活里很要命——后面会说到。）
他卡在一个具体的选择上——先测年付折扣力度，还是先回调月付价格？两人一周只能排两轮测试，样本量一直不够，App Store 那边改价格还要排队等审核。
很多人看到 4.2% → 3.4%，第一反应是"涨价翻车了，赶紧降回去"。
但这个 19% 是假的。真正被算错的，不是结论，是口径。
先把账算完：你其实赚了 21.5%
转化率跌了 19%，但客单价涨了 50%。这两件事乘起来是什么？
改版前，每 100 个安装里有 4.2 个付费，每个付 9.99：
4.2% × 9.99 = 0.4196 美元 / 安装
改版后，每 100 个安装里有 3.4 个付费，每个付 14.99：
3.4% × 14.99 = 0.5097 美元 / 安装
涨了 21.5%。
这个结论有个反直觉的地方：它跟苹果抽多少成完全无关。15% 的小企业计划也好，30% 的标准佣金也好，因为抽成是乘法，分子分母同时被它乘一遍，比值不变。0.4196 打八五折是 0.3566，0.5097 打八五折是 0.4332，还是 +21.5%。
那退款率涨的 2 个百分点呢？也吃不掉。哪怕原来的退款率是 8%，涨到 10%，净收入/安装还是从 0.3281 涨到 0.3899，+18.8%。退款吃掉的是绝对值，吃不动这个比值。
所以第一件事是：这个改动，从收入角度看大概率是对的。他不是把生意做砸了，他是把单价提上去了、把一部分价格敏感用户筛掉了，剩下的人付得更多。
那他到底错在哪？
错在拿"一周"当单位
他帖子里有一句话特别关键："已经在 Stripe 上跑了三个价格点的小流量测试，但两个人一周只能排两轮，样本量一直不够。"
他知道样本量不够，但他不知道自己差多远。这个可以算。
要用统计上站得住的方式区分 4.2% 和 3.4%（双侧 5% 显著性、80% 检验力），每组大约需要 8,965 个安装。
接近 9000 个安装是什么概念？按他 1 万美元月流水、客单价 10–14 美元反推，活跃订阅在 700–1000 个之间。假设月新增 80–120 个付费——对刚过冷启动的产品是个正常区间——对应月安装量是 1,900–2,900 个。
也就是说，光一组就要跑 3 到 4 个月。两组跑完，七八个月过去了。
而他手里的一周数据是多少？按上面推算，一周 440–670 个安装，4.2% 是 19–28 个付费。跌到 3.4%，就是二十来个变成十六七个。
三个人的差别。
价格实验里最贵的东西不是折扣，是判定时间。一个两人团队拿一周的数据下结论，等于在掷骰子——而且他会根据掷出来的点数调整策略，越调越乱。
更麻烦的是，他接下来要做的选择（年付折扣 vs 回调月付）本来就建立在"转化跌了 19% 是坏事"这个错误前提上。前提塌了，后面排什么测试都是浪费。
第二个坑：iOS 根本不是做价格实验的地方
他提到"App Store 的订阅价格组审核又要等"。我翻了苹果官方文档，这条约束比他以为的更硬：
-
• 价格点不能随便定，要从固定档位里选（App Store Connect 里可展开到 800 个价格点）； -
• 每个店面、每种计费方案，一次只能安排一笔未来价格调整，排第二笔会覆盖第一笔；生效时间只能提前 1–2 天预约； -
• 老订阅者要提前通知：月付 27 天、年付 60 天； -
• 涨价触发"强制征求同意"的门槛是：涨幅超过 50%，并且月付价差超过约 5 美元（年付是每年约 50 美元）；或者该订阅在 12 个月内已经涨过一次。触发之后，老用户必须在下次续订前点"同意"，不点就到期终止。
看到这里我停了一下。他这次 9.99 涨到 14.99，涨幅是 50.05%，价差正好 5.00 美元。
两个条件要同时满足才触发强制同意。涨幅过了 50% 这条线，但价差 5.00 美元没有"超过"5 美元——所以卡在门槛里侧，只走通知、不用征求同意。再往上定 5 毛钱，就是另一套流程了：老用户集体收到"是否接受新价格"，不接受就流失。
这不是他设计出来的，是运气。但它说明一件事：iOS 端的价格不是一个你能随便试的变量。你有固定档位、有排期、有通知期、有 12 个月一次的频率限制、还有一条随时可能踩到的同意门槛。
在这种约束下做 A/B 测试，等于在别人家的服务器上跑自己的实验。
所以他的问题"先测年付折扣还是先回调月付"，问错了方向。正确的问题是：这个实验我该在哪里做。
Web 端用 Stripe，价格随时改、随时回滚、样本独立、次日就能看数；而且同样收 14.99，iOS 扣完 15% 是 12.74；Stripe 按官方定价页当前展示的 3.4% + 0.5 美元算，到手 13.98（美国本土卡费率更低，会更接近 14.26）。同样一笔钱，多留一成。价格实验放 Web 端，不光是跑得动，是每一单都更值钱。
第三个坑：那个 99 美元的年付，折扣给太深了
14.99 × 12 = 179.88。他把年付定成 99，等于打了 45% 的折，相当于送 5.4 个月。
行业里常见的年付折扣是"送两个月"（约 17%）或者 20% off，对应价格是 149.90 和 143.90。他给的是这个的两倍多。
结果呢？年付只占 11%。
这说明什么——你付出了 45% 的单价代价，换来 11% 的占比。如果把 11% 的人按年付算，混合客单价是 14.25 美元/月；如果年付占比能到 25%，混合客单价降到 13.30；到 40% 就是 12.29。
换句话说，年付占比越高，账面上越"难看"，换来的是现金流提前、续费压力后移。这是笔交易，不是白捡的便宜。而他用 45% 的折扣只换到 11% 的占比，说明这个年付选项在页面上根本没被讲清楚——不是折扣不够，是没人知道有它。
所以年付该测的不是"折扣给多深"，是"怎么让 11% 变成 25%"，这是包装和展示问题，样本需求比价格实验低一个数量级，两个人一周两轮完全跑得动。
两人团队该怎么排
如果这个人来问我，我会给他四条：
一、把判定指标从"首周转化率"换成"每安装 30 天净收入"。 转化率是中间量，受涨价、退款、年付比例三重影响，而且首周样本只有二十来个。净收入/安装是终局量，一个数就能下判断，还自带退款。
二、只测大跨度，小跨度别测。 样本需求跟差值的平方成反比。测 9.99 vs 14.99（差 50%）要 8,965 个安装/组；测 9.99 vs 19.99（差 100%），如果转化掉到 2.5%，样本需求降到 1,757 个/组——一个月就能跑完。小跨度的调整不用实验，用"改完之后看 30 天队列"就够了。
三、iOS 端只做一次性定价，价格实验全部搬到 Web。 苹果那边的档位、排期、通知期、同意门槛，本来就不是为实验设计的。你在 Web 端测出来的最优价，再同步到 iOS，中间隔 27 天通知期，慢一步，但可控。
四、一次只动一个变量，而且要提前写停手条件。 他现在的困境是变量叠在一起：涨价、加年付、改展示，三个动作同时上，出了问题根本归不到因。两人团队尤其要克制——不是"一周跑两轮"，是"一轮跑够样本"。
最后一件事
这个故事里最值钱的不是"涨价要算收入别只看转化"，也不是"小团队别做 A/B 测试"。
是他其实已经做对了一半，却准备把它改回去。
如果那天他没去白鲸发帖，而是直接看后台的数字、把价格降回 9.99，他会丢掉 21.5% 的每安装收入，然后永远不知道丢的是什么。而且他会得出一个错误的经验——"涨价在我们这行行不通"，带着这个经验，下次还会犯同样的错。
出海做订阅的人，最后都会撞到同一堵墙：你能测什么，取决于你有多少流量；而你怎么定价，决定了你需不需要测。
流量小的时候，定价就不该是"实验出来的"，该是"算出来的"——算你的价值、算你的替代品、算你的抽成结构，然后一次定到一个不那么容易后悔的位置，剩下的交给队列观察。
一周两轮测试，是小团队最像大公司、也最没用的一种努力。