收入归因
付费用户从哪个渠道来？
适合做渠道和投放决策，但不解释用户在付费墙前具体卡在哪里。
付费墙转化闭环
把付费时的犹豫变成可验证的实付增长。
在定价或结账时只问一句。MorePaying 按钱排出最贵的阻碍，把下一项修改交给编程 agent，再核对这个部署 SHA 上线后到底多收了多少钱。
免费 · 不绑卡 · 一行脚本 · 不交 Stripe 密钥
已经装在真实付费墙上
同一张问一句的卡片已经装在六家会收款的站上。演示板上的钱仍是种子，不是这六家的实付。
跑一遍 60 秒演示
第一张 4K 已经出好。留下来要付费。点「不升级」。
免费版 · 还剩 12 / 50 额度
$20 / 月
第一张 4K 已经出好。留下来要付费。
这块板
你选的原因几秒内会出现在这里。
转化
打开公开板答完那一题，卡片会出现在这里。
用户为什么不付费：安装站真实报上来的原因
下面每一条都来自真实付费墙上的定价退出回答，不是问卷样本，也不是演示数据。
- Free plan is enough
- 10 · 26%
- Price
- 10 · 26%
- First result wasn't good enough
- 5 · 13%
- I need video, not images
- 3 · 8%
6 个线上付费墙 · 1227 次打开定价 · 38 条回答
安装站实时汇总，不含演示看板的种子数据。
什么是付费墙归因？
付费墙归因只回答一个带金额的问题：定价页上哪一个异议最贵，你上线的修改有没有把它挪动。它把一次打开定价、用户选的原因、他带进来的套餐和渠道、以及他差点付的金额放进同一行。有了这一行，阻碍才能按钱排序，而不是所有异议一起平躺在反馈收件箱里。
它和分析工具、反馈工具做的不是同一件事。分析告诉你掉在哪一步，反馈工具收集用户说了什么。付费墙归因在两者之后继续往下走：最贵的阻碍变成编程 agent 的工作项，带着记录下来的发布 SHA 上线，再回到这次发布后 7、14、30 天的实付数据里核对。
真正把它和又一块看板区分开的，是那一步实付核对。基线锁定之后没有出现过的新付费用户标识出现之前，定价页的改动都只是假设。MorePaying 把基线和发布 SHA 跟结果放在一起，让人分得清是真的增长，还是这一周运气好。
一个闭环，四份证据
从犹豫，到能核对的结果
别停在看板。先抓住阻碍，算出影响，上线一个改动，再检查这次准确发布有没有带来更多付费。
抓住
就在定价或结账时问，购买决定还新鲜。
353
次打开定价 · 31 条原因
111 次没有升级
排序
把回答和套餐、用量、渠道、挡住的钱绑起来。
$2,400
挡住
第一次结果不够好
上线
让编程 agent 领取价值最高的阻碍，并记录发布 SHA。
deadbeef
发布
Cancel reason is a hypothesis only. Compared Stripe + job log; user was cycling credits.
验证
看 7、14、30 天实付变化，而不是一部署就宣布胜利。
等待 7 天验证
已验证增长
看 7、14、30 天实付变化，而不是一部署就宣布胜利。
演示数据与六个真实安装站严格分开。
不是三选一的拼盘
分析告诉你从哪来，反馈告诉你说了什么，MorePaying 证明该改什么。
缺的不是又一张图，而是把一个购买异议变成有金额排序的工程决策，再变成能核对的收入结果。
上下文反馈
用户具体报告了什么？
适合收产品反馈和 Bug 上下文，但默认优先级不是挡住了多少钱。
MorePaying
哪个异议最贵、下一步改什么、上线后是否有效？
为什么 × 上下文 × 渠道 × 金额 × 部署 SHA × 实付增长，一条闭环。
敢装在真实结账前
拿到收入证据，不把钥匙交出去
- 浏览器和 widget 里不放 Stripe 密钥
- 登录用户使用短时身份 token
- 网络请求有边界，失败可降级为匿名演示
- AI 服务不可用时仍保留模板分诊
安装
一行脚本。他们离开付费墙时再问。
<script src="https://morepaying.com/widget.js"></script>
<script>
MorePaying.init({
projectKey: "mp_proj_YOUR_KEY",
apiBase: "https://morepaying.com"
})
MorePaying.identify({ userId, plan, creditsRemaining })
MorePaying.track("pricing_view")
MorePaying.track("pricing_exit") // when they do not pay
</script>