微信小程序事件上报教程｜自定义事件命名与采样｜漏斗数据不再打架 – MPForge

一、先把漏斗画出来，再谈埋点

结论先立住：事件上报是给转化漏斗服务的，不是把每个按钮都报一遍。周会上吵「数对不对」，十有八九是埋点阶段就没定口径：曝光算不算滑出半屏、点击算不算重复点、提交算不算校验失败。正确的顺序是先把业务漏斗画成四段——曝光→点击→提交→成功/失败，每一段只对应一个事件，事件里带参数区分细节。运营看漏斗哪一段掉人，开发看参数里哪类错误多，两边读的是同一组数。做埋点方案前可以先对照 数据埋点最低集 划边界，别让「先都报上再说」变成后续改看板的枷锁。

明确不做的两件事：页面每个按钮都报一个事件；用中文短语加空格当事件名。前者会把看板撑到没法读，后者会让事件名在不同版本间漂移，跨周对比直接失效。

二、命名规范：模块_动作_结果，一次锁死

命名是埋点里最便宜却最常翻车的环节，规则定了就不许现场发挥。我们用「模块_动作_结果」三段式，英文蛇形命名，例如 booking_submit_ok、booking_submit_fail。字典表随代码进仓库 README 维护，新增或改名事件走变更单，谁改谁登记。这样三个月后回看数据，还能对上「这个事件当初是干什么的」。命名漂移的代价很实际：同一行为两个名字，看板曲线断成两截，季度数据没法比。

三、采样与降级：大促前必须先演练

全量上报不是义务，撑不住才是事故。低频核心事件（预约提交、支付、核销）全量报；高频行为（页面停留、滚动曝光）按比例采样，大促前把采样率写进变更单。比采样更容易被忽略的是失败路径：支付失败、授权拒绝、核销超时这些事件如果缺失，客诉来了你只有结果没有过程。试点项目上线首周的值班就覆盖支付、核销、授权三类突发，排查全靠失败事件里的错误码。参数设计参考 性能数据上报 与 应用级事件 的口径，别在事件里塞用户手机号这类敏感字段，导出与存储另见 数据导出合规。

四、落地步骤：从漏斗到看板五步走

顺序不能乱：先漏斗、再字典、后上线，最后才接看板。按这五步执行：

1. 画漏斗定事件：把业务主路径写成曝光、点击、提交、成功/失败四段，每段定一个事件名，运营与开发当场确认口径。
2. 建字典入仓库：事件名、参数、触发时机、负责人写成字典表，随代码提交，改名走变更单。
3. 补失败路径：每个关键事件配一个失败事件，带错误码；三条异常路径（弱网、拒权、支付取消）必须在提审前用例里验证上报到位。
4. 定采样策略：核心事件全量，高频事件采样，大促前评审采样率与容量，避免活动当天上报通道被打满。
5. 接看板验收：看板只挂核心事件加诊断事件，用 数据看板周报 的口径出周报，渠道维度对照 渠道报表周刊 复盘。

五、避坑清单

这三条坑都出在「口径」两个字上：多端重复、失败缺码、大促无采样。

• 别让多端重复报污染数据：同一笔预约在用户端和店长端都触发上报时，必须带端标识，看板侧去重；否则漏斗人数虚高。
• 别只报成功：失败事件没有错误码，等于把排查成本留给值班同事；错误码表与用户提示文案同步维护。
• 别在大促前才想起采样：采样率调整要提前演练，临时改参数没人验证过，当天最容易翻车。
• 别用事件上报替代排障日志：事件进分析看板，日志进排障系统，工具分工见 日志管理器，混用两边都做不好。

六、常见问题 FAQ