# 一个$5/月的产品到底需要多少用户？

URL: https://caijiao.org/posts/219
Source: docs/posts/219.md
Description: 月收入的靶子决定人数：三百美元要六十人，一万两千美元要两千四百人，两万三千美元要四千六百人；若按百分之五月流失估算，还得每月新增相当于存量百分之五的人才能停在那儿。

先把答案按三档摆出来，它完全取决于你想落在哪个数上：每月 300 美元要 60 个付费用户，每月 12,000 美元要 2400 个，每月 23,000 美元要 4600 个。五美元的单价，这三个数就是除法的结果。

五美元这个价位在现实里有个锚：TinyWow 的会员层是每月 5.99 美元。它不是一个随手写在页面上的数字——比它再低，每笔收款里固定开销占的比例就会变得难看；比它再高，用户开始认真比较同类产品，决策时间明显拉长。这是我的推断，没有公开数据支持。

三档靶子都不是随手挑的。300 美元接近 terrific.tools 的第一个完整变现月；12,000 美元对应 Cloakist 与 Sotion 合计超过 $12k MRR 的规模；23,000 美元是 Data Fetcher 公开的 MRR，它有 600 个付费客户，客单价约 38 美元。同样的三个人站在不同价位的产品后面，人数乘数是七点七倍。

![terrific.tools 官网首页截图](/images/2026-09/terrific.tools.png)

*terrific.tools 首页在显著位置推 macOS 和 Windows 桌面应用，文件转换可以离线跑。*

## 只算除法是不够的，流失会把人数钉住

订阅数不是累积出来的，是存量。假设月度流失 5%（这是我的假设，没有公开数据支撑它适用于你的产品），稳态下的订阅人数约等于每月新增人数除以流失率，也就是新增的二十倍。

照这条式子往下算：要保持 600 个付费用户，每月得新增约 30 个；要保持 4600 个，每月得新增约 230 个。人数的增长会在某处停住，停在哪儿取决于你每月能稳定拉进来多少人，而不是取决于产品有多好。

换成钱更好懂：每个流失的用户带走的是接下来二十个月的五美元，也就是一百美元。

再看一个更接近日常的情形。假设每月稳定新增 20 人、流失率仍是 5%，人数会停在 400 人附近（20 除以 0.05），对应的月收入是两千美元。想把它推到三千美元那一档，要么把新增提到 30 人，要么把价格抬一档——五美元处的每一次提价，都等于把同样的工作再做一遍。

## 从访问量倒推，才知道要建多大的入口

再往前推一层。假设访客到付费的转化率是 1%（这是我的假设），每月新增 30 个付费需要约 3000 次访问，新增 230 个则要约 23000 次。转化率降到 0.5%，两个数字都要翻倍。

对照一下现实中的刻度：Gusto 那个免费工资计算器的月访问约 17776，已经接近中等需求；Shopify /tools/ 下的利润率计算器峰值月访问超过 2 万；而 Inch Calculator 是 459 万。也就是说，一个五美元的产品想走到 Data Fetcher 那一档，基本需要有若干个月访问量在两万以上的页面在进人。

## 同一笔钱，交给广告要多少流量

把订阅换成广告，同一个数字会长得很不一样。要拿 3000 美元的月收入，按 terrific.tools 公开的每千次会话 6.89 美元计算，需要约 43.5 万次会话一个月；而用五美元订阅的话，保持同样的月收入只要约 600 个在线客户，按上面的假设，每月新增 30 个人、约三千次访问就够维持。

这条对比本身就说明为什么小价位的产品不必在意总流量：它需要的不是人群规模，而是人群里那一小撮愿意按月付钱的人。

反过来读也很清楚：如果没有任何称得上精准的入口，五美元的产品只能靠大量泛流量去凑那一千个人里的一个，走到三千美元之前的日子会非常难熬。有没有一个具体的、能被搜到的问题可以占住，是这个价位能不能成立的前提。

## 五美元这一档的成本红线

价位压到五美元，就意味着每个用户身上能花的钱很少。工具如果每次调用都要走服务端、要排队、要读数据库，月度开销很可能逼近甚至超过五美元，尤其当额度是"无限使用"的时候。

可行的做法是让主要计算留在客户端完成，服务端只留用量记账。这条路有现成例子：10015.io 的五十多个工具几乎全在浏览器里执行、极少请求服务端，它才敢把它们全部免费开放。客户端能吃掉的重活，用 [WebAssembly](/webassembly/) 模块实现最合适，压缩、哈希、图像批处理都属于这一类。

## 这套东西具体放在哪

订阅状态与用量就三张表：客户、权益、事件。放进 [SQLite](/sqlite/) 即可，写入是本机文件 IO，延迟在毫秒级，早期完全不必为它单独起一台数据库。

金额一律用定点数。五点九九之类的价格累加、按比例折算、跨币种换算，只要用原生浮点，迟早会在某个月的汇总里冒出尾差，交给 [decimal.js](/decimaljs/) 处理是这类系统的默认做法。

三张表之外再留一张每天的快照：把当天的在订人数与金额写进一张日表。三个月后想看留存曲线时，有没有这张日表的差别非常大——没有它只能回头推算，有它只是一个简单查询。

做这些事的投入很小，收益却集中在判断上：五美元的产品最怕的是不知道自己到底有没有在往前走，因为它每天的账面变化只有几十美元，凭感觉几乎分辨不出来。

至于该把靶子定在哪一档，看的是你能稳定弄到多少带着具体问题的人。三千美元那一档的要求其实很低——每月三十个人而已。

---

*数据来源：terrific.tools、Data Fetcher、Cloakist/Sotion、10015.io 数据来自创始人公开披露；Gusto、Shopify、Inch Calculator 流量为第三方估算；流失率与转化率为本文假设。*