如何科学地输出一份的埋点需求文档？

Thea 2023-07-27 01:26:16

《数据埋点，一次讲个够》系列文章的第二篇，讨论用户行为数据采集工作的核心——埋点模型。

主要讨论：

主流的埋点模型–事件模型
按照事件模型的思路，如何设计埋点

下面来聊一聊埋点模型：

一、事件模型

埋点体系中一个非常重要的角度是埋点模型，它决定了我们以什么样的架构收集用户行为信息。

换句话说埋点模型反应的是数据采集的世界观，我们用什么样的视角去理解用户行为；比如，以产品的视角，用户和产品的交互可以理解为浏览了页面、点击了按钮，对于页面浏览的行为，埋点会记录用户id、ip、进入页面时间、页面名称等等，然后把这些数据单独落到一个表中，后续我们基于这张表可以查询 PV、UV 这样的指标。

对于点击行为，埋点会记录用户id、ip、点击时间、按钮名称、按钮所属页面名称，这些信息会落在另外的表中，后续基于这张表可以查询点击某元素的用户数等指标；这样的埋点模型是基于产品视角的，我们把用户对产品的操作分为几种类型，针对不同类的行为设置不同的字段；这是 PC 时代的设计方式，埋点能采集到的内容相对固定，能统计的指标也比较有限，也是 PV、UV、跳出率、停留时长这些，和业务数据打通比较困难，笔者就职的上一家公司，就采用这种模型来设计埋点。

目前主流的埋点模型是「事件模型」，市面上提供用户行为分析服务的绝大多数厂商都采用这种模型，比如，GrowingIO、神策、诸葛IO、TalkingData、友盟、Mixpanel等。

所谓的「事件模型」，其实是「事件 – 用户模型」，简单理解，我们把用户的行为记录为事件和用户，分别存在事件表和用户表中，事件表中记录 Who、When、Where、What、How，即谁在什么时间，什么地点，以什么样的方式，做了一件什么样的事，用户表里面记录了某个用户有什么样的属性特征，比如年龄、性别等。

如何科学地输出一份的埋点需求文档？

在我看来，事件模型有三个优点：

1）抽象能力强，能全面、精细地描述的用户行为

相比于 PC 时代的页面模型，事件模型表达能力更强，能刻画更多类型的用户行为；因为，对于页面模型的埋点，在最开始的时候已经固定好了采集哪几种类型的行为，比如页面浏览、按钮点击、push点击等等，不同类型的埋点也确定了其中会采集哪些字段，如果后续业务同学想在某个埋点中新增个性化的字段是比较麻烦的。

针对添加个性化字段的需求，一种解决方式是，我们在每类埋点中都预留一个 valvus 字段，以 k-v 的形式来记录此类埋点下所有个性化的字段，这样是可以解决问题，但成本比较高：

一个字段中存了多个信息，埋点元数据的管理成本增加；
这样的字段非常灵活，难以约束业务方按照约定上报数据，有可能会出现一个 values 字段包含了上千个k-v，数据质量难以把控；
在后期处理数据时，需要做额外的解析工作。另外，对于页面模型，如果后面要再采集一类埋点，需要重新设计一类埋点，后面的表、查询模型都要重新开发，非常的不灵活。

2）可打通业务数据和行为数据，实现更精细的用户行为分析

要把业务数据放入页面模型中是比较困难的，而对于事件模型，只要这个业务过程是有用户参与，就可以把业务数据表示为谁在什么时间、什么地点、以什么样的方式、做了一件什么样的事；随着用户行为分析越来精细，越来越深入业务，打通业务数据和行为数据已经是一件必要的事了，而事件模型在数据采集阶段就解决了这个问题。

3）容易理解，埋点设计起来相对容易

事件模型把用户和用户行为描述为「谁在什么时间，什么地点，以什么样的方式，做了一件什么样的事，这个用户有什么样的属性特征」，非常贴近自然语言，在很大程度上降低了模型的理解难度。

鉴于业界主流已经从页面模型切换到事件模型了，建议在构建埋点体系时尽量采用事件模型。后面的埋点设计也会以事件模型来说。

二、设计埋点

设计埋点是按照埋点模型把将业务需求翻译成为开发能懂的语言。

如果采用事件模型，翻译过程可以概括为四个步骤：业务分析、定义指标、事件设计、属性设计。

首先，需要梳理业务过程，然后针对细分的业务场景定义能够衡量业务目标的指标，确定埋点的内容和范围；之后就可以按照事件模型设计事件，以及事件下的属性了；比如，来看一个电商搜索的场景来看如何进行埋点设计。

下面用电商搜索场景为例，说明如何进行埋点设计：

1. 业务分析

梳理业务流程，以及每个业务流程下的用户路径和各种细分场景。

一般思路是——根据用户在产品上具体的操步骤，定义用户行为路径；比如在电商搜索的场景中，核心操作步骤是用户发起搜索/ 点击搜索结果/购买商品，那么就可以把业务分解为「输入关键词搜索」、「点击返回搜索结果」、「购买商品」，在「输入关键词搜索」环节；可以通过输入的关键词，分析用户对不同商品的需求情况，在「点击返回搜索结果」环节，可以评估不同关键词运营状况是否健康；譬如，是否存在没有搜索结果返回的关键词，或者用户点击的搜索结果排在很后面等等。

