埋点系列2-输出埋点需求文档

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

一、什么是埋点需求文档

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

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

● 应用标识:指当前应用的唯一标识,用来区分各数据来源于哪个的应用(站点)。

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

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

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

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

二、如何写埋点文档

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。如果我们直接修改了老版本的某个埋点事件,那么该事件统计的结果可能就是不准确的。

五、写在最后

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

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

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


系列相关文章:

埋点系列(一)——埋点需求分析&设计埋点方案

埋点系列(二)——输出埋点需求文档

埋点系列(三)——埋点的框架设计及其准确性

埋点系列(四)—— 从埋点系统搭建到数据可视化落地

禁止转载,如需转载请通过简信或评论联系作者。

推荐阅读更多精彩内容