数据分析的目的是要解决特定业务场景下的业务问题，通过数据埋点可以提高数据分析的质量。那么该如何进行数据埋点设计？本文总结了数据埋点相关流程，希望对你有所启发。

为了更好的实现公司的商业目标，用户体验越来越受重视。很多互联网公司都会成立UED部门，会搭建UE设计规范体系、UI设计规范体系，但是实际推动产品实现商业目标的过程中，会发现仅有这两套体系是不够的。因为这两套规范体系，主要是提高对内的开发协作效率，虽然也会在一定程度上对提升产品品牌一致性等也有一定的帮助，但这远远不够。

因此，很多集团公司会搭建：“UE设计规范体系、UI设计规范体系、数据埋点规范体系” 三位一体的闭环式规范体系。

通过数据埋点规范体系的搭建，可以保持数据埋点的规范性、提高开发埋点的速度和质量，保持数据分析口径的一致性，从而提高数据分析质量。同时可以更好的监测和解决特定业务场景下的业务问题，用户在操作流程中的受阻问题、用户在下单过程中的中断问题等，为迭代收集有效依据，为提升业务目标和用户体验指明方向性。

数据分析埋点要采用“以终为始”的解决方案，数据分析的目的是要解决特定业务场景下的业务问题。需要进一步把业务问题根据“业务目的”拆解成多个子问题，才能转成数据问题，才能基于此搭建分析框架。

（有的公司有专门的数据分析岗位，有的公司则是由产品经理、用户体验设计师或者业务需求方来承担此角色。文中统一写：数据分析师）

埋点分析，是一种常用的数据采集方法，指在需要采集数据的“操作节点”将数据采集的程序代码附加在功能程序代码中，对操作节点上用户行为或事件进行捕获、处理和发送相关技术及其实施过程。数据埋点是一种良好的私有化部署数据采集方式。

数据埋点分为初级、中级、高级三种方式，分别为：

初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复（如购买按钮点击率）

中级：植入多段代码，追踪用户在平台每个界面上的系列行为，事件之间相互独立（如打开商品详情页 一 选择商品型号 一 加入购物车 一 下订单一购买完成）

高级：联合公司工程、ETL采集分析用户全量行为，建立用户画像，还原用户行为模型，作为产品分析、优化的基础。

数据埋点是一种常用的数据采集方法，可方便产品、运营系统性的统计分析用户数据。通过采集用户在购买商品或者进行软件操作过程中的行为数据，通过埋点进行上报，便于后续分析用户行为与洞察用户偏好。

数据埋点做得好，能够方便分析业务问题，快速得出结论，同时辅助业务方进行决策，以实现业务目标，形成闭环。

数据埋点的方法根据其位置不同，可分为前端埋点和后端埋点。

前端埋点通过SDK进行数据采集，为了减少数据流量，通常对采集的数据进行压缩、暂存、打包上报。对于那些不需要实时上报的事件，通常只在Wi-Fi环境下上报，因此会出现数据上报的延迟与漏报现象。

后端埋点通过调用API (Application Programming Interface) 采集信息，使用内网传输信息，基本不会因为网络原因丢失数据，所以后端传输的数据可以非常真实地反映用户行为。

理论上，只要客户端向服务器发送请求，服务器埋点就能够收集到相应的数据。相比于前端埋点，后端埋点能实时采集数据，不存在延时上报现象，数据很准确；并且后端埋点支持与用户身份信息和行为附带属性信息的整合；另外，每次上线新的埋点或者更新埋点时，发布后埋点马上生效。

网站或者App能够采集到用户的四类信息：设备硬件信息、软件能力、数据权限、用户行为。

1、设备的硬件信息，如设备品牌、型号、主板、CPU、屏幕分辦率等；

2、软件能力，就算没有点击网页或者App、横竖屏、截屏、摇一摇等操作也会被记录下来；

3、数据权限，新注册某款软件时，对于相册、通讯录、GPS等比较私密的信息一般会跳出让用户授权的页面，如果用户同意授权，那么网页或者App就能够采集到这些信息；

4、用户行为，用户只要对网页或者App进行操作，行为都会被记录下来。

虽然网站或App在用户授权的情况下可以采集用户的各类数据，但是在做数据埋点文档的时候，并不需要追求大而全，根据业务方的需求文档对相应的行为进行埋点记录即可。

