编辑导语：对于产品来说，用户在你的产品里怎么使用、使用了什么板块、路径等等都是需要从埋点中进行监控；一个科学有效的埋点方式，可以一定程度上提高渠道转化，并且改善产品；本文作者分享了关于埋点事件的结构化设计方法，我们一起来看一下。

一、埋点的坑

近期负责了一款APP的数据相关工作。该APP是一个自制游戏内容产品，上架了很多个独立主题的小游戏，并按游戏的类型，分为5个类型。

为了解整体数据情况，我向数据开发提出了一个数据提取需求：以周为单位，统计最近一年每个类型的游戏累计被打开的次数。

本以为几分钟就可以拿到数据，但开发1个小时后才给我结果；经过详细了解，发现是因为数据埋点存在极大的坑，导致的数据统计效率低下。

埋点需求见下图：

通过这套方案采集到的数据，要实现按类型统计的需求，有2个问题：

    每一个游戏，都单独定义了一个打开游戏事件。也就是说，打开不同的游戏时，触发的是不同的事件；要想统计每个类型的游戏累计打开次数，必须先按事件名逐个统计每个游戏的打开次数。
    只采集了打开某个游戏，但游戏所属分类是没有采集的；要统计每个类型游戏累计被打开的次数，就需要对照游戏信息表，查到每个游戏的所属类型，再按游戏的所属类型，对打开次数做一次累加。

整个数据提取过程如下图所示：

每一个步骤都无法省略，因此，数据提取才耗费了很长的时间。

二、带来的问题

在这个埋点方案中，主要有两个问题：相似行为未做聚类抽象、事件信息采集不完整。

1. 相似行为未做聚类抽象

相似行为是指用户操作过程和目标高度相似的行为，如用户分享一篇文章，有分享给微信好友、朋友圈、微博。

将相似行为都定义为一个个独立的事件，会导致以下2个问题：

    埋点事件数量很多，开发和维护成本高。APP中有1000个游戏，就对应了有1000个打开游戏事件；只要增加新的游戏，对应的埋点代码都需要单独开发，并在表格中进行维护，一旦没有及时维护，或因员工离职时交接不到位，可能导致事件管理出现混乱，如重复事件、无效事件等。
    数据统计和分析效率低下。当需要统计全部游戏的打开次数时，必须要先分别找到每个游戏点击对应的事件，然后逐个统计每个事件的触发次数，再做一次汇总。

聚类抽象是指用一个抽象的主题来概括多个相似信息。如分享给微信好友、朋友圈、微博3个行为，都是在描述用户分享文章的行为，可以聚类抽象为“分享文章”。

将相似行为聚类抽象后，原本1000个游戏的打开事件减少为1个，事件数量大幅度降低；统计全部游戏的打开次数也能一步完成，数据统计和分析效率提升一倍。

2. 事件信息采集不完整

一个用户行为，往往可以从多个维度来描述，每一个描述维度，都是一个信息，这些信息，有些是有分析价值的，有些没有；埋点采集到所有具备分析价值的信息，才是完整采集事件信息。

如果我们在梳理埋点需求时，没有完整采集信息的意识，或考虑不全面，就很容易遗漏，导致相应的分析无法进行。

打开游戏时，所在页面是事件相关的信息，统计用户打开游戏时所在的页面，可以分析不同页面对游戏的引流效果，指导运营工作方向。

若没有采集该信息，就无法统计在某个页面打开游戏的次数。

三、解决方案

很明显，为每个独立的、最小颗粒度的用户行为单独定义一个事件，不是一个好方法。那么，我们应该怎么设计埋点事件呢？

答案是采用“事件-属性-属性值”的结构，对事件进行多维度描述。

结构化是指一个完整的埋点事件，分为事件、属性、属性值三层，包含一个事件定义（用户行为）和若干个属性定义（描述用户行为的属性）。

下图是打开游戏事件的结构化设计案例：

点击游戏图标打开游戏的行为，定义为“打开游戏”事件；该事件有2个属性，分别为“游戏分类、游戏ID”；游戏分类指游戏所属的类型，其属性值为“A、B、C、D、E”；游戏ID是唯一识别游戏的编号，其属性值为“001、002、003···999”。实际使用时，还可以增加更多属性。

游戏ID属性，将相似行为聚类抽象为一个事件，即使有新的游戏上线，也只需要增加一个属性值，事件数量从1000个减少到1个，开发和管理成本大幅度降低。

增加的属性，使采集到的行为信息更完整。通过“游戏分类”属性的值，即可统计每个类型的游戏累计被打开的次数，满足更多数据分析需求。

1. 属性的定义

    一个用户行为，通常可以从多个维度进行描述，描述事件的维度，称之为“事件属性”，简称“属性”；每个属性，都有若干个值，为属性值。

用户打开游戏，如果从玩家性别维度描述，分为男、女；从玩家年龄维度描述，有15、16、17、18等，从游戏分类维度描述，分为A类、B类···

“玩家性别、玩家年龄、游戏分类”就是用来描述“打开游戏”事件的属性。

