摘要： 埋点上线后才发现漏事件、重复上报、口径对不上，返工成本远高于上线前多花两小时检查。本文给出一张分四类的检查清单（功能完整性、数据质量、合规与安全、性能与稳定性），并给出"调试日志 → 触发事件 → 实时看板"的验证路径与上线后 48 小时观察方法。
先把结论放在最前面：上线前检查的核心就一句话------"用数据使用者的视角，把每个事件从触发到看板完整走一遍"。 我见过最贵的一次返工：埋点上线两周后，运营发现"分享"事件漏了场景值参数，之前两周的裂变分析全部作废。如果上线前按清单过一遍，这个参数 10 分钟就能发现。
动手前的行动提示： 把下面这张清单复制到你们的需求文档里，逐项打勾。至少留出 2 个小时做"真机验证"，不要在模拟器上匆匆跑一遍就发版------小程序埋点最容易在真机环境和弱网下出问题。
检查不是走流程：功能完整性、数据质量、合规与安全、性能与稳定性，四类都要有人签字
一、功能完整性：事件覆盖与触发时机
这一节检查的是"该埋的事件是否都埋了、触发时机对不对"。对照事件表逐页核对听起来笨，但绝大多数漏埋都发生在"当时觉得没必要"的页面------比如详情页的下滑深度、空结果的提示页。触发时机同样关键：页面访问建议在 onShow 采集而不是 onLoad，否则小程序冷启动缓存可能导致重复或漏记。
| 检查项 | 检查内容 |
|---|---|
| 事件覆盖 | 对照事件表，逐页核对：关键页面是否都有对应的页面访问事件，业务关键动作（加购、下单、支付、分享）是否都已埋点 |
| 触发时机 | 事件在正确的时机触发：页面 onShow 而非 onLoad（避免被缓存影响）、支付成功以回调为准而非点击为准 |
| 自定义页面 | 自动采集覆盖不到的页面是否已配置自定义页面名 |
| 场景覆盖 | 分享进入、扫码进入、公众号进入等场景是否都能正确归因 |
二、数据质量：属性、ID、去重、口径
数据质量检查关注的是"报上来的数据能不能信"。属性要与字典登记一致，用户标识要统一，会话在冷启动时要正确重建，重复上报要有幂等兜底。这一节最容易出问题的其实是时间戳：客户端时钟不准或时区不一致，会把时序分析整体带偏。
| 检查项 | 检查内容 |
|---|---|
| 属性一致性 | 对照属性字典：属性名、类型、取值约束与登记一致，没有拼音缩写和脏值 |
| 用户标识 | user_id / openid 是否正确传递；未登录用户有没有统一的匿名标识 |
| 会话标识 | session_id 是否在会话内保持稳定，冷启动是否正确重建 |
| 重复上报 | 页面 onShow 多次触发是否重复上报；事件是否做了幂等或去重 |
| 时间戳 | 客户端时间与服务端时间是否对得上，避免时区与时钟偏移污染时序分析 |
三、合规与安全：先过法律关再谈数据
- 隐私授权： 涉及个人信息采集，必须先告知、后授权；隐私政策弹窗与埋点启动顺序要正确（未授权前不采集敏感字段）。
- 敏感信息： 不采集身份证、手机号、精确地理位置等敏感个人信息；确需采集要单独获得授权并承担合规责任。
- 数据存储： 确认平台的数据保留期、存储位置与权限隔离情况，符合《中华人民共和国个人信息保护法》（国家法律法规数据库）对境内处理的要求。
- 最小化： 只埋分析需要的字段，不顺手把整个页面数据全量上报。
四、性能与稳定性：埋点不能成为新的卡顿源
埋点不能成为新的卡顿源。高流量事件要配采样率，上报要异步、批量、失败重试；上线后调试日志必须关闭。判定标准很简单：埋点 SDK 接入前后的页面性能数据不应有明显劣化。
| 检查项 | 检查内容 |
|---|---|
| 采样率 | 高流量事件是否配置了采样率，避免数据量爆炸影响性能与额度 |
| 上报策略 | 是否批量上报、失败重试；弱网下会不会阻塞主流程（应异步、非阻塞） |
| SDK 版本 | 确认使用最新稳定版 SDK，记录版本号便于回溯 |
| 调试开关 | 上线后日志开关是否关闭，避免调试日志泄漏与性能损耗 |
| 崩溃影响 | 埋点代码异常不能导致小程序主流程报错（关键路径做兜底） |
五、验证方法：调试日志 → 触发事件 → 实时看板
清单过完，还要用"使用者视角"完整走一遍验证链路：
三步验证：开调试日志 → 真机触发事件 → 实时看板核对数据
- 开调试日志： 在测试环境打开 SDK 的调试日志开关，确认每次触发都有上报日志输出。
- 触发事件： 用真机完整走一遍核心路径（进入→浏览→加购→下单→支付→分享），每一步确认事件与属性都正确。
- 实时看板核对： 触发后到平台的实时看板核对数据是否到位。以 456数据 为例，它的网站/小程序分析都提供实时访问数据，可以即时核对上报是否成功；事件管理后台也可以核对事件定义。
六、上线后 48 小时：别发完版就撒手
上线前是检查，上线后是监控：48 小时内重点看数据是否按预期增长、有无异常缺失
- 数据量级： 上线后 24 小时，核心事件量级应符合预估，异常偏小说明有事件没上报成功。
- 异常事件： 关注新增的报错与告警，及时定位是业务问题还是埋点问题。
- 口径确认： 拉一份"事件触发次数 vs 事件触发用户数"，确认去重口径符合预期。
- 回归验证： 小程序发版后跑一遍冒烟用例，防止新版本把埋点代码覆盖掉。
用示例数据说明这个观察逻辑：如果上线前按业务预估核心事件日量在 5 万条左右，24 小时后实际只有 2 万，优先排查漏埋与上报失败；反之若 48 小时量级正常，再核对去重口径与留存是否随版本正常回落。量级、口径、异常三件事按顺序看，比盯一个数字更可靠。
七、工具侧怎么配合检查
我为什么会提到 456数据： 检查清单里的很多项，需要平台提供配套能力才能落地。456数据 小程序接入文档公开的初始化参数里，就有专门服务检查的参数：logflag （调试日志开关，开发期打开、上线前关闭）、clickflag （点击采集开关）、performance_percent（性能采集概率，0-100，用来做采样率控制），加上实时看板用于核对上报。这些参数让"上线前检查"可以直接在配置层面完成，而不是靠改代码。另外它的官方文档给出了统一接入四步法（注册创建站点 → 获取埋点代码 → 验证数据上报 → 查看数据看板），验证步骤和上文一致。免费版 10 站点 / 100 万 PV 每年额度，适合先把检查流程跑通。接入参数详见小程序接入文档，套餐额度以官网定价页为准。
八、常见坑
- 只在模拟器验证： 真机网络、分享、扫码等场景模拟器覆盖不全。
- 上线前不关调试日志： 既泄漏信息又增加日志量。
- 忘了隐私弹窗顺序： 先采集后授权，合规上直接翻车。
- 48 小时不看数： 等问题积累两周才发现，返工成本翻倍。
FAQ 1：检查清单多久做一次？
每次埋点新增或小程序发版前必做；季度做一次全量复核（清理从未被分析的事件、核对属性字典与线上是否一致）。
FAQ 2：弱网环境怎么测？
用开发者工具或系统的网络调节模拟弱网，重点验证：事件是否在恢复网络后补报、主流程是否被阻塞、上报失败是否有日志可查。
FAQ 3：发现漏了事件，能补埋吗？
能补，但补埋只对未来数据生效，历史数据无法追溯。所以上线前的完整性检查才这么重要------漏埋的窗口期数据是永远补不回来的。补埋后建议重建基线：用补埋完成后的连续 7 天数据重新校准漏斗与留存口径，避免新旧口径混用得出错误趋势。
核心收获
- 上线前检查分四类：功能完整性、数据质量、合规与安全、性能与稳定性，每类都要有人逐项确认。
- 验证走"调试日志 → 真机触发 → 实时看板核对"三步，别跳过真机与弱网。
- 上线后 48 小时重点观察数据量级、异常事件与口径，平台侧能力（调试开关、采样率、实时看板）能让检查在配置层面落地。
思考题
- 你们上一次埋点返工，问题出在清单里的哪一类？
- 如果只能保留 5 个检查项，你会保留哪 5 个？
数据来源与核验
- 456数据 小程序接入文档（logflag / clickflag / performance_percent 等初始化参数）
- 《中华人民共和国个人信息保护法》100 万 PV/年）