先看到升级的人数，Baremetrics 那次免费方案试验似乎相当不错。
按创始人 Josh Pigford 对 2015 年经历的复盘，11 周里出现了 1,000 多个免费账户。按当时业务条件筛选，461 个属于可能成为付费客户的账户，其中 53 个升级。用这 461 个作分母，转化率约为 11.5%。
但同一份复盘接着写道：服务开始越来越难维持。
这项方案于 2015 年 8 月 18 日推出。此前，Baremetrics 从注册时就收费，依靠退款保证降低客户顾虑。新的免费方案没有使用时限，也没有按客户数量设上限，主要通过功能划分免费和付费：更完整的历史数据展示、更深入的分析工具，需要升级。
问题在于，少展示一些功能，没有让后台少做同样多的工作。
Josh 解释，系统仍需导入账户的完整历史数据，再计算和保存指标。免费账户增加以后，处理量迅速上升，支持工作也变多。团队一边应付性能问题，一边处理由这些问题引起的咨询，产品本身的改进逐渐被挤开。
客户看到的是延迟的数据、故障和不准确的指标。复盘称，这 11 周里有将近 60 名客户流失。这里的 53 次升级与近 60 次流失，是作者对同一观察期的报告；它们不是一组足以分离所有原因的对照实验，也不应被拿来直接计算净利润。
后来，团队改成 14 天的完整试用。试用结束后，没有选择付费方案的账户停止继续处理数据。同时，他们也调整了基础设施。Josh 没有宣布免费模式普遍失败，而是把结论限定在团队当时的资源与做法上。
这个故事的资料还有一个需要先交代的边界：文章原发于 2015 年 11 月 9 日，现在的页面标有 2026 年 11 月 2 日更新，并包含后加的说明。本文讨论的是其中描述的 2015 年试验，不把旧事件当成今天刚发生的新闻，也不采用附加问答里的行业转化率结论。
我认为，这次选择最值得拆开看的，是收费页上的限制与实际工作量的限制。
在用户眼前，免费账户可能只显示少量结果；在服务背后，数据获取、计算、保存和答疑却可能已经完整发生了。把“高级结果只给付费用户看”写清楚，只解决了购买条件，没有回答免费使用会消耗多少工作。
独立开发者很容易先问：免费用户中有多少人会付费？Baremetrics 的经历提醒我们，还需要同时问：在他们决定之前，团队已经交付了多少，现有用户的体验有没有改变？
假设你做一款录音整理工具，免费账户只能查看前几分钟的文字。这是一个假设案例。如果系统仍先把整段录音全部处理完，再遮住后面的结果，那么限制展示范围未必限制了计算量。这里并非建议随意缩减服务，而是提醒团队先把界面承诺与实际执行对应起来。
可以画一条很短的工作记录：收到文件时做什么，生成结果前做什么，用户离开以后还做什么，何时停止。每一步注明谁承担工作，以及一次任务很大、任务连续进入时会发生什么。支持时间也应留在记录里，因为一个处理失败的任务，可能同时产生重试和解释两项工作。
在扩大免费入口之前，我会用自己生成的样例任务，检查不同长度和同时到来的任务会怎样排队，再安排一段范围明确的观察。要看注册与升级，也要看等待时间、失败情况、求助数量，以及已有用户能否照常完成工作。只看新增人数，会让服务质量的变化留在另一张无人对照的表上。
观察安排还需要一个能够执行的回退步骤。出现持续积压时，谁来决定暂停新增名额，用户会看到什么说明，正在处理的任务怎样完成，都应事先写清。这样才不会等到所有人都在催结果时，再临时重新解释免费方案。
具体阈值应来自自己的服务能力，本文不提供一个通用的免费人数上限。有限试用、限制任务范围、等待名额或继续收费，都可能是候选办法；选择应由真实记录支持。
Baremetrics 的故事里，愿意升级的人确实出现了。但经营产品还要把另一半工作接住：每一次新增使用，都进入同一套需要维护的服务。把这部分写进试验，增长数字才有可以承受它的日常工作。
资料与时间：
- Josh Pigford，《How freemium nearly caused our business to implode》，原发 2015 年 11 月 9 日，当前页面标示更新于 2026 年 11 月 2 日：创始人复盘。
全文及当前附加说明核对日期为 2026 年 11 月 6 日。账户、升级与流失数字均为作者自报，本文没有取得原始业务数据，也没有验证其因果解释；录音工具及观察方法为独立假设和建议。
