数据埋点方案——以内容产品为例

1 埋点与定义

数据采集，就是采集相应的数据，是数据流的起点，采集的准确性和全面性直接决定数据的质量，影响后续的所有环节。埋点是采集数据的重要来源。

1.1 什么是埋点

埋点是（用户行为）数据采集领域的术语，学名叫做事件追踪（Event Tracking），主要是针对特定用户行为或事件进行捕获、处理和发生的相关技术及其实施过程，如用户点击某个按钮的次数、阅读某篇文章的时长等等。

埋点是一种常用的数据采集方法，它是为了满足丰富的数据应用而做的用户行为过程及结果记录，是数据的主要来源，采集的数据常常用于分析产品的使用情况、用户行为偏好等，于是延伸出AB测试、用户画像、用户推荐系统等数据产品。

把埋点体系作为数据中台或 BI 体系的重要组成部分及其好处 埋点系统和数据仓库、分析体系、预警系统等子系统一样，需要放入整个公司的业务体系和数据体系里，方便统一规划。 首先，可以把行为数据作为数据体系的一部分进行整合。行为数据，换一个角度看也是一种业务数据，这种数据在业务系统里无法采集。建议把它作为一个数据源，方便把整个用户行为数据关联到业务或外部数据。 其次，可以把此时此刻的用户数据特征作为属性补充行为数据。整个数据体系中，有些数据在前端埋点时无法采集。比如在做某些优惠券逻辑时，只会传一个 ID 到前端页面上，实际再去埋点时，也只能拿到这些 ID 信息，其他无法采集。解决这个问题有很多办法，但通过前端业务侧解决的方式，通常风险比较大，因为要考虑接口设计、性能及各种并发问题，如果把这些数据问题放在业务侧，将会受到一定的阻力。而如果通过数据侧解决会相对容易，比如把 ID 采集回来后，它的优惠价格、历史信息及其所承载的数据含义等信息，在数据侧都可以直接关联。

1.2 埋点的类型

根据目前常见的数据埋点形式，可以将数据埋点分为全埋点（也可称无埋点）和代码埋点（自定义埋点），后者分为前端埋点与服务器埋点。

常见的数据埋点形式

根据埋点技术还可分为Web埋点/JavaScript埋点、App埋点、接口埋点。

2 埋点设计

2.1 注意点

1. 埋点规划。在对埋点需求进行规划时，切忌一次性完成大量需求，最好对需求进行优先级排序处理，这样有助于管理产品文档，如果一次性处理几百个埋点，加上涉及到跨部门协同，撰写时难免会有纰漏，所以埋点规划的节奏非常重要。

2. 埋点尽可能全面和必要。当我们想到用某些数据进行机器学习的时候，才可以不用再去埋点，也不会损失历史数据的价值。全面的关键点是以事件驱动，需要上传的信息包括事件本身和触发事件的用户信息，以及触发元素本身所在实体（对于客观世界物体的抽象）的信息。 必要是指只有能够产生业务意义的事件及相关信息才需要上报。

3. 用户属性。设计埋点时要考虑用户属性设计。设计用户属性时，需要遵循一个最基本的原则，就是通过**事件分析系统、用户标签、用户画像系统计算出来的东西，就不要单独上报埋点。**比如想要获取用户近几日的消费单数，或是确认他是否为 VIP 用户，这些数据需求都可以通过事件计算出来。如果再单独埋点，不但会浪费开发资源，而且上报来的结果远不如整个系统内环计算来的灵活。 需要注意的是，有两种属性非常值得埋。一个是静态属性，比如说用户年龄、性别等，这些静态属性无法算出来，很有埋点的必要。另一个是通过算法和数据挖掘产生的挖掘标签，也值得单独埋点。

4. 了解预置属性。建议通读了解预置属性，一方面是防止事件所采集的属性，跟预置属性有所重叠。另一方面，通过预置属性，可以了解各端的数据特性，比如小程序的特性如何，它在封闭环境里可以返回哪些数据、不返回哪些数据？比如 H5 特性、客户端特性等等。

5. 确定节点口径。通常，一个事件会有很多下沉节点，比如某个按钮的点击事件，从用户在 APP 层的点击，到 APP 去请求应用接口，到服务器去确定接口，接到了请求后，到业务侧后台系统处理这个请求时是否成功，再到最后是否能把结果成功返回给客户端。 因此࿰