为什么埋点经常做乱
很多项目第一次做数据采集时，只想知道“用户点了哪里”。需求看起来简单，最后却容易变成一堆没人敢用的数据：事件名称不统一，字段缺失，页面路径变化后统计断掉，测试环境和生产环境混在一起，业务方看报表时也不知道数字从哪里来。
前端埋点不是把点击事件都发到服务器。它更像一份业务记录，说明用户在什么场景下做了什么动作，动作是否成功，失败原因是什么。设计时要让产品、前端、后端和数据分析的人都能读懂。
先把采集目标说清楚
动手写代码前，最好先列出要回答的问题。比如：注册流程在哪一步流失？搜索结果是否被点击？用户提交表单后有没有收到明确反馈？新功能上线后有没有人使用？这些问题决定了要采集哪些事件。
如果没有问题清单，埋点会越加越多，后面清理成本很高。我们通常会把需求拆成三类：页面访问、用户操作、业务结果。页面访问说明用户到了哪里；用户操作说明用户做了什么；业务结果说明这次操作有没有完成。
事件命名要稳定
事件名不要跟着按钮文案走。按钮今天叫“立即咨询”，下个月可能改成“提交需求”，但事件可以一直叫 contact_form_submit。命名稳定，报表和历史数据才不会被页面文案影响。
常见做法是用“模块 + 动作”的格式，例如 search_submit、article_card_click、checkout_pay_success。同一个项目内只保留一种风格，不要一会儿用驼峰，一会儿用下划线。
字段不要只存页面路径
页面路径有用，但不够。一个按钮可能出现在首页、文章页、案例页，单看点击次数很难判断来源。字段里至少要包含页面类型、页面标题、入口位置、业务对象 ID、用户状态和设备信息。
以文章卡片点击为例，可以记录 article_id、article_title、source_page、card_position。这样后续才能看出哪些位置带来了阅读，哪些内容只是曝光多但点击少。
上报时机要照顾体验
页面访问可以在页面加载后上报，但提交、支付、保存这类事件，最好区分“点击”和“结果”。用户点了提交按钮，不代表表单已经提交成功。只记录点击，会让转化数据偏高。
对于跳转前的点击事件，可以使用 navigator.sendBeacon 或短暂延迟跳转。不要为了保证埋点上报而阻塞页面，也不要在网络失败时反复弹出错误提示。埋点失败应该被记录，但不能打断用户操作。
隐私边界要提前定
数据采集不能把所有信息都发出去。手机号、邮箱、姓名、身份证、详细地址等个人信息不要直接进入埋点日志。确实需要关联用户时，可以使用内部用户 ID 或脱敏后的标识，并在隐私政策里说明数据用途。
如果页面包含表单输入，不要采集输入内容本身。更合理的做法是采集字段是否填写、校验是否通过、失败原因类型。这样能分析流程问题，也能减少隐私风险。
数据要有校验流程
埋点上线前要做一次验收。打开浏览器网络面板，按真实路径走一遍，确认事件名、字段、触发次数和环境标识都正确。上线后再看一天数据，检查是否出现异常尖峰、重复上报或字段为空。
对于重要事件，建议建立埋点清单。清单里写清事件名、触发条件、字段说明、负责人和上线日期。以后页面改版时，可以对照清单确认哪些事件要保留，哪些事件需要调整。
项目里可以这样推进
- 先列业务问题，不先列按钮。
- 把事件分成页面访问、用户操作、业务结果三类。
- 每个事件写清触发条件和字段含义。
- 测试环境和生产环境使用不同标识。
- 上线后检查真实数据，再把报表交给业务方使用。
埋点做得好，团队能更快判断页面是否有效、流程卡在哪里、功能有没有被使用。数据数量不必追求越多越好，能回答业务问题才有价值。