2. 指标拆解

完成业务拆解之后，需要结合业务分析目标思考，每个细分的业务过程可以有哪些指标来分析。

在电商搜索的场景中，常见的分析是视角是：

用户对不同商品的需求情况如何，相关的指标是「不同关键词的搜索次数/人数」；
不同关键词当前的健康度如何，相关的指标是「搜索结果点击人数/次数」、「搜索结果点击率」、「不同关键词返回结果数」、「搜索结果点击位置均值」等；
用户对商品的需求是否都能得到满足，相关的指标是「不同关键词返回结果数」、「关键词返回结果点击-成功购买的转化漏斗」，此时，我们就完成了指标定义。

3. 事件设计

在上面的步骤中，我们定义出了「不同关键词的搜索次数/人数」、「搜索结果点击人数/次数」、「搜索结果点击率」、「不同关键词返回结果数」、「搜索结果点击位置均值」、「关键词返回结果点击-成功购买的转化漏斗」等要统计的指标。

事件设计，其实就是把指标中设计也行为提炼出来；回来电商搜索这个例子中，我们可以提炼出七个用户行为，分别是：「点击搜索按钮」、「返回搜索结果」、「点击搜索结果」、「浏览商品详情页」、「商品加入购物车」、「确认订单」、「支付订单」。

在实际的设计中，有一个重要的问题需要考虑：针对某个具体的行为是否需要设计单独的事件，比如「点击搜索按钮」这个行为是否可以用「APP 元素点击」这个事件采集，还是需要有一个单独的「点击搜索按钮」事件去采集？

在这个问题上，有两条经验分享：

1）对于重要的点击事件，建议单独设置事件采集，而不要使用「APP 元素点击」「Web 元素点击」等这样的全埋点事件。

重要的点击事件往往需要记录更全面、更精细的字段，需要根据具体的点击事件的类型以及个性化属性，进行归类采集；常见的点击事件有 Banner 位点击、ICON 点击、频道 TAB、功能重要操作点击等事件。

2）有两个相似的行为，如「信息流广告点击」和「Banner 广告位点击」这两个行为，由于要记录较多丰富的属性，已确定要设置单独的事件；但这两个事件采集的字段非常相似，都需要采集广告 id、广告名称、排序、所属页面等字段，是按照下面的 a 方案采集，还是 b 方案采集呢？

这里需要回到业务，如果在后续的分析中业务需要将信息流广告和 Banner 广告汇总起来看总的广告点击次数/人数；那需要按照 a 方案合并设计，如果后续业务上不会合并看数据，建议按照 b 方案分开设计（其实 a 方案也能满足分别统计两种广告的需求，不过查询要麻烦一些）。

如何科学地输出一份的埋点需求文档？

另外，在事件设计时还需要说明数据的采集时机以及在哪个端采集。

举个例子，我们设计了一个「信息流条目曝光」的埋点事件，如果不对采集时机加以说明，研发很有可能在信息流条目只在屏幕上露出 50% 时就采集上报数据，而业务需要的是信息流条目在屏幕上完全露出时才采集上报；于是，在事件设计时需要描述清楚在什么样的情况下会触发事件数据的采集。

从事件上报的触发逻辑上面来讲，可分为前端触发上报、前端获取后端汇总结果后上报、后端触发上报、后端获取前端属性后上报四个比较类别，如下图所示。

如何科学地输出一份的埋点需求文档？

以淘宝下单流程中的「购买成功」为例，详细介绍下单埋点事件的触发逻辑类型。

例：以购买成功为例看事件的触发逻辑。

如何科学地输出一份的埋点需求文档？

前端触发就上报：点击「立即付款」按钮就触发，这是最常见的前端采集方式，如果业务方是想了解「用户是否有意愿支付」，那么当用户点击「支付订单」这个按钮或者发出支付请求就采集即可。

前端获取后端汇总后上报：这种方式一般是由于除了记录用户操作外，还需要获取用户操作的结果；比如需要收到后端结果的返回，以判断用户是否支付成功，以及失败情况下具体的报错原因，那么其触发机制必须等到前端拿到后端服务器处理结果后，再进行上报。

后端触发就上报：这种方式是指后端处理后直接上报，比如后端处理付款请求出结果时直接后端触发上报；采用这种方式的主要好处是数据不会出现漏报，但也由于是后端直接上报，基本是拿不到用户的设备终端及软硬件环境属性的，比如用户在支付时使用的是什么设备、网络环境是什么等信息。

后端获取前端属性且触发上报：这种情况就是为了解决后端埋点的软硬件环境属性问题，让前端在用户点击「立即支付」时，将相应的属性一并传回服务器，服务器发生「支付成功」时，带上相应的前端属性上报数据；当然这种方式理论上时数据准确度、完备性最高的，但同时这种方式的采集成本会比较高，意味着所有端的前后端接口需要做变更，建议是只在数据准确性、前端属性获取两个需求都非常强烈时采用。