【埋点学习】03 埋点需求文档：一份规范的埋点需求文档该如何写？

原创：Luluzeng 2020-03-20

上一节章《埋点需求分析&设计埋点方案》已经说明了什么是埋点，埋点需求分析、数据指标、常见的埋点事件等基本概念。本周主要输出整理埋点文档的思路。

埋点文档是一个对我们之前埋点需求分析结果的方案落地，上一章里，我们知道埋点分为前端埋点和后端埋点，我们常说的埋点文档是指前端埋点文档，通常由产品经理进行梳理。

首先，埋点文档没有一个固定结构。不同平台，不同渠道，不同公司对于业务需求的不同，所产出的埋点方案都不同。但是通常需要包含：

● 应用标识：指当前应用的唯一标识，用来区分各数据来源于哪个的应用（站点）。

● 页面名称：即当前埋点所属的页面，有了这个页面位置，才能知道这个埋点属于哪个页面的数据。通常我们埋点文档中是根据页面来划分的。

● 埋点位置：即需要添加埋点的位置信息，比如一个收藏按钮，一个分享按钮，某一指定位的曝光区域等等。

● 埋点标识：每个埋点的位置有一个埋点标识，用来标记这个位置，有且仅有一个，不能出现标识重复的情况，不然统计到的数据一定有重复。

● 埋点参数：参数就是除了点击这个位置带来的点击量，你还想看到哪些信息。比如点击支付按钮时，需要附带支付方式，支付金额，支付流号等信息。

1、选择数据平台

目前大多中小型公司都会选择第三方数据平台，少部分公司会自建数据平台。目前知名的第三方平台有：国外的Google Analytics、Mixpanel，国内的有友盟+、Talkingdata、百度统计、诸葛IO、神策数据，还有专注于游戏领域的dataeye等。

各平台都能基本满足业务需求，各有优缺点，具体选择哪家需要各自进行权衡。我之前仅用过友盟、百度统计和诸葛IO，以上3家来讲，我更倾向于友盟，除了数据统计，还提供推送服务、社会化分享、用户反馈，功能十分强大。也有很多人推荐TalkingData，界面很清晰，功能也好用。

2、查看平台技术文档

选择好平台后，我们需要查看平台的技术文档。比如进入TalkingData的官文点击App集成文档，就可以查看相应的技术文档了。

Talkingdata

这需要开发按照操作说明把SDK集成到我们的APP中，而产品需要输出埋点文档。

如上TalkingData的自定义事件的文档说明，其中包含代码事件和灵动事件。TalkingData的灵动事件，是一种无需预先埋点，随时可以按需配置即可实现的自定义事件追踪方式。在正确集成SDK后，任何时候通过报表页面设置，就可以实现自定义事件追踪。

代码事件是通过在代码中对每个需要追踪的自定义事件调用接口，传入相应参数从而实现对自定义事件追踪的方式。自定义事件需要定义的信息有：EVENT_ID(自定义事件名称)，EVENT_LABEL(自定义事件Label)，Map（自定义事件的参数及参数取值Key，Value）。TalkingData自定义了标准事件，比如下单、成功支付订单、浏览商品、加购、查看购物车。

一般地，如果所有事件都需要传输相同的参数，可以设置全局的Key-Value，这些Key-Value自动会添加到所有自定义事件中。比如操作系统（Android、iOS），渠道（小米，华为，app_store）、应用版本等。

设计事件大概分为三类：

● 常规通用事件：APP激活、APP退出、页面浏览、点击事件等

● 重要操作事件：Banner点击、icon点击、频道Tab等重要操作点击、某推荐位的曝光事件等

● 业务流程事件：注册流程、忘记密码流程、购物流程等

总之，不管采用第三方数据平台，还是自建的埋点平台，我们的方案中一般都采用Key-Value的形式，Key一般表示某个事件，Value代表相对应的值，一个Key可以对应一个Value或多个Value。埋点过程中，同种属性的多个事件要命名成一个事件ID，并以Key-Value的形式区分；不同属性的多个事件要命名为多个事件ID，此时尽量不用Key-Value的形式埋点。

事件（Event）、参数（Key）、参数值（Value）关系如下：

3、埋点文档实例

先举个简单的栗子，比如我们想要知道新上线的【国美官方入驻】活动入的点击情况，在京东有以下3个地方可以进入该活动页面：

这里我们设置的参数是“国美的入口按钮A“的点击页面（Page），参数值有3个，一个从全球品质购物节页面点击(Page1)，一个从排行榜点击(Page2)，一个从家电品质盛典页面可点击(Page3)。根据这个思路，我们就可以做这样一个简单的埋点方案了。Key字段表示分析的维度，Value是不同维度下对于的值。即便以后增加活动入口，也只用增加value值即可。