数据埋点是数据治理流程中重要的一环，是一项需多部门协作共同完成的工作，数据分析师在整个流程中承担着重要的角色，数据分析师从数据需求评估阶段直至数据应用阶段都需要参与。

在数据埋点这项工作中，需要立足于当前的数据需求，提炼出数据指标方案，并且构思这些指标需要哪些数据，这些数据也就是需要的埋点。

当然，这只是一些初步的埋点方案，想要让埋点变得“准”而“全”，还需要另外一些方法才能实现，比如用户路径等。有了初步的埋点规划之后，还需要确定时间触发机制和上报机制，因为不同的机制意味着不同的统计口径。

对于新业务方来说，为了避免因统计口径不一致而出现乌龙事件，统计指标最好能和之前的口径一致，以方便横向比较。

除此之外，统一各个项目之间的字段名和表结构也是一项必不可少的工作，这个步骤也是数据治理流程中必不可少的环节。完成这些步骤之后，一份初步的埋点方案就完成了。

然后在和业务方及前端、后端工程师的反复讨论中修改完善埋点文档，将埋点文档交付前、后端工程师进行埋点，在此期间数据分析师需要通过测试环境的数据验证当前埋点是否存在问题，若有问题，还可以在该阶段进行修改，若无问题可部署埋点事件上线。

