编辑导语：数据埋点让产品或运营等相关人员能按照具体的需求，定制性地统计较为复杂的用户数据，在工作中经常会用到数据埋点；那当我们在谈论数据埋点时，我们在谈论什么？本文作者详细分析了埋点体系的建设，认识一些埋点，我们一起来看一下。

这是一篇关于埋点体系建设的文章，谈论三个核心问题：

• 什么是埋点？
• 什么是好的埋点体系？
• 如何着手搭建埋点体系？

一、什么是埋点？

当我们要应用数据时，「巧妇难为无米之炊」这句话常常被提起，这句话是在表达，应用数据的前提是先有数据。

这可能听起来是句废话，但在实际的工作场景中，数据团队常常会收到一些「奇怪」的需求；比如，业务人员希望了解昨日使用搜索功能的用户数，而实际上数据库里面并没有存用户点击搜索按钮这个行为的相关数据；又比如，数据库中记录了打开小程序这一行为的相关数据，而业务人员希望了解通过不同场景启动（如，列表下拉打开、单人聊天页面分享打开等）打开小程序的用户数；由于数据库并没有在用户启动小程序时记录启动的场景，这样的需求也是无法被满足的，这样的情景都可以用「巧妇难为无米之炊」来比喻。

既然「先有数据」是一切数据应用的前提，如何才能把业务关心的用户行为数据都收集存储下来呢？答案就是——埋点。

如何理解「埋点」？

笔者有一个比较直觉的理解：埋点就是部署在前端，或服务端的一段代码，当用户触发了某种特定的操作，这段代码就会生成一条数据发送到数据库里，这条数据会记录哪个用户在什么时候以什么样的方式做了一件什么样的事。

于是，当我们想要统计用户操作某功能的次数、浏览页面的时长、某页面的跳出率时，就需要用埋点去采集这些信息。

二、什么是好的埋点体系？

埋点就埋点呗，为什么还要在「埋点」两个字后面加「体系」？

这是因为虽然埋点本身技术实现的难度并不高，但是整个埋点的过程可以说十分的复杂繁琐，有非常多细节需要考虑；不是某个角色能独立完成的工作，需要数据团队、研发团队、测试团队、业务团队多方参与。

如何让各方高效地协作，采集到业务线真正所需要的数据？埋点上线之后，BI 同学是否能清楚地知道埋点的元数据信息，加工出业务需要的指标？基本上，开发人员都不太愿意做「埋点」的工作，如何去说服他们？

这一系列问题都是埋点工作中需要考虑的，到最后，埋点不仅仅是一串能采集用户行为数据的代码，而是一整套能实现业务数据需求的复杂体系；其中包括埋点模型、埋点SDK、埋点流程规范、埋点工具、用户行为分析平台等等这些内容。

正由于埋点业务一套非常复杂的体系，需要投入很多的资源和人力去长期的运营，我们对埋点工作的要求就不止是解决采集数据的有无问题，还要关注成本问题、质量问题，也就是说如何以较低的成本稳定产出高质量的埋点？

我认为一个好的埋点体系应该同时满足：

• 成本低，埋点从需求到开发上线，再到数据分析，各方的操作成本低。
• 效率高，埋点模型全面、复用性高，不需要每个埋点需求都走一遍埋点流程。
• 质量好，通过机制和上线化的工具保证埋点需求端到端的交付。

三、如何着手搭建好的埋点体系？

一般而言，一条完整的埋点工作流长下面这个样子：

我们把上面描述的三个目标拆解到埋点工作流中去：

在埋点业务流程的每个步骤中 ，我们可以做些什么让能整个埋点体系实现成本更低、更高效、质量更好：

1）需求沟通，业务同学要把需求传达给数据团队；我们都知道，沟通是一个时间黑洞，应最大程度地提升埋点需求的沟通效率，让业务人员清楚有埋点需求应该找谁对接、如何把需求描述得清楚。

2）埋点设计，重点在于埋点模型，好的埋点模型抽象能力强，能够更全面的覆盖用户行为，也有更好的复用性，设计起来也更加简单，可以极大的提升埋点工作流的效率；埋点模型设计得好还能提升后续数据计算的性能。另外，因为我们考虑的是企业级的埋点体系建设，需要统一的设计。

3）需求评审：很必要把埋点当作一条独立的研发流程来看待，设置专门的埋点需求评审，这么做的好处，一方面是让大家重视埋点研发；另一方面，因为参与埋点的团队比较多，可以在需求评审时把大家聚到一起，同步埋点方案、业务价值、研发计划等，协同各方各司其职。

4）开发测试：研发和测试按照评审通过的 DRD 进行开发测试；埋点的研发是一项琐碎的工作，并且随着埋点越来越多，埋点代码的管理任务很重，这也是很多研发不愿意埋点的原因；埋点的测试是一件比较困难的事件，很多测试人员之前没有接触过专项工作，需要提供一些线上的工具帮助研发和测试提升效率。

5）埋点应用：这个环节主要是要维护好埋点的元数据信息，知道埋点和业务是如何关联，方便 BI 同学加工出业务需要的指标。

总结上面，Thea 认为建设一个好的企业级埋点体系，有三个要点：

• 设计灵活、全面、复用性高的埋点模型，提升埋点设计的效率，降低埋点应用和管理的成本。
• 制定清晰可落地的端到端埋点采集规范，定义埋点工作流以及每个环节的输入输出，保证参与埋点的各方高质量的产品。
• 开发线上工具支持埋点的管理、研发、测试验收等工作，提升效率。

这是《数据埋点，一次讲个够》系列文章的第一篇，这一系列的文章会和大家系统地分享我对埋点体系建设的实践与思考，后续的文章会进一步和大家讨论这些问题：

• 如何让业务线的产品/运营更高效地提埋点需求？
• 如何更快的响应业务需求，输出 DRD？
• 如何设计更简洁、更灵活、拓展性更强的埋点模型？
• 如何协调好参与埋点工作的各方，快速产出高质量的埋点？
• 如何有效地管理成千上万个已线上、未上线、需要下线的埋点？

希望可以帮助数据产品新手快速上手建设埋点体系，同时，如果你在企业里负责埋点相关的工作，也希望这些文章能够贡献一些好的思路，帮助你们的埋点体系更上一层楼。

Thea，微信公众号：Thea的若干好奇；从事大数据产品工作六年，设计、管理埋点已有三年，经手过上万个埋点，经历过从 0 到 1 自建埋点体系，也使用过第三方的埋点服务。

本文由@Thea 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。