用户埋点不是“把所有点击都记录下来”。
真正有价值的埋点，是把用户行为转化成可分析的问题：用户从哪里来？为什么注册？哪里流失？哪些功能真的被用？付费前做过什么？新版本有没有改善转化？
如果埋点没有设计，后面看到的不是数据，而是一堆无法解释的事件名。
本文参考了几类官方资料：
- Google Analytics 4 Recommended Events
- Google Analytics 4 Automatically Collected Events
- Segment Tracking Plan
- Mixpanel Property Reference
先从问题开始
不要一上来就问“要埋哪些点”。
先问业务问题：
用户从访问到注册的转化率是多少？
注册后有多少人完成第一次关键动作？
哪些入口带来的用户更容易付费？
哪个步骤流失最多？
新功能发布后有没有被使用？
免费用户升级前通常做了什么？
埋点是为了回答问题，不是为了显得数据化。
如果一个事件不能帮助你做判断、优化产品或验证假设，就不应该优先埋。
事件、属性、用户属性要分清
埋点里有三个概念很容易混。
事件：用户做了什么
事件属性：这次行为的上下文
用户属性：这个用户长期不变或变化较慢的特征
比如：
事件：checkout_started
事件属性：plan=pro, source=pricing_page, currency=USD
用户属性：role=owner, company_size=1-10, signup_channel=seo
事件描述动作，属性描述这次动作的细节，用户属性描述这个人或账号。
不要把所有东西都塞进事件名。例如不要写：
pro_user_from_pricing_page_started_usd_checkout
应该写成：
event: checkout_started
properties:
plan: pro
source: pricing_page
currency: USD
这样后续才能筛选、分组和对比。
命名要稳定
事件命名一旦混乱，数据很快就没法用。
推荐使用统一格式，比如 snake_case：
page_viewed
signup_started
signup_completed
onboarding_completed
project_created
file_uploaded
checkout_started
payment_succeeded
subscription_cancelled
不要在同一个产品里混用：
Signup Success
signup_success
signUpSuccess
register_done
user_registered
命名稳定，比命名“优雅”更重要。
Google Analytics 4 的推荐事件文档也给出了 sign_up、login、purchase 等推荐事件名。能复用平台推荐事件时，优先复用；平台没有覆盖的，再定义自有事件。
先埋关键路径
早期不需要埋满全站。
先覆盖最关键的路径：
访问首页
查看定价页
开始注册
完成注册
完成 onboarding
创建第一个项目
触发核心功能
开始支付
支付成功
取消订阅
如果是内容产品，可以关注：
文章曝光
文章阅读
目录点击
搜索
收藏
分享
订阅
如果是工具产品，可以关注：
模板选择
文件导入
生成开始
生成成功
导出
协作邀请
不要一开始就追踪所有按钮。按钮点击很多，但不一定都能回答核心问题。
每个事件都要有属性
没有属性的事件，分析能力很弱。
例如 project_created 这个事件，至少可以带：
project_type
template_id
source
plan
team_id
is_first_project
checkout_started 可以带：
plan
billing_cycle
currency
price
coupon_used
source
article_read 可以带：
article_id
category
read_depth
referrer
locale
属性不要过多，但要能支持常见分析：分渠道、分版本、分计划、分入口、分用户类型。
设计漏斗，而不是散点
单个事件价值有限，漏斗才更能回答问题。
例如注册漏斗：
landing_viewed
signup_started
email_verified
profile_completed
onboarding_completed
activation_event_completed
支付漏斗：
pricing_viewed
checkout_started
payment_method_entered
payment_succeeded
subscription_activated
核心功能漏斗：
feature_opened
input_added
generation_started
generation_succeeded
result_exported
设计埋点时，最好直接画出漏斗，而不是单独列事件。
激活事件要单独定义
每个产品都应该定义一个激活事件。
激活事件不是注册成功，而是用户真正体验到产品价值的行为。
例如：
项目管理工具：创建第一个项目并邀请成员
AI 写作工具：生成第一篇可用草稿
图片工具：上传图片并完成第一次导出
邮件工具：成功发送第一封邮件
数据工具：连接数据源并生成第一张图表
注册只是账户创建，激活才代表用户开始理解产品价值。
如果你不知道激活事件是什么，就很难优化 onboarding。
埋点表必须维护
埋点要有 tracking plan，也就是埋点表。
Segment 的 Tracking Plan 文档把它描述为一份数据规范，用来定义你要采集的事件和属性。
早期可以用一个 Markdown 或表格维护：
事件名
触发时机
触发页面
事件属性
属性类型
是否必填
示例值
负责人
上线版本
备注
没有埋点表，过几个月你会忘记事件是什么意思，也不知道哪些事件还在发送。
不要采集敏感信息
埋点系统通常会被产品、运营、增长、客服、外部工具访问。
所以不要采集：
密码
Token
验证码
身份证件
银行卡号
完整地址
私密聊天内容
用户上传文件原文
未经同意的敏感个人信息
如果需要分析，可以用脱敏、分组或枚举值。
例如记录 plan=pro，不要记录完整支付信息；记录 company_size=1-10，不要记录员工名单。
事件版本要能演进
产品会变，埋点也会变。
当事件含义变化时，不要悄悄改。
可以采用：
新增属性，而不是改旧属性含义
必要时新增 v2 事件
在埋点表里记录废弃时间
保留新旧事件一段过渡期
上线前检查事件是否仍然发送
最糟糕的情况，是同一个事件名在不同时间代表不同含义。这样历史数据会混在一起，分析结果会误导你。
一个最小可用埋点方案
独立开发早期可以这样做：
1. 先列 3 个核心业务问题
2. 为每个问题设计一个漏斗
3. 每个漏斗只保留关键事件
4. 事件统一使用 snake_case
5. 每个事件带必要属性
6. 定义一个激活事件
7. 用埋点表维护事件规范
8. 禁止采集敏感信息
9. 每次发布前检查关键事件是否正常
这套方法比“全站点击自动采集”更慢一点，但数据质量高很多。
写在最后
用户埋点的本质，是把产品问题翻译成可观察的行为数据。
不要为了数据而数据。先有问题，再有事件；先有漏斗，再有按钮；先有命名规范，再有代码接入。
一个好的埋点系统，最后应该让你更清楚地知道：用户在哪一步理解了产品，在哪一步放弃了产品，以及哪一类用户最有可能留下来。
下一篇，我们继续聊增长入口：SEO 页面怎么生成。