获得埋点文档如下：

好了，按照这样就能顺利的统计和维护数据了。但是我们思考一下上述思路的短板是什么呢？很明显，我们发现如果要给【国美活动页】新增一个页面很容易，添加一条value就好了。但是如果PageA页面新增一个XX活动按钮B呢，我们就得新增一条功能了，叫“统计XX活动入口按钮B的点击情况”，比如这样：

这样看起来没有问题，但是这样会不断增加事件ID，不但工作量越来越大，后期维护成本和处理数据的成本也很高，所以通常我们不建议这样做。

实际上我们通过归纳总结，可以这样来思考：将不同维度（页面、元素）分开，这样根据不同维度（Key）和不同参数（Value）组成事件ID。这样有组织的进行归纳，可以将不同维度下的不同参数有效区分出来，即便以后增加活动页面入口，或者增加增加元素类型，都只需在当前Key-Value的基础上对应的维度上增加新值就可以了，这样再来看下思维导图，是不是就清晰了一丢呢。

按照上面这样从不同维度去设计的思路，输出埋点文档如下：

时隔一周，京东APP排行榜页面已经进行了新的改版。这就呼应了我们上篇文章说的埋点的作用：改善产品。我们根据调整后的页面对比之前的页面，反推一下该页面通过怎样的数据埋点，可能产生怎样的数据结果改成目前这样的。

1、改动点1：展示界面调整。新增一个tab叫【精选】，跟以前的页面相比，从手机一屏幕来讲，以前只能看到4个商品。现在我们可以看到3个热卖榜，共9个商品，首页共可以展示90个商品。

分析该页面：我们可以猜想，可能是由于在排行榜首页的商品点击率都集中在榜单前三名。虽然展示了1~30名排行，但是对于用户来说，他并不关心所有该榜单类目的东西。所以我们反推点击商品这个事件上，应该有个参数（Key）是排名，参数值（Value）是排名位数。

2、改动点2：首页数据源调整。之前的首页的商品都从属于一个“面部精华”的类目，比如面部精华的Tab下，就是面部精华热卖榜，进口面部精华热卖榜，韩系面部精华热卖榜。调整后的首页数据源扩展到了其他类目，比如面部精华热卖榜、口红榜、耳机热卖榜。

分析该页面：为什么要加入其他分类的榜单呢，可能是因为该页面统计到用户点击Tab标签选项卡的频率较高，且在其他类目下浏览的时长较多。证明用户还对其他分类的产品感兴趣。由此我们可以知道应该有点击Tab标签这个事件，参数（Key）是标签名称、该标签下停留时长（点击标签记录t1，切换其他标签记录t2，t2-t1）。

基于当前页面，用代码埋点的方式，大概输出的埋点文档长这样：

在实际开发中，我们还需要根据公司要求或者场景要求添加部分字段，比如上线日期，英文变量名、中文显示名等等，都是根据具体情况来的。正如前文说所，埋点文档没有一个定式，但是都遵从基本原则。

在整理完埋点需求表格后，我们已经踏出重大的一步了！接下来，我们需要发起需求评审。正确表述目的，让其他产品人员、开发、测试都提出自己的意见。有时候他们的意见能帮助我们完善埋点需求。

评审完成后，顺利经过以下步骤，就可以上线了。然后在我们的埋点文档中记录下上线时间、状态等重要信息，以后有增加，就继续更新文档即可。

这里需要注意的是埋点文档不同于一般的PRD，PRD是针对本次迭代的功能进行描述，而埋点文档需要基于历史所有埋点，所以我们一般不会对原有埋点数据进行直接删除或修改。如要删除某个埋点，在状态写明“已停用”及”停用时间“即可。

前端代码埋点有时依赖App发版来生效，我们无法保证用户使用的版本一定是最新的版本，可能他还在使用老版本APP。如果我们直接修改了老版本的某个埋点事件，那么该事件统计的结果可能就是不准确的。

我们平时在网上会看到各类的大数据相关的架构图，有的从产品层面出发，有的从技术层面出发。其中所分析的数据源，埋点数据都是重要的一个成员。埋点数据不仅是用户行为分析、用户画像分析的基础，也是我们建立数据仓库的基础之一。

随之我们可以思考，这些各类数据最终会存储到哪里呢？怎么清洗、转换，怎么用于用户画像分析呢？随着公司业务的不断发展，我们累积了大量各种类型的数据，加以利用，我们能获取商机，提升公司业务竞争力。不加以利用，那么它们只是躺在数据库中的冗余。

以上是我的一些个人学习和工作经验，没有试卷，也不是标准答案，如果对您有帮助或启发就再好不过啦。