埋点方案是什么？

埋点方案里写什么

每个事件，一份有用的方案会写清楚：

• 事件名，和代码里发送的一字不差，再加一个看得懂的显示名。
• 触发时机——用大白话写：“支付渠道确认订单成功之后”，而不是“点击时”。
• 属性——类型、是否必填、示例值。
• 端——网页、iOS、Android、小程序、服务端。
• 负责人和开发——谁定义它的含义，谁来实现。
• 状态——它走到了生命周期的哪一步。

一个事件的一生

事件会经过几个阶段，方案里应该看得出每个事件在哪一步：

• 已提出——有人需要，还没排期。
• 开发中——正在实现。
• 验收中——数据已经在上报，正在检查必填属性有没有填上。
• 已上线——验证过，可以放心用在报表里。
• 已废弃——不再采集，保留历史。

“验收中”是多数团队会跳过的一步，坏数据也大多出在这里：一个事件在发，但没带 value 属性，直到有人要汇总收入才发现。

TapCub 里的埋点方案

TapCub 把埋点方案放在控制台里，和事件定义双向关联。可以从已采集的事件或行业包生成，从 CSV 或 JSON 导入，导出成表格，并让每一项按上面五个状态推进。

实时验收会给每个计划中的事件显示最近 24 小时的上报次数和必填属性覆盖率，“验收中”成了一项检查，而不是凭感觉。通过 track() 上报、却不在事件定义里的事件名，会列为“计划外事件”——拼写不一致的变体就是在这里被发现的，不用等它们出现在看板上。

埋点方案要靠统一的事件命名才站得住，规则和示例见事件命名规范。

常见误区

• 一张没人更新的表格。和真实数据脱节的方案，几周就会走样。要把它和实际采集的数据连起来。
• 触发时机写成点击。“点了购买”和“订单已支付”是两个事件，数量也不一样。
• 没有负责人。没人能说清一个事件能不能改名、能不能删。
• 跳过废弃这一步。直接删事件会悄悄弄坏旧看板，先标记为废弃。

延伸阅读：事件埋点怎么做、网站统计实践指南和网站统计审计。另见追踪自定义事件。

相关阅读

• 数据分类体系：命名规则和一次整理的例子
• 制定埋点方案

另见：什么是数据类型？编程、统计和埋点里的例子。