试用用户没有付费，团队该先查哪三段数据

假设一个团队月底复盘：14 天试用注册量没有明显下降，付费人数却低于预期。会议很快会出现三种建议——缩短试用期、要求先绑卡、到期前增加优惠提醒。每一种都可能有效，也可能改错位置，因为“试用转付费率”把几段完全不同的用户行为压成了一个数字。

用户从注册走到首笔付款，至少要完成三件事：先用产品解决一次真实问题，再遇到值得付费解除的限制，最后看懂套餐并完成支付。团队如果不知道人停在哪一步，试用期和折扣只会改变表面数字。能指导下一步的诊断，要把转付费分成激活、升级触发和首次支付三段。

一条转付费率，掩盖了三种不同的流失

ChartMogul 与 ProductLed 的 2026 年报告分析了 200 个 B2B 软件产品，样本的免费转付费中位数是 8%，实际分布却很散：有些产品低于 2.5%，也有一部分高于 25%。报告显示，几乎没有一个“正常值”能直接告诉团队哪里出了问题。

同一份报告把网站访客也放进漏斗后，结论又发生了变化。要求绑卡的试用末端转化更高，进入试用的人数却更少；免费增值的末端转化较低，入口人数更大。只拿“开始试用的人里有多少付费”作比较，会把获客量和筛选强度一起漏掉。

三段应分别建立数据口径和问题清单。激活看注册者有没有完成一次能体现产品价值的行为，以及这件事花了多久；升级触发看已激活用户有没有遇到与当前工作直接相关的功能或用量限制；首次支付看付费墙触达、套餐选择、结算发起和付款成功。三段落在不同位置，不能共享一个模糊的“转化优化”项目。

RevenueCat 对 Android 订阅漏斗的拆解提供了一个清楚的例子。其 2026 年大样本显示，Android 从下载到付费的中位转化明显低于 iOS；把入口拆开以后，两边从试用到付费的中位数几乎相同。作者同时提醒，Android 的试用人群可能经过更强筛选。总差距可能发生在进入试用前，末端转化率相近也不能证明两条漏斗相同。

用户没有完成核心行为，试用期只是在倒计时

激活要落到产品里的具体行为。报表工具可能把“导入一份真实数据并保存第一张图”作为激活事件；协作产品可能选择“创建项目、邀请同事并完成第一次共同编辑”。打开应用、浏览功能页或收到欢迎邮件只能证明用户来过，还没有证明他得到价值。

Amplitude 对试用数据的说明把激活率和激活所需时间分开：前者看有多少注册者完成关键事件，后者看这件事发生得多快。两个产品拥有相同激活率，其中一个多数用户在第一天完成，另一个拖到试用结束前才完成，后者留给理解高级功能和做购买决定的时间更少。

Intercom 也公开复盘过类似过程。团队早期只看 trial-to-paid、MRR 等经营数据，后来为 Articles 产品补充了“使用意图—首次得到价值—持续使用”三个节点。Beta 用户行为显示，从开始创建内容到发布给客户查看所需时间过长，团队据此简化产品；Intercom 的复盘称，上线时激活时间得到改善，试用转付费也出现正向变化，但没有公开具体幅度。

当断点落在这一段，团队先定义价值行为，再比较留存者与流失者怎样走到它。新用户激活与留存工具能整理真实行为数据、现有注册流程和触发邮件，输出激活口径与首次体验改版方案。它以真实漏斗为输入，一份通用 onboarding 清单无法判断用户为何流失。

用户已经看到价值，升级理由也要在同一条路径里出现

完成激活以后，用户仍可能缺少付费理由。免费层已经覆盖了他的全部工作，高级功能和当前需求无关，付费墙只解释“七天后扣款”，都会让购买停下来。这里要检查的对象从“用户会不会用”变成“继续完成当前工作何时必须升级”。

Stripe 的 PLG 定价指南把升级触发分成功能限制和用量限制。高级权限、审计日志适合在团队规模扩大时出现；项目数、存储量或 API 调用量适合在使用增长时形成上限。触发点要落在用户已经信任产品之后。用户还没有完成第一次工作就被拦住，看到的只是一道收费门。

