SaaS 定价踩坑记：几种模型和常见错误

定价是独立开发者最头疼的事之一。产品做了三个月，到了要收钱的时候，盯着定价页面发呆——$9 还是 $19？免费版给多少功能？要不要按用量计费？

这篇不是给你一个「正确答案」——因为不存在适用于所有产品的万能价格。但有一些常见的模型、被验证过的策略、以及反复被踩的坑，了解它们能帮你少走弯路。

常见的定价模型

按月/年订阅（Flat-rate Subscription）

最经典的 SaaS 定价方式：每月或每年收一个固定金额，用户获得完整的产品使用权。

典型价格段（面向个人用户的工具类 SaaS）：

• $5-9/月：轻量工具、单一功能
• $10-29/月：中等复杂度工具、多功能
• $30-99/月：专业工具、团队功能
• $100+/月：企业级、或价值链上关键环节

优点： 收入可预测、用户理解简单、LTV 容易计算。

缺点： 对轻度用户来说可能「太贵了」，对重度用户来说可能「太便宜了」。一刀切的价格很难完美匹配所有用户的支付意愿。

免费增值（Freemium）

给一个免费版（功能受限或有用量上限），然后靠一部分用户升级付费版赚钱。

免费版的目的不是做慈善，是获客。 通过降低试用门槛，让更多人进来体验产品，其中一部分转化为付费用户。

关键指标： 免费到付费的转化率。行业基准大约 2%-5%。也就是说 100 个免费用户里有 2-5 个最终付费。如果你的转化率低于 1%，说明免费版给的太多了（用户不需要升级）或者付费版的价值感不够。

免费版给多少功能的判断标准：

• 免费版要让用户感受到产品的核心价值（不然他根本不会留下来）
• 但要在用户需要「更多」的时候碰到付费墙
• 常见的限制方式：用量上限（每月 100 次）、功能门控（高级功能付费）、人数限制（1 人免费，多人付费）

按用量计费（Usage-based / Pay-as-you-go）

用多少付多少。API 产品用得最多——按 API 调用次数、token 消耗、存储量、带宽来计费。

例子：

• OpenAI API：按 token 计费
• AWS / Vercel / Supabase：按请求数 + 存储 + 带宽
• Twilio：按短信 / 通话时长

优点： 对用户公平（用多少付多少），大客户自然付得多，收入天花板高。

缺点： 用户无法预测月度账单（对个人用户是负面体验），收入波动大，用户可能因为「怕超额」而压制使用。

对独立开发者的建议： 纯按用量计费适合 API 产品和开发者工具。如果是面向终端用户的 SaaS，更好的方式是「订阅 + 用量上限」组合——$19/月包含 1000 次调用，超出部分每次 $0.01。

一次性买断（Lifetime Deal / One-time Purchase）

用户付一次钱，永久使用。

什么时候适合买断：

• 桌面软件（安装在本地，不依赖你的服务器运行）
• 工具类产品（功能稳定，不需要频繁更新）
• 早期获客阶段（用 LTD 快速积累第一批用户和现金流）

什么时候不适合买断：

• 有持续服务器成本的产品（每个用户每月消耗你 $X 的服务器资源）
• 需要持续迭代更新的产品（长期维护没有对应收入）
• 如果你指望稳定的 MRR（月经常性收入）

Lifetime Deal 的坑： 很多独立开发者在产品早期做 LTD（比如在 AppSumo 上卖 $49 终身版），确实能快速回笼几万美金。但问题是——这些用户之后永远不会再付钱给你，而你需要一直给他们提供服务和技术支持。当用户基数大了，支持成本会压垮你。

如果要做 LTD，建议限量（只卖 500 份），明确 LTD 包含什么版本的功能（后续新功能不一定包含），或者设置合理的使用量上限。

混合模型

现实中大多数成功的 SaaS 都不是纯用一种模型，而是混合：

• Freemium + 订阅： 免费版 + Pro $19/月 + Team $49/月
• 订阅 + 用量： 基础版 $9/月含 100 次调用，超出按量付费
• 订阅 + 增值： 基础功能订阅，高级功能单独购买

定价锚点设计

定价页不是只放一个价格的。多数 SaaS 的定价页有 3 个方案（Plan），这不是随便设计的——它利用了「锚点效应」。

三档定价的标准套路

关键： 中价档和高价档的价格差距要让用户觉得「中价档性价比最高」。如果三档是 $9 / $19 / $99，大部分人会选 $19——因为对比 $99 它太划算了，而对比 $9 它功能多了不少。

年付 vs 月付

