数据埋点，对于产品迭代而言，有很重要的指向意义。本文从常规埋点属性和常规埋点流程两个方面带我们认识了数据埋点。

数据埋点属于数据采集的阶段，是互联网分析业务闭环中的起点，为之后的许多日常及专题的分析提供数据源。本篇文章从两个角度来阐述数据埋点的预备知识。横向角度为，每个埋点事件可以埋一些什么内容（用户、时间、地点、方式及内容等），即埋点指标的基本属性。纵向角度为，要完成埋点操作，整个时间上的流程及顺序是如何（梳理需求、撰写需求文档、后期监控等）。

本文旨在梳理数据埋点过程中的基础知识以及流程，若有错误之处，敬请指点！

一、常规埋点属性

在日常的数据监控及分析中，也就是特殊情况发生之前，不管是作为产品、运营还是数据方都很难预料到会需要何种特殊的分析需求，自然也就没有办法预先制定好相应的特殊埋点。

这时候，常规的一些埋点属性可以帮助我们进行一些基础的观察与分析，以一次普通的付费行为来举例，常规的埋点主要可以从以下几个属性来划分：

1. Who（用户）：

主要目的是通过该属性将产品不同的付费用户区分开。主要有以下两种方式：

• 设备：主要包括移动端（IOS、安卓）及PC端。
• 账号：可以是手机号、邮箱、微信号等用以登录的识别号，关键是不可重复性，即一个账号只代表一个用户。

以上两种方式都能达到将识别并区分用户的目的，至于如何选择，主要取决于当前产品如何定义唯一用户。例如某APP是一个强登录型产品（不登录将无法使用），那么账号本身可以完全覆盖并区分所有的用户，因此该埋点字段可设置为“user_id”。反之，如果是一个“路人”也可以使用的产品，那么设备+账号的埋点设置可能更加适合，即同时加上“user_id”与“device_id”两个字段。

2. When（时间）：

即用户于何时发生该付费动作。对于时间的上报主要有以下两种方式：

• 客户端时间
• 服务器时间（Unix时间戳）

在涉及跨时区数据的时候，一般使用全球统一的Unix时间戳来上报，在用户属性的后方再加上“timestamp”。

3. Where（场景）：

即用户在何处发生了该付费动作。主要可分为：

• GPS：指的是通过GPS定位获取当前设备的经纬度信息。但通常仅仅获取到经纬度信息对于产品或运营的分析是意义不大的，很少有人关注“东经116°，北纬39°”的用户日均使用某APP的时长是多少，而是说“北京地区”用户的使用情况如何。可见要将其利用起来，还需要将其转化为国家、城市、街道等人文地理信息，目前大部分产品都是通过调取API实现的。
• IP：通过IP地址来定位当前使用的位置，一般比较粗略。
• 用户自定义。当使用场景涉及异地选址时，用户的实际定位可能并不能真实反映消费意向，例如异地点外卖、异地订房等，因此对于一些涉及此类场景的APP来说，在获取常规定位信息的同时，再加上对用户自定义位置的埋点，相信也是有一定意义的。

不同的位置获取方式可根据当前业务情况选定。

4. How（方式）：

即用户是通过何种方式发生的该付费动作。主要包括：

• 设备类型：移动端 or PC端。
• 操作系统：安卓 or IOS or Windows or Mac OS。
• 版本号：各产品不同的版本号。
• 网络类型：4G or 5G or Wi-Fi。

以上几个是比较基础的常用属性。也可根据产品的特殊需求增加相关属性，例如，对于修图类软件来说，屏幕分辨率的高低可以很大程度上影响用户的使用体验，因此可将其加入常规属性进行埋点。

5. What（行为）：

上述的四种属性描述了用户在何时何地以何种方式发生了此次付费行为，而该环节它描述了用户究竟购买了什么。主要包括：

• 购买的类型。实物 or 虚拟服务，进一步还可以分为具体的类目是什么。
• 购买的名称。
• 购买的数量。
• 付费金额。
• 付款方式。

这几项都是比较基础的属性，可根据不同的业务需求进行添加。

上述关于who、when、where、how、what的五个维度涵盖了基本的使用场景，为日常监控产品数据提供了基本素材。

二、常规埋点流程

1. 收集需求，梳理指标

（1）梳理相关部门的埋点需求，将其指标化

• 明确埋点目标：埋点主要为了实现什么目标？能够满足产品部门的什么需求？
• 其他业务部门的需求：同时，结合其他部门例如技术、运营部门等需要获取的一些埋点需求。
• 确定埋点指标：梳理上述所有需求，确定最终需要埋点的指标。

（2）建立流程图，规范细节

• 建立用户行为流程图：根据梳理好的需求，建立详细的流程图，例如用户从点击广告进入，一直到购买页面，具体可能经过哪些步骤都需要整理清楚，这样能有效避免漏埋等情况。
• 事件触发的时机：根据不同事件，定义好该事件的触发时机，例如购买事件是按照点击“购买”按钮还是按照出现“付款成功”计算，这就涉及前面对用户行为流程图的详细规定，具体的规则需要不同部门之间认真商讨，达成共识。
• 埋点属性的设计：埋点的属性与上文4w1h的属性范围相对应，主要描述的是关于每一个埋点的事件，是由谁在何时何地以何种方式完成了什么。

2. 形成数据需求文档（DRD）

在梳理清楚上述细节之后，假定一个用户从浏览商品列表到下单购买的场景，参考上述4w1h的属性，再根据不同的埋点事件进行选取及调整，一份较为完整的数据需求文档能够应运而生了，例如下图：

3. 上线后，复盘效果

（1）验证所有指标能否被正确采集

• 主要负责保证埋点数据的正确性及准确性，如有异常、缺失等情况，则需及时反映并进行调整。

（2）监控、管理当前埋点指标的效果

• 在产品运行的过程中，会逐渐体现出不同功能模块的业务复杂程度，因此埋点的需求也会随之产生一定的调整，能否尽早地调整各个埋点的计划以适应不同的分析需求，这就需要产品及数据部门更加敏锐的洞察力了。

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

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