埋点方案怎么做：事件、属性与验收模板

埋点方案不是“把所有点击记下来”，而是把业务问题翻译成可采集、可验证的事件与属性。一份可用的方案应说明：为什么采、何时触发、叫什么、带哪些属性、怎样验收。先定问题，再写代码，后续漏斗和留存才不会反复返工。

第一步：先写要回答的问题

埋点设计应从决策问题开始。问题越具体，事件越容易收敛。例如“注册为什么少”太宽；“访问注册页的用户在哪一步流失”可以直接转成注册漏斗。

第二步：定义事件、属性和触发时机

事件表示用户完成了什么动作，属性说明动作发生时的上下文。触发条件必须能被开发和测试人员用同一种方式判断，避免“点击了”和“提交成功”混为一谈。

Iris 的自定义事件可通过 track 接口上报，并在事件字典维护友好名称和业务描述。

第三步：建立可维护的命名规则

命名规则的目标是让同一动作不会出现多个写法。推荐使用小写英文与下划线，并采用“动作_对象”，例如 view_pricing、click_register、submit_order。属性值也要固定枚举，避免 wechat、微信、wx 被统计成三组。

• 事件名表达已发生的动作，不把页面文案直接当事件名。
• 结果不同可用属性区分；只有分析口径明显不同才拆成多个事件。
• 公共属性保持同名同类型，例如页面、设备、渠道。
• 敏感信息不进入事件名、属性值或 URL；不要采集密码、验证码、身份证号。

第四步：用表格完成评审

埋点表至少需要九列，任何一列不清楚，都可能在上线后变成口径争议。

第五步：按“触发—传输—入库—分析”验收

埋点验收不能只看浏览器发出了请求。完整验收应确认事件只触发一次、字段正确、平台能查到，并能进入目标报表。

1. 触发：正常、重复点击、返回重进、失败流程都执行一次。
2. 传输：检查事件名、属性类型、用户标识和时间是否正确。
3. 入库：在实时或事件列表中找到唯一测试标识。
4. 分析：把事件加入目标漏斗、留存或分群，确认人数与顺序符合预期。
5. 回归：记录测试账号、版本、环境和结果；修复后重跑关键路径。

常见问题

自动采集能代替埋点方案吗？

不能完全代替。自动采集适合页面浏览和基础点击；注册成功、支付完成、内容发布等业务结果仍需明确事件与触发口径。

事件越多越好吗？

不是。事件数量增加会提高维护和验收成本。应优先覆盖能支持决策的关键路径，再按真实分析需求扩展。

埋点表上线后还能改吗？

可以，但不要随意更改已存在事件的含义。新增属性通常比改写旧口径安全；重大变更应记录版本和生效日期。