WebFunny 埋点实战：看清用户的付款路径与留存

老板在季度会上连问三个问题：用户在付款的哪一步流失了？付过款的人多久会回来复购？哪个渠道带来的用户最值钱？——后台只有订单结果数据，过程全靠猜。于是立项做埋点，选了开源的 WebFunny 自建监控。这篇记录从业务设计到落地的全过程，个人认为最有价值的部分是前面的埋点设计，工具反而是最简单的环节。

为什么自建

看过 Sentry 和几家国产 SaaS，放弃的原因很具体：一是付款行为数据属于核心敏感数据，全量出境过不了安全评审；二是做留存分析必须把埋点明细和内部 userId 打通，SaaS 方案拿不到原始明细；三是配额，免费版月事件量不够，付费一年大几万。WebFunny 开源、部署在自己服务器、MySQL 存储，三条全满足。

埋点设计：付款路径 + 留存（本文核心）

付款路径漏斗，六个节点一个不多一个不少，每个事件必须对应路径上的一个真实决策点：

view_product   商品详情页曝光
add_cart       加入购物车 / 立即购买
start_order    进入订单确认页
choose_pay     选择支付方式
pay_submit     提交支付
pay_success    支付成功

所有事件带统一维度参数：渠道来源、终端类型、会员等级、金额区间。维度必须从第一天就统一，否则后面想按渠道切漏斗时发现早期数据没带，悔之晚矣。

留存口径，埋点之前就定好，不然数据对不上：匿名用户用设备 ID，登录后绑定 userId 打通两端；以"首次访问"和"首次购买"两个时间锚点，计算次日/7日/30日留存，以及复购间隔分布（两次下单之间隔几天）。渠道价值 = 渠道维度的留存曲线 × 客单价，光看注册量会被渠道商骗。

接入

WebFunny 分探针（probe）和监控端（monitor）两个服务，docker-compose 一键部署。前端入口初始化探针，错误监控、性能、行为轨迹全自动采集；业务事件手动埋：

import wxKalend from '@webfunny/track-js'

wxKalend.init({
  projectId: 'xxxxxxxx',
  trackUrl: 'https://monitor.internal.example.com:8010',
  performanceUrl: '...',
  jsErrorUrl: '...',
})

// 付款路径事件
wxKalend.track('choose_pay', { channel, device, vipLevel, amountRange, payType })

上线后的三个发现

• 漏斗卡点：choose_pay → pay_submit 环节流失 23%，远高于其他环节。抽样流失用户的行为链路（WebFunny 能回放报错前的完整操作轨迹），发现某银行支付渠道拉起后白屏，错误监控里同步有对应的 JS 报错。推动渠道方修复后，该环节流失降到 8%
• 留存真相：全站次日留存 31%，但完成首单用户的 30 日复购率 42%。结论：促复购的 ROI 远高于拉新，运营预算据此调整了方向
• 渠道去水：某信息流渠道注册量全场第一，7 日留存 9%，客单价垫底——按"注册量"结算是被薅了，按有效留存重新谈了结算口径

踩坑记录

• pay_success 不能只信前端：前端事件本质是"支付意向"，真正成功以后端回调为准。我们由后端在支付回调里补发埋点修正最后一环，否则漏斗终点虚高，全部结论都会偏
• 金额脱敏：埋点不传明文金额，传区间（0-50/50-200/200+），安全评审硬性要求
• 数据膨胀：日千万级事件，MySQL 一个月 40G。埋点库单独实例 + 自动清理，别和业务库混部
• 埋点进 review：出过参数名拼错导致报表对不上的事故，之后埋点变更必须过 code review

小结：埋点系统要回答的不是"发生了什么"（后台报表就有），是"为什么"（哪一步流失、卡在哪）和"值不值"（渠道价值、复购 ROI）。设计埋点时先写清楚要回答的问题，再倒推事件和参数，顺序反了就是白埋。