用户埋点不是“把所有点击都记录下来”。真正有价值的埋点是把用户行为转化成可分析的问题用户从哪里来为什么注册哪里流失哪些功能真的被用付费前做过什么新版本有没有改善转化如果埋点没有设计后面看到的不是数据而是一堆无法解释的事件名。本文参考了几类官方资料Google Analytics 4 Recommended EventsGoogle Analytics 4 Automatically Collected EventsSegment Tracking PlanMixpanel Property Reference先从问题开始不要一上来就问“要埋哪些点”。先问业务问题用户从访问到注册的转化率是多少 注册后有多少人完成第一次关键动作 哪些入口带来的用户更容易付费 哪个步骤流失最多 新功能发布后有没有被使用 免费用户升级前通常做了什么埋点是为了回答问题不是为了显得数据化。如果一个事件不能帮助你做判断、优化产品或验证假设就不应该优先埋。事件、属性、用户属性要分清埋点里有三个概念很容易混。事件用户做了什么 事件属性这次行为的上下文 用户属性这个用户长期不变或变化较慢的特征比如事件checkout_started 事件属性planpro, sourcepricing_page, currencyUSD 用户属性roleowner, company_size1-10, signup_channelseo事件描述动作属性描述这次动作的细节用户属性描述这个人或账号。不要把所有东西都塞进事件名。例如不要写pro_user_from_pricing_page_started_usd_checkout应该写成event: checkout_started properties: plan: pro source: pricing_page currency: USD这样后续才能筛选、分组和对比。命名要稳定事件命名一旦混乱数据很快就没法用。推荐使用统一格式比如 snake_casepage_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_projectcheckout_started可以带plan billing_cycle currency price coupon_used sourcearticle_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 验证码 身份证件 银行卡号 完整地址 私密聊天内容 用户上传文件原文 未经同意的敏感个人信息如果需要分析可以用脱敏、分组或枚举值。例如记录planpro不要记录完整支付信息记录company_size1-10不要记录员工名单。事件版本要能演进产品会变埋点也会变。当事件含义变化时不要悄悄改。可以采用新增属性而不是改旧属性含义 必要时新增 v2 事件 在埋点表里记录废弃时间 保留新旧事件一段过渡期 上线前检查事件是否仍然发送最糟糕的情况是同一个事件名在不同时间代表不同含义。这样历史数据会混在一起分析结果会误导你。一个最小可用埋点方案独立开发早期可以这样做1. 先列 3 个核心业务问题 2. 为每个问题设计一个漏斗 3. 每个漏斗只保留关键事件 4. 事件统一使用 snake_case 5. 每个事件带必要属性 6. 定义一个激活事件 7. 用埋点表维护事件规范 8. 禁止采集敏感信息 9. 每次发布前检查关键事件是否正常这套方法比“全站点击自动采集”更慢一点但数据质量高很多。写在最后用户埋点的本质是把产品问题翻译成可观察的行为数据。不要为了数据而数据。先有问题再有事件先有漏斗再有按钮先有命名规范再有代码接入。一个好的埋点系统最后应该让你更清楚地知道用户在哪一步理解了产品在哪一步放弃了产品以及哪一类用户最有可能留下来。下一篇我们继续聊增长入口SEO 页面怎么生成。原文链接用户埋点怎么设计 | Harries Blog™
用户埋点不是“把所有点击都记录下来”。真正有价值的埋点是把用户行为转化成可分析的问题用户从哪里来为什么注册哪里流失哪些功能真的被用付费前做过什么新版本有没有改善转化如果埋点没有设计后面看到的不是数据而是一堆无法解释的事件名。本文参考了几类官方资料Google Analytics 4 Recommended EventsGoogle Analytics 4 Automatically Collected EventsSegment Tracking PlanMixpanel Property Reference先从问题开始不要一上来就问“要埋哪些点”。先问业务问题用户从访问到注册的转化率是多少 注册后有多少人完成第一次关键动作 哪些入口带来的用户更容易付费 哪个步骤流失最多 新功能发布后有没有被使用 免费用户升级前通常做了什么埋点是为了回答问题不是为了显得数据化。如果一个事件不能帮助你做判断、优化产品或验证假设就不应该优先埋。事件、属性、用户属性要分清埋点里有三个概念很容易混。事件用户做了什么 事件属性这次行为的上下文 用户属性这个用户长期不变或变化较慢的特征比如事件checkout_started 事件属性planpro, sourcepricing_page, currencyUSD 用户属性roleowner, company_size1-10, signup_channelseo事件描述动作属性描述这次动作的细节用户属性描述这个人或账号。不要把所有东西都塞进事件名。例如不要写pro_user_from_pricing_page_started_usd_checkout应该写成event: checkout_started properties: plan: pro source: pricing_page currency: USD这样后续才能筛选、分组和对比。命名要稳定事件命名一旦混乱数据很快就没法用。推荐使用统一格式比如 snake_casepage_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_projectcheckout_started可以带plan billing_cycle currency price coupon_used sourcearticle_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 验证码 身份证件 银行卡号 完整地址 私密聊天内容 用户上传文件原文 未经同意的敏感个人信息如果需要分析可以用脱敏、分组或枚举值。例如记录planpro不要记录完整支付信息记录company_size1-10不要记录员工名单。事件版本要能演进产品会变埋点也会变。当事件含义变化时不要悄悄改。可以采用新增属性而不是改旧属性含义 必要时新增 v2 事件 在埋点表里记录废弃时间 保留新旧事件一段过渡期 上线前检查事件是否仍然发送最糟糕的情况是同一个事件名在不同时间代表不同含义。这样历史数据会混在一起分析结果会误导你。一个最小可用埋点方案独立开发早期可以这样做1. 先列 3 个核心业务问题 2. 为每个问题设计一个漏斗 3. 每个漏斗只保留关键事件 4. 事件统一使用 snake_case 5. 每个事件带必要属性 6. 定义一个激活事件 7. 用埋点表维护事件规范 8. 禁止采集敏感信息 9. 每次发布前检查关键事件是否正常这套方法比“全站点击自动采集”更慢一点但数据质量高很多。写在最后用户埋点的本质是把产品问题翻译成可观察的行为数据。不要为了数据而数据。先有问题再有事件先有漏斗再有按钮先有命名规范再有代码接入。一个好的埋点系统最后应该让你更清楚地知道用户在哪一步理解了产品在哪一步放弃了产品以及哪一类用户最有可能留下来。下一篇我们继续聊增长入口SEO 页面怎么生成。原文链接用户埋点怎么设计 | Harries Blog™
