埋点方案的两种典型病：该采的没采，上线三个月后想分析却发现数据不存在；采了的看不懂，事件名叫 login、denglu_1、user_click2 混在一起。用 AI（大模型）做埋点方案和数据字典，恰好对症：它擅长把事件想全、把命名理齐，但「要回答什么问题」得你先定——埋点是手段，分析目标才是起点。
先定问题，再倒推要采什么
上来就列事件清单，结果往往是采了一堆用不上的数据，存储和开发成本都花了，分析时一次没用到。正确顺序是把分析目标写出来，例如「用户在哪一步流失最多」「哪个渠道来的用户更活跃」，再让 AI 从这些问题倒推需要的事件和属性，并区分哪些是必需、哪些是可选。
提示词可以这样写：我要回答这几个问题（列出问题），请 1）列出为回答这些问题需要采集的事件和属性；2）标注哪些数据是必需、哪些可选；3）提醒哪些数据可能涉及用户隐私、需要谨慎处理。第三条经常被忽略，但它决定了这个方案能不能过合规审查。
命名规范：让半年后的同事也能看懂
命名不统一，后期每次分析都要翻文档猜含义。让 AI 先起草一套规则，团队评审后固化下来，常用的四条如下：
| 规则 | 示例 | 为什么这样定 |
|---|---|---|
| 格式统一为「模块_对象_动作」 | pay_order_success（支付模块_订单_成功） | 看到名字就知道事件属于哪个业务面 |
| 全小写、下划线分隔 | search_result_click，而不是 SearchResultClick | 避免大小写和空格在不同系统里解析不一致 |
| 不用缩写，除非团队都懂 | 写 detail_page_view，不写 dpv | 缩写的解释成本在半年后会翻好几倍 |
| 属性名跟随事件维度 | order_amount 只挂在订单类事件下 | 同名属性在不同事件里含义不同，是常见歧义源 |
数据字典：每个字段都要有主人
把每个事件、每个属性的含义、取值范围、负责人写清楚，这份字典是数据分析的基础设施——没有字典，数据就是一堆看不懂的字符串。让 AI 按固定字段整理：事件名、触发时机、属性列表、属性取值示例、负责人、版本号。字段固定的好处是可比，五十个事件放在一起能快速找出缺属性的、缺负责人的。
字典还要跟版本走。每次发版增删埋点，字典同步更新并标日期，否则三个月后字典就和线上实际采集对不上，分析结论全部存疑。
写属性时格外留意口径：金额字段是含税还是不含税、单位是元还是分；时间字段是事件发生时间还是上报时间。这些口径问题 AI 猜不出来，字典里不写清，后期分析必然有人按错误口径算一遍再返工。一条实用规则：任何需要解释第二遍的字段，解释文字直接写进字典，而不是留在某个人的脑子里。
AI 帮不上的三个判断
业务含义：AI 不知道你的「下单」和「支付成功」在业务上差在哪一步，事件之间的业务边界要你来画。隐私合规：涉及个人信息的采集，字段要不要收、收到什么粒度、要不要脱敏，必须对照相关法规和平台规定确认，AI 的提醒只是清单，不能当豁免。开发可行性：埋点能不能实现、实现成本多大，要问研发，有些客户端事件技术上采不到或代价很高，方案要一起裁剪。
三个典型失效场景
- 漏埋：分析目标中途新增，对应事件没补，等要做分析时数据已经回不来——每次需求评审都过一遍埋点清单。
- 命名漂移：新同事按自己的习惯起新名字，字典半年就乱——命名规则写进字典首页，新事件入库前对一遍。
- 字典过期：发版改了埋点没更新字典，分析口径全错——把字典更新挂进发版流程，标日期和版本号。
埋点采回来的数据最终要落到分析和复盘上，横向上可以参考「用 AI 做年度复盘：数据与选题的总结法」的数据复盘框架；如果分析对象是售后和流失，「用 AI 分析退货原因：售后数据的归因」的归因方法是现成的用法；要向决策层呈现数据，「用 AI 写年度经营总结：给合伙人的版本」里给合伙人的呈现方式可以直接借用。
埋点方案速查
- 顺序：先定分析问题，再倒推事件和属性
- 命名：模块_对象_动作，全小写下划线，不用缩写
- 字典：每个事件有含义、取值、负责人、版本号
- 发版即更新字典，标日期
- 隐私字段先过合规，可行性先问研发