行业惯例： 年付比月付便宜 15%-25%。比如月付 $19/月，年付 $15/月（省 21%）。

年付的好处：

• 对你：预收一年的钱，现金流好，用户 churn 率低（已经付了一年不容易退）
• 对用户：省钱

比例： 成熟的 SaaS 产品年付用户通常占 30%-50%。如果你的年付比例低于 20%，可能是折扣力度不够，或者用户对产品的长期信任不足。

定价调研怎么做

不要凭感觉定价。花半天做个简单的调研：

1. 看竞品定价

列出 3-5 个和你产品最像的竞品，记录它们的：

• 定价档位和价格
• 每个档位包含什么功能
• 是否有免费版
• 用量限制设在哪里

你的定价不需要和竞品一样，但要知道用户的价格预期在什么范围。如果竞品都定 $9-19/月，你上来定 $49/月，用户转化率会很低——除非你能清楚证明贵在哪里。

2. 算你的成本底线

你的定价至少要覆盖：

• 每个用户的边际服务器成本
• Stripe 手续费（2.9% + $0.30）
• 你的时间成本（客服、维护、迭代）

如果每个用户每月消耗你 $2 的服务器成本，Stripe 扣 $1，那你的定价至少要 $5-6 才不亏钱。考虑到不是所有免费用户都会付费、考虑到 churn，实际定价应该远高于成本底线。

3. 用户愿付价格测试

最简单的方式：发一个 survey 问两个问题（Van Westendorp 价格敏感度测试的简化版）：

• "你觉得这个产品值多少钱/月？"
• "超过多少钱/月你肯定不会买？"

收集 30-50 个回复就能看到一个大致范围。

独立开发者最常见的定价错误

错误一：定价太低

这是最常见的错误。 独立开发者倾向于低估自己产品的价值，觉得 "我一个人做的小工具怎么好意思收 $29/月"。

现实是： 如果你的产品能帮用户每天省 30 分钟，$29/月对他们来说太便宜了。

低价的隐性代价：

• 吸引来的是价格敏感用户——这些用户退款率高、支持需求多、忠诚度低
• 收入低 → 没钱做营销 → 增长慢 → 做不下去
• 后续涨价困难（已有用户会反感）

建议： 第一版定价先往高了定，然后通过转化率数据来判断是否需要降。定高了可以打折（用户高兴），定低了再涨价（用户不高兴）。

错误二：免费版给太多

Freemium 的免费版如果太好用，用户永远不需要升级。

判断标准： 如果你的免费用户活跃度很高但付费转化率低于 1%，说明免费版太香了。需要收紧限制——要么减少免费用量，要么把某个关键功能移到付费版。

错误三：只有一个价格档

只放一个价格 = 放弃了所有价格歧视的机会。

有些用户愿意付 $9，有些愿意付 $49。如果你只有一个 $19 的档位，你既丢了 $9 用户（他们觉得贵不买），也少赚了 $49 用户的钱（他们本来愿意付更多）。

最少要有两档，推荐三档。

错误四：把定价当成一次性的事

定价不是设定好就不动了。它应该跟着产品迭代、用户反馈和市场变化持续调整。

好的节奏：

• 产品上线时：设一个初始价格
• 3 个月后：看数据（转化率、churn、用户反馈），做第一次调整
• 之后每 6-12 个月 review 一次

错误五：涨价不沟通

涨价本身不是问题——你的产品在变好，价格理应上涨。但涨价方式决定了用户是理解还是反感。

涨价的正确方式：

• 提前 30 天通知现有用户
• 说清楚为什么涨价（新功能、成本上升）
• 给老用户一个优惠（锁定旧价格 3-6 个月，或者永久 grandfather pricing）
• 不要偷偷涨——用户发现了会更生气

一些参考数据

这些是面向全球英语用户的参考价格。如果你的目标市场是发展中国家（东南亚、印度、拉美），价格通常需要下调 30%-60%——可以用购买力平价（PPP）折扣来实现区域差异化定价。

实际操作建议

如果你的产品还没定过价：

1. 看 3-5 个竞品的定价，确定用户的价格预期区间
2. 算你的成本底线
3. 定三档价格，中档定在竞品价格的中位数附近
4. 先不做免费版（或者只做 7 天免费试用），观察付费转化率
5. 上线后根据数据调整——转化率 > 5% 说明太便宜了，< 1% 说明太贵了

不要在定价上纠结太久。一个不完美的价格比没有价格好。 先上线，然后用真实数据来迭代。

相关阅读：Stripe 和 PayPal 之外的收款工具 · AdSense 的前世今生