“男、女”是属性“玩家性别”的属性值，“15、16、17”是属性“玩家年龄”的属性值，“A类、B类”是属性“游戏分类”的属性值。

从上一篇文章中，我们已经知道，数据埋点能采集4w1h多个维度的信息。

从不同的维度对事件进行数据分析，要么能指导产品的迭代，获得更高的用户价值；要么能更好地达成业务目标，获得更高的商业价值。

因此，在数据采集时，不仅要采集事件本身，还要采集事件的属性信息。

游戏被打开次数的性别分布，体现了不同性别的用户对该游戏的兴趣高低；如游戏灰度发布的3天内，选取了男女用户各1000人推送内测邀请，其中900个男性用户打开了游戏，而女性用户仅10人，说明该男性用户对该游戏更感兴趣。

为了在尽可能少消耗推送次数的条件下，让该游戏获得更高的打开率，游戏上线时，运营只给男性用户全量推送了游戏。

2. 设计方法

结构化事件设计的关键，是定义好事件、触发机制、属性、属性值类型、属性值5个要点。

1）定义事件

数据埋点是要采集对数据分析有价值的过程数据，因此，需要先根据数据分析需求，找出对应的用户行为，再抽象出事件名。

数据分析需求是目标，确定了目标，才能找到能达成该目标的用户行为；事件名是对该事件的概括，帮助相关同事统一沟通话术和名词定义，提高沟通效率。

需要分析用户打开某个游戏或某类次数、人数，对应的用户行为是用户点击并打开游戏，可以将该行为抽象为“打开游戏”事件，作为内部沟通统一名称。

2）定义触发机制

埋点代码被触发执行的条件，即为触发机制，通常取决于事件的定义和目的。如点击了某个元素、打开了某个页面、展示了某个内容等。

“打开游戏”事件中，打开游戏的定义，是点击游戏图标，并进入游戏界面，事件的目的是要准确记录打开游戏的行为。

因此，当用户通过各种方式（点击游戏图标、点击推送消息、点击进入游戏按钮等）进入游戏界面时，才触发事件。

只有在正确的时机触发埋点事件，才能准确采集用户行为。触发时机错误，必然导致数据不可信，失去分析价值。

若以“点击游戏图标”为“打开游戏”事件的触发机制，就遗漏了其他两种打开游戏的方式带来的行为记录；同时，游戏被点击时，可能未完成下载，此时点击游戏图标，并没有打开游戏，但也被采集为一次打开游戏。

最终无法分析几种打开游戏方式的次数分布，也不能准确评估游戏真实的消费情况。

3）定义属性

梳理事件的属性，主要有两种方法：梳理事件的分析需求、寻找事件内部的分类维度。

梳理事件的分析需求：

不同的事件，分析需求不同，需要采集的事件属性也不同。因此，需要先梳理事件的分析需求，再针对性地寻找能满足该需求的属性。

“打开游戏”事件中，需要分析不同游戏被打开的次数，以验证游戏的受欢迎程度。如果在触发“打开游戏”事件时，采集被打开的游戏ID，在分析该事件时，即可通过“游戏ID”统计不同游戏的打开次数。

寻找事件的分类维度：

事件是对用户行为的抽象，本身还可以从不同的维度来分类，这些分类维度，也可以作为属性来描述事件。

从游戏的获取方式维度，可以将游戏分为付费游戏和免费游戏；为了统计付费游戏和免费游戏的打开次数差异，可以将“是否付费游戏”作为一个属性。

4）明确属性值类型

找到需要的属性后，还需要明确属性的值类型，如枚举型、字符串型、布尔型、数值型。

游戏ID是一串数字，如008，是数值型；游戏分类是可以穷举的选项，是枚举型；是否付费游戏是只有2个选项，是布尔型···

不同类型的属性值，取值来源和储存形式都不同。定义属性值类型，可以帮助相关同事理解埋点需求，并合理使用。

枚举型的属性值，通常是事先穷举的若干个值，存储时通常用数字替代，使用时再转化成真实的内容。

布尔型的属性值，只有2个值，存储内容为0和1。

5）给出属性值

定义好属性值类型后，再根据不同的属性值类型，给出对应的属性值或示例：

    枚举型：穷举所有值；
    字符串型：给出示例，并约定最大字符长度；
    布尔型：给出值名称；
    数值型：给出示例，并约定最大字符长度。

属性值或示例是研发编写埋点代码和测试的标准，帮助开发理解埋点需求。

研发不理解业务的前提下，可能都不知道游戏分类是什么，也不清楚有哪些分类。但当他看到穷举出来的属性值时，就能立刻理解。


3. 建议：整理公共属性

在梳理事件属性时，我们会发现有一些属性是大部分事件都需要采集的。如每一个事件都要采集发生时间、用户ID、设备类型、APP版本···

如果每一个事件都需要将这些属性在数据需求文档中列出来，就会带来大量的重复工作；因此，可以将这些属性定义为公共属性，即每个事件都默认需要采集的属性，单独整理在一个表格中。