事件是指产品中的功能或者用户的操作，变量是指描述事件的属性或者关键指标。确认事件与变量可以通过AARRR ( Acquisition Activation Retention Revenue Referral〉 海盗模型或者UJM（User Journey Map，用户旅程图）模型进行逐步拆解，理清用户生命周期和行为路径，抽象出每一个步骤的关键指标。（这三个模型单独在新文章中分析）

不同的触发时机代表着不同的事件计算口径，因此触发时机是影响数据准确性的重要因素。二者口径不同，数据肯定会有一定差异，因此明确事件的触发条件非常重要。

以用户付款为例，是以用户点击付款界面作为触发条件，还是以付款成功作为触发条件进行埋点呢？在用户付款这个例子中，建议使用两个字段记录用户付款行为：一个字段记录点击付款界面这个行为，另一个字段记录是否付款成功。

上报机制也是数据准确性的重要影响因素之一。客户端上报数据可能会由于网络连接原因出现丢包的情况。数据分析师在完成埋点工作的时候也需要确定数据是实时上报还是异步上报，以确定埋点是否合理，并及时调整数据埋点方案。

统一数据表结构，可方便团队内部进行数据的管理和数据复用，建议在团队内部形成一套统一的数据结构规范。例如，将表分为不同的层级，第一层记录用户的基础信息，包括用户、地区、昵称等；第二层记录用户行为信息。

有了统一的数据表结构规范还不够，统一数据命名规范也是数据埋点工作的重要一环。如果有条件的话，可以建立数据字典，以统一数据命名规范。例如，确保同一变量在所有的数据表中都用统一的字段名。对于消费金额这个字段，数据分析师希望所有的表中只要出现消费金额都Amount字段名，不要出现money、payment等其他字段名。

建立公司内部或者团队内部的命名规范是非常必要的，可以采用动词+名词或者名词+动词的规则来命名，比如“加入购物车”事件，就可以命名为：addTocart。

数据埋点是为数据应用做铺垫的。埋点之后，数据分析师可能面临着搭建指标体系和数据报表体系的工作，可以根据报表的优先级、埋点的技术、实现成本及资源的有限性，为数据埋点确定优先级。

下面举个实际案例：

之前在某集团公司负责过电商类数据埋点设计。公司有很多子品牌和不同的业务线，当时做的埋点设计，主要是针对商标交易业务。

（1）需求背景

商标库商标有100W+，但是由于之前的商标排序算法机制不合理，点击行为占了排序的很大权重，导致长时间卖不出去的商标排序反而更靠前，需要人工操作处理，耗时且工作量大。为了解决这一问题，当时设计了时间衰减模型，同时业务线也希望商品能实现千人千面的智能推荐。

（2）数据埋点设计流程总览

（3）数据埋点流程实操步骤

①确认事件与变量——通过UJM模型拆分用户购买商品的路径

将用户购买路径拆分为注册、登录、商品曝光、商品点击、浏览页面详情、加入购物车、生成订单、订单支付等步骤。根据产品经理提出的数据需求，确定每一个步骤需要哪些字段才能实现数据需求。

②确认触发机制

明确是在点击按钮时记录行为还是在用户完成该步骤时记录行为。

③确认上报机制

明确数据上报机制是实时上报还是异步上报。不同的上报机制采集到的字段可能不一样，或者说需要将字段拆分到不同表中进行记录。

④统一字段名

业务数据集内同一变量在所有的数据表中都使用统一的字段名。例如，用户编号用account_id、用户所属国家用region、用户所属地区用ip_region等。

⑤统一表层级结构

采用多层数据表结构：第一层存放通用信息，第二层存放用户基本信息，第三层存放用户行为信息。表层级结构可以根据团队内部的数据接入规范进行调整，采用统一的结构。

⑥明确优先级

根据埋点需求的紧急程度，给每一个埋点任务标上优先级。根据上面的六个步骤，将每一个步骤需要记录的字段按照标准格式汇总到文档中，即可完成初步的埋点设计。之后，还需要与产品经理、策划人员和前端、后端工程师一起反复讨论，不断修改完善文档，直至三方会谈达成统一意见，最终埋点文档。

一般由业务方发起需求，产品经理或者运营基于自己的业务场景，明确核心指标和分析需求。在建立产品数据指标体系之初，尤其需要关注「核心」的场景，对核心指标进行优先埋点。在明确分析需求的基础上进行埋点方案设计。

由数据团队主导，召集提出需求的业务方和开发团队共同参与。既需要与需求方确认方案设计是否符合业务需求，也需要确认开发团队已完全理解业务语境，并确认需求开发的可行性。需求评审可能需要召集多次，但是必须达到需要业务方（市场、运营、产品经理等）、数据规划师（数据产品、数据分析师等）、开发三方一致，才能进入开发环节。

（如果没有专门设置数据分析岗位，可由用户体验设计师、产品经理承担，需求方承担该角色）

在方案执行环节，需要数据团队和开发团队共同进行。数据团队需在分析平台的数据管理模块中进行相应的配置，例如，在数据管理模块中，对埋点事件以及相关的变量进行配置。开发团队则根据埋点方案，确认埋点可行性和排期，进行相应的代码部署，负责埋点开发、测试和上线。

在开发团队完成开发和测试后，需要数据团队进行数据校验后再正式部署上线。数据校验时，重点确保数据触发时机正确，确保入口覆盖完全。

埋点上线后，业务方和数据团队即可使用数据分析平台，对上报的埋点数据进行监控和分析。

整个过程中三方需要相互配合，如果缺乏明确的协作流程，可能会导致埋点周期漫长，甚至漏埋错埋的结果。想要提高埋点的质量和效率，团队协作至关重要，建议明确协作的流程，并规范流程中各方的职责。

1、明确产品目标和首要问题，从深层次和具体的需求进行梳理。

2、同级页面操作和同页面多来源为一个事件，不同的操作内容和页面来源作为事件的属性进行采集。

3、在分析的初期采集少量重要的用户行为，快速获取成果。

4、核心流程尽量每一步用户行为都需要获取数据。

5、数据统计口径要确定清楚，与开发保持良好沟通，将埋点的具体采集时机传达给开发。

6、埋点结束后，需要验证数据的有无和准确性，而不仅仅是埋点是否有数据返回。

7、不要一次性全方位无死角进行埋点，工作量巨大且大量数据反而引起干扰混乱，建议分阶段分版本进行埋点。

对于数据分析的结果，要考虑是给数据结论就可以了，还是需要做成分析报告？是给数据报表就可以了，还是需要做成BI在线报表？做得越深的事情意味着需要付出更多的精力和成本，同时也需要有更高的价值支撑。在输出数据分析结果时，需要注意的是对需求交付目标把控，要和价值匹配：

（1）避免用力过度：业务只需要临时看一眼指标，竟然收到一份完整的分析报告。

（2）避免不及预期：业务期望从分析师结论建议中找到功能迭代的方向，却只收到一份结果数据的呈现报表。

所有形式的产品到最后都必须要能经得起市场和用户（客户）的检验。数据分析是帮助我们实现产品商业价值的重要工具之一，工具有效与否、好用与否，不在于工具本身，主要在于使用工具的人。希望我们都能借助此工具，更好的帮公司产品实现商业目标。

专栏作家

忻芸，人人都是产品经理专栏作家。专注于B端、SaaS产品，擅长技能用户体验设计、交互设计、用户研究、数据分析、项目管理。

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

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

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。