埋点之痛和埋点治理流程

运营有数为您推荐本文：

编辑导读：数据埋点是指在产品中加入统计代码做用户行为数据的收集，对于产品迭代和运营策略调整有很大的帮助，但是，很多公司对于数据埋点总是用不起来。本文作者对此进行了分析，希望对你有帮助。

数据埋点，也叫数据打点，是指在网站或者APP中加入一些统计代码进行用户行为数据的采集，通过分析埋点数据，来帮助产品做迭代及运营调整策略。

埋点的价值以及正确埋点的重要性，基本上所有的产品或者数据相关人员都得需要了解。埋点的数据价值很多公司都有清晰的认识，但为什么有的公司埋点总是用不起来呢？

一、埋点之痛

埋点的数据价值是一个数据驱动型的互联网公司需要认真考虑的事情。很多公司都有自己的埋点，但埋点数据却因各种原因用不起来，或者叫很难用好。埋点体系上涉及到的干系人非常多，而每一环又都不可或缺，任何一环的不重视都会导致埋点出问题。我想很多数据从业人员都知道埋点数据价值，但基于各种历史原因和现状却经常会感叹“”埋点数据怎么这么难用”。埋点之痛，不经历过埋点体系的从业务无法感同身受。

我们首先来梳理下多数公司 埋点治理体系的干系人及其痛点。一般埋点体系涉及到的人员有：业务方（常说的需求方 市场运营团队），产品（专指前端APP产品，部分公司由APP产品经理代提埋点需求），开发（埋点开发人员），测试（埋点数据测试），数据（包括两类角色：数据工程师，解析埋点并规范落库；数据分析师：使用埋点数据进行取数或分析）。

在数据产品经理这个角色慢慢成形之前，一般是由业务团队的前端产品或者业务团队商业分析师来提埋点需求，目前很多中大型公司会有专门的数据产品经理来负责埋点需求和全流程。那我们来总结下，这些角色的“埋点之痛”：

1. 业务方

1）埋点需求告诉产品了，但最后的数据却不是我想要的，没解决我的问题

2）想要做分析却发现数据不支持，该埋得点没埋或埋错了，不该埋点埋了一大堆

2. 产品

1）各条产品线各个功能模块产品各负责各自的埋点，很难全局规划和统一

2）除了负责功能需要，还要负责埋点需求，事情忙起来，根本无暇顾及埋点需求

3）业务一句话需求，也不说明白想要看什么指标，想分析什么运营

3. 开发

1) 产品这边五花八门埋点需求文档，我到底按哪个的标准来？

2) 嵌套到业务逻辑中的埋点代码，看着头疼，以后怎么维护？

3) 每次埋点都需要重新发版，埋点相对业务功能滞后，影响业务功能开发及上线进度

4) 有些APP业务端需求火急火燎，根本没时间详细考虑这块埋点

4. 测试

1）埋点设计需求不清晰，没个测试验收标准，怎么测都测不准

2）埋点功能嵌入到业务逻辑代码里面，每次测埋点都要重新走一遍流程

3）埋点事件存在性好测，埋点数据准确性，测的我心累

5. 数据分析

1）同一个埋点类型，存在无数个事件，让我怎么做统计分析？

2）事件定义的不清楚，问了开发和产品，问死都问不出来个所以然

3）做个行为数据的BI，业务怎么老说数据有问题

想必各位数据人或多多少都会碰到上述问题，埋点之难，难道真的无法解决了吗？到底是人出了问题还是流程体系出了问题？

二、规范埋点治理流程

很显然，埋点治理流程不对是导致埋点数据难以治理的根本原因。没有一个核心人物对埋点数据负责，那必然导致事不关己高高挂起。那到底应该由什么角色来牵头负责埋点全生命周期，保障埋点数据可用性呢？笔者基于自己公司的实践经验，总结出 可以由 数据人员（具体可以是数据产品经理）来把控埋点需求流程，统一设计埋点需求，并对埋点数据可用性负责。基于传统的埋点（前端产品/分析师）提需流程，经过优化后建议的提需流程如下：

业务需求统一汇集到 前端app产品处，然后app产品和数据部数据产品对接埋点业务需求，同时app产品产出PRD后给到数据PM，数据PM基于前端PRD来设计埋点需求，出埋点需求文档（DRD）。这里面数据PM会和前端产研有多次交互，一个好的交互方式能及时消除信息不对称，笔者经过实践，为提高整体埋点治理效率，总结出如下整个埋点生命周期流程中 前端功能需求和埋点需求协同的节奏：

经过几个月的实践，我们发现埋点治理新流程有如下优势：

• 统一了埋点需求入口和出口
• 统一了埋点设计规范
• 加深了数据对产品业务的理解
• 产出了更多的有价值数据应用

当然也有一些缺点，比如数据和产研频繁交互会更多，沟通成本会上升，这一点也可以在具体实践中不断优化流程，达到最优最合适的效果。

那具体新的埋点治理流程到底能有啥效果，能不能量化评估，接下来谈谈我们是怎么去评估这套新流程的效果。

效果评估：

效果评估从两个维度来：准确的数据应用产出，解决了流程干系人的痛点。

比如之前数据很难用，因为数据质量问题，几乎就只能做少量分析；现在统一流程和规范后，数据分析同学能基于埋点数据产出很多（取数，分析，BI，甚至行为数据产品）。之前流程干系人的埋点之痛，现在大多数也都解决了。

具体过去和现在对比如下：

下一步规划：

统一和规范了埋点治理流程 是实现埋点治理的关键的一步，也是埋点整体治理体系的第一步。公司要根据自身业务发展的阶段，公司的研发资源，成本等来综合评估是否还要进一步完善埋点治理体系。一个完整的埋点治理体系，除了统一埋点提需流程，还包含 打通各业务线，做统一的埋点事件设计，统一的埋点管理平台，统一的埋点测试平台，统一的行为数据分析平台。具体这些平台如何来实施，后续有空再分享。

当然，埋点数据的价值应该被高层所重视，建议能自顶向下推动数据驱动业务的文化，如果没有这层驱动，相关人员是无法有真正动力去做流程体制改造，建设多个埋点系统的。还有，数据部的同学要主动承担起这份责任，用数据驱动业务思想去影响业务和产研同学，只有他们觉得他们做的埋点真的有应用价值了，他们才会花时间去重视。

笔者的经历有限，分享的经验并不能完全代表其他公司的埋点治理情况。各位数据同行们，对于埋点治理体系 有任何的想法，对我的分享有任何建议，欢迎沟通。

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

题图来自Unsplash，基于CC0协议

文章来源于互联网:埋点之痛和埋点治理流程，如有侵权，请邮件联系我们附上版权证明,我们将在24小时内处理!