事件-用户模型
本篇为 如何做好埋点设计 的补充。在上篇文档中，存在着思考过程和设计过程无法通用的情况。故新开一篇来进行详细说明。
数据观
产品视角
在埋点体系中，有一个非常重要的视角是埋点模型 ，它决定了我们以什么样的架构去收集用户行为信息。埋点模型反映了数据采集的数据观。它暗含了一个问题：
我们应该用什么样的视角去理解用户行为？
如果我们的数据观是产品视角，使用的是页面模型，那么用户的交互行为就包括了页面浏览、点击按钮：
- 对于用户浏览页面的行为，我们设计的埋点会包括用户ID、IP、页面停留时长，页面名称等。把这些数据归入表中，我们后续可以通过这张表查询诸如页面浏览量（PV）和用户访问数（UV）等数据。
- 对于用户的点击行为，除了用户ID、IP，埋点还会记录用户的点击事件，点击的按钮名称以及按钮所属页面的名称。这些数据会落入另外一个表，我们后续可以基于这张表查询点击某元素的用户数（Users）等指标。
在 PC 时代，这是产品常用的埋点设计方式，也即之前提到过的用户和事件视角方法。在这种埋点设计视角下，产品收集到的数据相对固定，能统计的指标也非常有限，比如 PV、UV、页面跳出率、停留时长等，很难反映出业务在发生哪些变化。
在前向几篇文章中，我们使用的便是这种思考视角。但整体来看，分析思路是零碎的。核心业务的漏斗数据或者某些重要的数据组并不能直接告诉我们背后的答案，在当时的语境下，产品经理需要将用户和事件视角结合起来分析，才更有可能发现数据背后的秘密。分析单一维度，并不能有所收获。
那么，我们有没有方案去解决这一种问题呢，比如说更换一种看待数据的视角？答案是有的。这种方式是目前业界主流的方式，事件模型（事件视角）。
事件模型
事件模型，又称作 “事件 - 用户模型”。简单来说，我们将用户的行为记录为事件和用户，分别存在事件表和用户表中，事件表中记录 Who、When、Where、What、How，即谁在什么时间，什么地点，以什么样的方式，做了一件什么样的事，用户表里面记录了某个用户有什么样的属性特征，比如年龄和性别。通过事件表和用户表，我们能快速明确不同群体做了什么事情，他们有哪些倾向，喜欢在浏览哪些板块，使用哪些功能等等。
目前，市面上提供用户行为分析服务的厂商大部分使用的都是这种模型。比如之前提到的神策数据、GrowingIO，以及 TalkingData、友盟、诸葛IO等等。
相较于传统的页面模型，事件模型的优点在于：
1、抽象能力强，能全面、精细地描述的用户行为
事件模型表达能力更强，能刻画更多类型的用户行为。传统的页面模型埋点，在最开始的时候已经固定好了采集哪几种类型的行为，比如页面浏览、按钮点击、Push 点击等，不同类型的埋点也确定了其中会采集哪些字段。也就是说，传统的页面模型是一套固定模板，如果后续想在某个埋点中新增个性化的字段是比较麻烦的。
针对添加个性化字段的需求，一种解决方式是，我们在每类埋点中都预留一个 values 字段，以 k-v 的形式来记录此类埋点下所有个性化的字段，这样是可以解决问题，但成本比较高：
- 一个字段中存了多个信息，埋点元数据的管理成本增加；
- 这样的字段非常灵活，难以约束业务方按照约定上报数据，有可能会出现一个 values 字段包含了上千个 k-v，数据质量难以把控；
- 在后期处理数据时，需要做额外的解析工作。另外，对于页面模型，如果后面要再采集一类埋点，需要重新设计一类埋点，后面的表、查询模型都要重新开发，非常的不灵活。
2、可打通业务数据和行为数据，实现更精细的用户行为分析
要把业务数据放入页面模型中是比较困难的，而对于事件模型，只要这个业务过程是有用户参与，就可以把业务数据表示为谁在什么时间、什么地点、以什么样的方式、做了一件什么样的事；随着用户行为分析越来精细，越来越深入业务，打通业务数据和行为数据已经是一件必要的事了，而事件模型在数据采集阶段就解决了这个问题。
3、容易理解，埋点设计起来相对容易
事件模型把用户和用户行为描述为：
谁在什么时间，什么地点，以什么样的方式，做了一件什么样的事，这个用户有什么样的属性特征。
这种描述非常贴近自然语言，在很大程度上降低了模型的理解难度。鉴于业界主流已经从页面模型切换到事件模型了，我们在构建埋点体系时尽量采用事件模型，而非页面模型。
谋定而后动
回到最开始的问题，为什么在 如何做好埋点设计 中，采用的思考方式和设计方法是不同的？
原因其实很简单。通常情况下，产品经理在设计埋点时依照的是事件模型原则，但直接采用这种方式是比较复杂的。对于新手产品经理来说，通常对自己所负责或参与的产品并不熟悉，进行埋点设计会遇到大量的错误和频繁的修改。最终又得重新思考产品业务和指标。
那么，不如我们直接在埋点设计之前就将产品捋清楚，花上 1~2 个小时的时间简单盘点一下产品的核心指标和用户路径，但是能使你的思路更加清晰，在后续的埋点设计中也会减少大量修改成本。
PS：本来是想新开一篇写原因的，没想到又写多了...