Sunqy 文档库

主题

06 · 埋点与数据：从埋点设计到行为分析 ​

"用户到底怎么用？"——猜是没用的，埋点才有答案。 埋点是把产品决策从"我觉得"变成"数据显示"的证据链。本篇讲埋点怎么设计、数据质量怎么保证、怎么从数据得出可行动结论；具体平台接入链回各域。

速览卡 ​

项内容
一句话定位用"埋点设计 → 数据质量 → 行为分析"三步，建立"数据驱动迭代"的证据链
核心内容埋点什么、事件怎么命名、属性与上下文、埋点管理、数据质量四问、分析闭环、合规边界
读完能回答一个功能要埋哪些点？埋点数据凭什么可信？怎么看数据得出下一步该做什么？
相关板块H02 · 产品思维 ｜ B38 · 埋点与行为分析 ｜ S05 · 数据与隐私合规

一、埋点什么：从指标反推事件 ​

埋点不是"能埋就埋"，而是从指标反推：

text
北极星指标（H02） → 指标树 → 需要的用户行为事件 → 埋点

一个功能至少埋三类事件：

类型例子回答
曝光页面/模块被看到有没有人看到
交互点击、切换、提交有没有人用、用到哪一步
转化/结果成功、失败、耗时用完之后有没有达成目标

经验法则：与其埋 100 个"可能有用"的点，不如埋 20 个"能验证当前指标"的点。埋点跟着指标走，才不会变成没人看的数据垃圾。

二、事件设计与属性 ​

一个事件的要素：

要素说明例子
事件名动词 + 对象，统一命名report_viewed、filter_clicked
属性能回答"在什么情况下"页面、来源、筛选条件、耗时
标识用户/设备/会话用于漏斗与留存

命名规范很重要：同一件事全端同名（前端、Flutter、后端上报同一事件，名字一致），否则跨端对不上。属性要提前定好，补埋点是最贵的。

三、数据质量：埋了不等于可信 ​

数据不可信，分析就是自欺。四个必查问题：

问题检查
有没有漏埋？事件触发率与预期功能路径是否吻合
有没有重埋？一次操作是否重复上报
属性对不对？关键属性（来源、状态）是否为空/错
版本对得上吗？新旧版本口径是否一致

用开发视角保证质量：埋点代码要可测试、可验证，升级版本要评估事件口径变化。数据质量的责任在开发，不在分析师。

四、行为分析闭环：从数据到行动 ​

数据只有变成"行动"才有价值。闭环四步：

text
① 看指标（发生了什么）
② 找异常（哪里不对/哪里有机会）
③ 提假设（为什么会这样）
④ 设计实验（改什么、怎么验证）
环节示例
看指标看板页 7 日留存下降 5%
找异常新用户留存差，老用户正常
提假设新用户 onboarding 太长，弃用率高
设计实验缩短 onboarding，A/B 验证留存是否回升

数据只回答"是什么"，不回答"为什么"。从"是什么"到"怎么办"，需要产品假设 + 实验，这是 H02 产品思维和数据分析的结合点。

五、合规边界 ​

埋点涉及数据收集，必须遵守合规（详见 S05 数据与隐私合规）：

  • 只收集必要数据，明确告知与授权
  • 个人标识最小化，敏感信息不采集
  • 数据留存期限、删除权要落实
  • 跨平台上报不泄露敏感字段

合规不是"上线前补个弹窗"，是埋点设计的一部分。先想"这个属性该不该采集"，再想"怎么采"。

自检清单 ​

  • [ ] 埋点从指标反推，不"能埋就埋"
  • [ ] 每类关键行为有曝光/交互/转化三类事件
  • [ ] 事件命名全端统一，属性提前定好
  • [ ] 数据质量四问（漏/重/错/版本）有验证手段
  • [ ] 能走完"看指标 → 找异常 → 提假设 → 设计实验"闭环
  • [ ] 埋点设计时已考虑合规（授权、最小化、留存）

常见误区 ​

误区事实
"埋点越多越好"跟着指标走，埋点才是资产；否则是负担
"埋了就有数据"数据质量靠验证，漏/重/错都会毁掉结论
"数据会告诉你为什么"数据只给"是什么"，"为什么"要靠假设与实验
"合规是法务的事"埋点设计的合规责任在开发

动手练习 ​

练习 A：给一个功能设计埋点 ​

选一个功能，从北极星指标反推出需要的事件与属性，列成埋点清单。

练习 B：数据质量自查 ​

对现有埋点做一次四问检查：有没有漏、重、错、版本不一致？写下发现的每个问题与修复方式。

练习 C：走一次分析闭环 ​

取一组真实指标，走完"看指标 → 找异常 → 提假设 → 设计实验"四步，输出一份可执行的实验计划。

相关文档 ​

本区 ​

其他域 ​