折扣不是让利，是一次交换。换不到东西的折扣，就是降价。
一、一次看起来很成功的 LTD
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
顾行做一个桌面截图与标注工具，订阅 19 元一个月。产品做了两年，增长停滞，每月新增付费用户个位数。他试了一次终身买断（LTD）：399 元，限 100 份。
三天卖完，进账 39900 元。这是他做过最大的一笔单日收入。他在社区里发了战报，有人祝贺，也有人问「你以后靠什么活」。
半年后他算了一笔账：这 100 个人不再产生订阅收入，但仍在提需求、报兼容性问题、要求适配新系统。他每个月花在这 100 个人身上的支持时间，大约是 4 小时。按 60 元/小时算，一年 2880 元。
那 39900 元不是收入，是一笔预付款。
二、六类折扣，各自换什么
折扣只有在「换到东西」时才成立。常见六类：
| 折扣类型 | 幅度 | 换到什么 | 什么时候值得 |
|---|---|---|---|
| 年付折扣 | 约 17%（送 2 个月） | 提前锁定 12 个月现金流，降低流失 | 几乎总是值得 |
| 限时首发 | 30%–50% | 一批种子用户与反馈 | 产品还不成熟，需要真实使用数据 |
| 学生/教育 | 50% 或免费 | 口碑与未来的职场用户 | 产品有明确的职业迁移路径 |
| 开源/公益 | 免费 | 社区贡献、案例、信任 | 对品牌有正向作用 |
| 渠道专属 | 10%–20% | 渠道方的推荐位 | 渠道真的带来新用户，而不是老用户换路 |
| 终身买断 | 相当于 20–40 个月订阅费 | 一次性现金 + 一批「不会再付钱」的用户 | 仅限冷启动或产品进入维护期 |
前两类是定价结构，中间两类是品牌投入，后两类最容易被误用。
「渠道专属」的陷阱：如果折扣码在公开渠道流传，老用户会用折扣码重新订阅，你损失的是本来就会付的钱。判断方法是看折扣码带来的订单里，有多少是第一次出现的新邮箱。
更隐蔽的一种是「渠道自己打折」。合作方为了冲量，把你的折扣码贴到自己的公开页面，或者发给已经买过的用户。合同里要写清折扣码的使用范围，技术上要限制单账号只用一次。
首年折扣与年付折扣容易混淆：前者是「第一年便宜，之后恢复原价」，后者是「每年都便宜，换取一次付清」。前者的续费转化率通常很低，因为第二年的价格落差会触发取消；后者才是真正锁定现金流的结构。
「终身买断」的陷阱更隐蔽，因为它在账面上太好看了。
三、LTD 的五年账
把 399 元拆成订阅等价物：
回本点 = 399 ÷ 19 = 21 个月
也就是说，一个用户只要订阅满 21 个月，你就收到了同样的钱。而 LTD 用户的使用期是「永久」。
按五年算：
订阅用户 5 年收入 = 19 × 60 = 1140 元
LTD 用户 5 年收入 = 399 元
少收 = 1140 − 399 = 741 元
LTD 用户的五年成本
服务器与存储 = 0.2 × 60 = 12 元
支持 = 6 元/月 × 60 = 360 元
合计 = 372 元
五年净收入 = 399 − 372 = 27 元
五年赚 27 元。这还没算支付手续费、税费和退款。
关键变量是支持成本。如果产品足够简单、文档足够好，支持成本能降到 1 元/月：
支持 = 1 × 60 = 60 元
五年净收入 = 399 − 12 − 60 = 327 元
327 元仍然不如订阅的 1140 元，但至少不是白干。所以 LTD 能不能做，取决于一个问题：这个产品的支持成本会不会随着用户变老而下降？
工具类产品通常可以——用户熟悉之后问题变少。但需要适配外部变化的产品（对接平台 API、跟随系统升级、依赖第三方服务）不行，老用户会持续回来要求兼容。
如果决定做 LTD。 如果决定做 LTD，三个限制必须写在销售页上，而不是藏在条款里：
- 不含未来大版本。 写清「包含当前 2.x 版本及同主版本内的更新」，下一个大版本可以另行收费。
- 限量与限时。 写清份数与截止日期，卖完即止。不限量的 LTD 等于永久降价。
- 支持范围。 写清包含哪些支持（比如邮件支持、工作日回复），不包含什么（比如电话、定制开发）。
还有一条不写在条款里但必须自己记住：LTD 的用户会聚集。 他们是在同一个时间、因为同一个理由进来的，有相似的期待，也会在同一个社区里交流。一次处理不好，会变成一群人的共同抱怨。
LTD 的现金流也要看得更远一点。39900 元进账的那个月看起来很好，但接下来 12 个月这笔钱不会再出现。如果把 LTD 当成「收入」而不是「预付款」，很容易在第二个月安排一个按月度流水计算的支出，然后发现自己没有现金流。
一个可用的记账方式：把 LTD 收入按订阅等价期（这里是 21 个月）分摊，每月记 19 元。这样账面上的「月收入」才不会骗人。
LTD 还有三个替代方案，效果类似但风险更小：
- 长期折扣订阅：比如「一次付 3 年，七折」，既有现金流，又有到期日。
- 买断当前大版本：不含未来版本，老用户想升级再付一次。
- 限量创始会员：价格介于订阅与 LTD 之间，保留「早期支持者」的身份，但不承诺永久。
三者都在「一次性收钱」与「长期负担」之间取了中间值。
四、折扣的纪律
不管做哪种折扣，三条纪律：
第一，折扣码要有有效期与使用次数。 一个永不过期的折扣码，最终会出现在优惠券聚合站上。
第二，老用户不参与拉新折扣。 如果老用户看到新用户半价，会觉得自己被惩罚。技术上可以在结账时校验邮箱是否为历史付费用户。
第三，每次折扣只为一个目的。 为了清库存、为了拉新、为了测试价格弹性，三个目的不能用一个折扣同时完成。做完之后记录：带来多少新用户、其中多少在 30 天后还在、退款多少。
学生折扣还有一个执行细节：怎么验证。常见做法是要求教育邮箱，但教育邮箱可以买，也可以借。对单价不高的产品，验证成本不值得，直接给一个公开的折扣码更省事；对单价高的产品，要求上传学生证或走第三方验证。
开源与公益免费是另一类：它换的不是收入，是案例与信任。给之前要想清楚对方会不会公开使用、能不能写进案例；如果对方只是想要免费，那就不是这个类别。
五、行动清单与复算验收
- 列出自己正在用的所有折扣，逐个写下「换到了什么」
- 算一遍年付折扣的实际折扣率，确认它换来的是现金流而不是流失
- 如果做 LTD，先算出五年支持成本，再决定份数
- LTD 条款写清版本范围、限量与支持边界
- 折扣码设置有效期与次数上限
- 每季度复盘一次折扣带来的新用户与 30 天留存
验收标准：能说出每一种折扣换到了什么、LTD 的五年净收入是多少、折扣码有没有被非目标用户使用。 说不出交换物的折扣应当停掉。
使用边界与实操验收
本文不讨论平台内的促销工具与商店折扣节奏，游戏发行的折扣策略属于个人游戏发行定价：价格不是胆量测试，而是玩家预期管理 的话题；浏览器扩展的 LTD 与站外支付许可证属于浏览器扩展变现：买断、订阅、LTD 与站外支付的许可证设计 的话题。
本文也不主张 LTD 是坏东西。对进入维护期的产品，LTD 是一次合理的收尾；对刚上线、需要现金流和种子用户的产品，限量 LTD 也能成立。不成立的是「用 LTD 解决增长问题」——它买的是一次现金，不是持续增长。
验证以自己后台的订单记录为准：按折扣码分组，看每组的新用户占比、30 天留存与退款率。如果某个折扣码带来的订单里老用户超过 20%，说明这个折扣在给自己让利。
关键参考与核验范围
本文的价格、成本与折扣幅度均为教学演示。核验日期：2026-10-23。
- 中华人民共和国电子商务法 ：从经营者义务的角度看促销表述——「限时」「限量」「终身」之类的说法应当真实可履行，不能作为常规话术反复使用。
- 中华人民共和国个人信息保护法 ：从最小必要的角度看折扣校验——用邮箱判断是否为老用户时，不应额外收集与该判断无关的信息。
上述两条只用于说明合规取向，不构成法律意见。各平台对「终身」「永久」类表述的广告合规要求不同，本次核验未逐条比对，故不引用其条款原文、不附链接。
系列导航
- 上一篇：涨价：通知、老用户与过渡期
- 下一篇：结账页：币种、税费、失败重试与拒付
- 回到目录：一个人把价格定对：定价、付费墙与涨价
- 相关阅读：浏览器扩展变现：买断、订阅、LTD 与站外支付的许可证设计 、个人游戏发行定价：价格不是胆量测试，而是玩家预期管理
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。