数据埋点|六个步骤实现数据埋点方案设计

点击上方 蓝字 关注我们

作为数据分析师的你，是否和我一样经常会被业务方拿着两个不同数据平台的报表数据进行灵魂拷问。下面的场景你应该在熟悉不过了。

情景1

一场拉新促活的活动之后，运营拿着两个不同团队维护的报表数据来问我，为什么两份报表统计出来的日活跃用户(DAU)数量不一致？

我解释道，“你确定两份报表的统计口径是一致的吗，最小的统计维度是一致的吗？”

运营说，“都是一样的啊，统计的都是DAU。”

我说，“DAU以account_id为最小维度进行统计或者以device_id或者以open_id为最小维度进行统计的结果都会有一定的差距。我们这边是以account_id为最小单位统计的DAU。而且，即使统计口径一致，埋点和上报方法也有区别。”

后来，我向另外一个数据平台的相关人员咨询之后，发现他们统计DAU的最小单位是open_id,不同的统计口径会造成一定的数据差异。而统计口径的差异不止出现在报表统计阶段，在数据埋点阶段也会出现口径不一致的问题，触发事件的条件、数据埋点的方式、数据上报的方式不同都会造成数据不一致的情况出现。

为了避免这些问题，小编把自己踩过的坑总结出来并形成一套方法论，希望初学的你或即将转行的你能够少采坑，高效地完成数据埋点工作！

 

01

数据埋点流程

 

数据埋点是数据治理流程中重要的一环，是一项多部门协作共同完成的工作，数据分析师在这个流程当中承担着重要的角色。我们将数据埋点流程梳理为下图，数据分析师从数据需求评估阶段直至数据应用阶段都会参与流程，可谓是埋点工作的中流砥柱。

 

在数据埋点这项工作中，数据分析师需要立足于当前的数据需求，提炼出数据指标方案，并且构思要看这些指标需要有哪些数据，这些数据也就是需要埋的点。当然，这只是一些初步的埋点方案，想要让埋点指标变得“准”而“全”当然还需要另外一些方法实现，比如用户路径之类的。有了初步的埋点规划之后，分析师还需要确定时间触发机制和上报机制，因为不同的机制意味着不同的统计口径。对于新业务来说，为了避免统计口径不一致而出现乌龙事件，最好能和之前的口径一致，以方便横向比较。除此之外呢，统一各个项目之间的字段命名和表结构也是一项必不可少的工作，这个步骤也是数据治理流程当中必不可少环节。完成这些步骤之后，一份初步的埋点就差不多完成了。在和需求方以及程序的反复讨论中修改完善埋点文档，将埋点文档交付程序进行埋点，在此期间分析师需要通过测试环境的数据验证当前埋点是否存在一定的问题，若有问题还可以在该阶段进行修改，若无问题可上线埋点事件。

 

02

六个步骤实现数据埋点设计

 

数据埋点设计师数据分析师是埋点的重中之重，埋点设计得好能够极大地方便后续的数据应用。对于数据埋点设计，我们也总结了六个关键步骤。