付费墙的内容也要接住刚才的行为。用户准备导出报告时，页面应说明升级后能导出什么、适合哪个套餐、怎样继续当前工作；群发“试用即将结束”无法提供这些上下文。Intercom 的官方示例建议按已经发生或尚未发生的行为触发消息，例如只提醒注册多日却从未使用导出功能的人，并把功能价值和下一步放在同一条消息里。这是产品使用建议，页面没有提供折扣必然提高转化的证据。

团队已经知道用户在哪个行为前停住时，应用内付费墙工具能把触发场景、现有页面和展示数据整理成页面结构、文案与 A/B 测试变量。测试还要保留退出方式和触发频率，避免靠隐藏取消入口制造短期付款。

公开自述案例提醒：渠道变化会改写转付费率

2026 年 7 月，一位独立开发者在 Reddit 公开复盘自己的 iOS 健身应用。作者自报，5 月下旬的整体试用转付费率为 20.7%，最近四个已经结算的周 cohort 合计为 46/104。

这轮复盘同时涉及多项变化：重新把两个 Pro 功能放回付费层、测试新的付费墙、修复漏记约 80% 实际转化的埋点、按照片数量分析试用意愿、增加历史照片导入，并在 onboarding 中预览高级功能。作者还发现，欢迎付费墙曾在一次代码改动中被误删，新用户看到付费墙的比例随之下降。这些发现把埋点、免费层、激活行为和付费墙放进了同一轮诊断，无法给任何单项改动确认因果。

原帖给出的限制比增长数字更重要。改善从 5 月 31 日 cohort 开始，早于部分产品改动；作者认为，5 月中旬停止付费投放、让试用重新以高意向自然流量为主，可能贡献最大。每周 cohort 只有 24—30 次试用，付费墙 A/B 的胜出概率为 88.9%，当时尚未达到统计显著；一项针对 onboarding 的实验也没有降低约 42% 的放弃率。

这段公开自述能支持一个收窄后的结论：先查清埋点、渠道构成和 cohort，再挑选一个断点运行实验。渠道带来的人群改变了，产品页面的前后对比也会混入选择效应；埋点或观察窗口有误，改动前后的基线也站不住。

试用长度和绑卡方式，要放回完整漏斗比较

试用长度常被当作最容易修改的按钮。RevenueCat 的 2026 订阅应用报告显示，17—32 天试用的试用转付费中位数为 42.5%，4 天以内为 25.5%；短试用的取消也更集中在第 0 天。这个数据来自订阅应用，品类、地区和获客方式差异很大，相关关系也不能单独证明延长试用会带来提升。

判断自己的试用时长，先看“激活时间分布”。大多数高意向用户第一天就激活，剩余时间只是在等待到期，缩短试用可能提高回款速度。用户要导入资料、邀请团队或等待一个业务周期才能看到价值，短试用会在价值出现前结束。长度应覆盖合理的价值兑现时间，并给购买、审批和付款留出空间。

绑卡也要同时看入口和末端。ChartMogul 的 B2B 样本中，绑卡试用的末端转化明显更高，进入试用的人数更少。团队应比较每一千名合格访客最终带来多少新付费客户、首月退款和后续留存，不能只庆祝试用转付费率上升。

如果用户已经激活、看过付费墙，却始终选不出套餐，问题进入价值口径和套餐结构。此时可用SaaS 定价与套餐设计工具把现有 ARPU、转化率、客户价格反馈和套餐功能整理成价值口径与套餐矩阵。缺少这些输入时，竞品价格只能提供参照，无法替团队决定收费方式。

下一轮实验，只改一个断点并保留 cohort

团队先从一张按注册周和渠道拆分的表开始。每个 cohort 记录四组人数：进入试用、完成激活、看到升级触发、首笔付款成功；旁边再记录激活所需时间、付费墙触发行为、套餐选择、支付失败、退款和首次续费。所有数据先写清分母和观察窗口，避免把尚未走完试用期的新用户与已经结算的人混在一起。

接下来只选择掉幅最大的一段。激活率低，就减少到达价值行为前的步骤；激活正常、付费墙触达低，就检查免费层和升级触发；付费墙触达正常、支付低，再研究套餐、价格、结算错误和审批需求。一次实验只改变一个主要变量，并保留原 cohort，团队才知道变化发生在哪一段。

试用转付费率适合向管理层描述结果，无法独自安排产品、增长和商业化团队的工作。当激活、升级触发和首次支付都能分别回答“多少人、花多久、停在哪、为什么”，下一轮改动才有明确对象。