神策分析中的数据模型

1. 数据模型简介

在神策分析中，我们使用“事件模型（Event 模型）”来描述用户在产品上的各种行为，这也是神策分析所有的接口和功能设计的核心依据。

简单来说，事件模型包括事件（Event）和用户（User）两个核心实体，在神策分析中，分别提供了接口供使用者上传和修改这两类相应的数据，在使用产品的各个功能时，这两类数据也可以分别或者贯通起来参与具体的分析和查询。对这两个概念，我们会在后文做具体的描述。

1.1 Event Model Vs. Page View

在传统的 Web 时代，通常使用 PV（Page View 的简写，也即页面访问量）来衡量和分析一个产品的好坏，然后，到了移动互联网以及 O2O 电商时代，PV 已经远远不能满足产品和运营人员的分析需求了。

在这个年代，每个产品都有着独一无二的核心指标用来衡量产品是否成功，这个指标可能是发帖数量、视频播放数量、订单量或者其它的可以体现产品核心价值的指标，这些都是一个简单的 PV 无法衡量的。

除此之外，PV 模型也无法满足一些更加细节的、更加精细化的分析。例如，我们想分析哪类产品销量最好，访问网站的用户的年龄和性别构成，每个渠道过来的用户的转化率、留存和重复购买率分别如何，新老用户的客单价、流水、补贴比例分别是多少等等。这些问题，都是以 PV 为核心的传统统计分析没办法解答的问题。

因此，神策分析采用事件模型作为基本的数据模型。事件模型可以给我们更多的信息，让我们知道用户用我们的产品具体做了什么事情。事件模型给予我们更全面且更具体的视野，指导我们做出更好的决策。

当然，采用神策分析的事件模型，依然是可以完成 PV 统计的，并且实现起来也很简单，使用 SDK 或者导入工具上传一个类似的接口即可：

{
“distinct_id”: “2b0a6f51a3cd6775”,
“time”: 1434556935000,
“type”: “track”,
“event”: “PageView”,
“properties”: {
“$ip” : “180.79.35.65”,
“user_agent” : “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.）”,
“page_name” : “网站首页”,
“url” : “www.demo.com”,
“referer” : “www.referer.com”
}
}

2. Event 实体

2.1 Event 的五要素

简单来说，一个 Event 就是描述了：一个用户在某个时间点、某个地方，以某种方式完成了某个具体的事情。从这可以看出，一个完整的 Event，包含如下的几个关键因素：

Who：即参与这个事件的用户是谁。在我们的数据接口中，使用 distinct_id 来设置用户的唯一 ID：对于未登录用户，这个 ID 可以是 cookie、设备 ID 等匿名 ID；对于登录用户，则建议使用后台分配的实际用户 ID。同时，我们也提供了 track_signup 这个接口，在用户注册的时候调用，用来将同一个用户注册之前的匿名 ID 和注册之后的实际 ID 贯通起来进行分析。
When：即这个事件发生的实际时间。在我们的数据接口中，使用 time 字段来记录精确到毫秒的事件发生时间。如果调用者不主动设置，则各个 SDK 会自动获取当前时间作为 time 字段的取值。
Where：即事件发生的地点。使用者可以设置 properties 中的 $ip 属性，这样系统会自动根据 ip 来解析相应的省份和城市，当然，使用者也可以根据应用的 GPS 定位结果，或者其它方式来获取地理位置信息，然后手动设置 $city 和 $province。除了 $city 和 $province 这两个预置字段以外，也可以自己设置一些其它地域相关的字段。例如，某个从事社区 O2O 的产品，可能需要关心每个小区的情况，则可以添加自定义字段“HousingEstate”；或者某个从事跨国业务的产品，需要关心不同国家的情况，则可以添加自定义字段“Country”。
How：即用户从事这个事件的方式。这个概念就比较广了，包括用户使用的设备、使用的浏览器、使用的 App 版本、操作系统版本、进入的渠道、跳转过来时的 referer 等，目前，神策分析预置了如下字段用来描述这类信息，使用者也可以根据自己的需要来增加相应的自定义字段。
$app_version：应用版本
$city： 城市
$manufacturer： 设备制造商，字符串类型，如"Apple"
$model： 设备型号，字符串类型，如"iphone6"
$os： 操作系统，字符串类型，如"iOS"
$os_version： 操作系统版本，字符串类型，如"8.1.1"
$screen_height： 屏幕高度，数字类型，如1920
$screen_width： 屏幕宽度，数字类型，如1080
$wifi： 是否 WIFI，BOOL类型，如true
What：描述用户所做的这个事件的具体内容。在我们的数据接口中，首先是使用“event”这个事件名称，来对用户所做的内容做初步的分类。event的划分和设计也有一定的指导原则，我们会在后文详细描述。除了“event”这个至关重要的字段以外，我们并没有设置太多预置字段，而是请使用者根据每个产品以及每个事件的实际情况和分析的需求，来进行具体的设置，下面给出一些典型的例子：
对于一个“购买”类型的事件，则可能需要记录的字段有：商品名称、商品类型、购买数量、购买金额、 付款方式等；
对于一个“搜索”类型的事件，则可能需要记录的字段有：搜索关键词、搜索类型等；
对于一个“点击”类型的事件，则可能需要记录的字段有：点击 URL、点击 title、点击位置等；
对于一个“用户注册”类型的事件，则可能需要记录的字段有：注册渠道、注册邀请码等；
对于一个“用户投诉”类型的事件，则可能需要记录的字段有：投诉内容、投诉对象、投诉渠道、投诉方式等；
对于一个“申请退货”类型的事件，则可能需要记录的字段有：退货金额、退货原因、退货方式等。

2.2 Event 的划分和字段设计原则

为了更好地使用神策分析提供的强大、便捷的分析功能，我们强烈建议使用者花费一定的时间，梳理自己的数据使用需求，并据此做好 Event 的划分和字段设计。

在 Event 的划分和设计过程中，神策分析团队也会提供相应的技术支持和服务，除此之外，我们将一些基本的原则也在这里整理出来，期望对使用者有所帮助。

2.2.1 客户端埋点 Vs. 在后端记录 Event

友盟、百度统计等传统分析工具，都是在客户端嵌入 SDK 进行埋点，但是，我们强烈推荐在后端记录 Event，这是出于以下一些考虑：

很多行为，如下单等，他们的很多字段在前端（App 和 Web 界面）是拿不到的。甚至有些行为，如用户线下消费等，前端根本就没有提供相应的功能，就更拿不到对应的数据。
后端修改程序更加方便便捷，如果是在 App 端记录数据，则每次修改都需要等待 App 的发版和用户更新；
App 端收集数据会有丢失的风险，并且上传数据也不及时。App 端为了避免浪费用户的流量，一般情况下，都是将多条数据打包，并且等待网络状况良好以及应用处于前台时才压缩上传，因此，自然会造成上传数据不及时，很有可能某一天的数据会等待好几天才传到服务器端，这自然会导致每天的指标都计算有偏差。同时，由于 App 端可以缓存的内容有限，用户设备的网络连接等问题，App 端收集的数据目前也没有太好的手段保证100%不丢失。
基于以上几点考虑，除非某个行为只在前端发生，对后端没有任何请求，否则，我们建议永远只在后端收集数据。

2.2.2 Event 的划分原则

对产品划分 Event，我们有如下的一些建议：

为了节约使用成本，应该从需求出发，只记录那些会分析到的 Event，这一点是与传统的 PV 分析产品一个很大的不同。记录 Event 是为了详细地了解用户是如何使用产品的，对于暂时不会分析到的那些使用情况，可以暂时先不记录。
Event 的数量不应过多，对于一个典型的用户产品，Event 的数量以不超过20个为宜。当然，这个只是我们对事件设计的一些原则性的建议，系统本身并没有这方面的限制。一些类似的用户操作，可以合并成一个 Event。例如，假设某个产品比较关心对一系列商品分类页的访问情况，那么，并不意味着每个商品分类页点击就应该划分成一个单独的 Event，而是可以划分出一个单独的“商品分类页访问” Event，然后再将不同的分类以字段的形式进行记录。
Event 不仅局限于用户在 App、Web 界面等前端的操作和使用，一些其它类型的用户行为，例如用户的电话投诉、用户在线下接收服务、用户在线下商家进行消费等，如果能够获取到相应的数据，并且数据分析也会用到，则也可以作为相应的 Event。

2.2.3 字段设计原则

为每个 Event 进行字段设计，我们有如下的一些建议：

先根据需求梳理分析的指标和维度，然后再从指标和维度倒推需要在每个 Event 记录的字段。
神策分析是一个数据分析工具，并不是一个日志存储和备份系统，所以，一些用不到的字段，例如 Cookie 的完整内容、后端请求返回码等，就没有必要作为一个 Event 的字段来进行记录和收集了。
预置字段中已经有的字段，则建议尽量复用预置字段。对所有预置字段的说明，可以参看数据格式中的相应说明。
某个 Event 的某个字段的设计一旦确定，则不要再修改它的类型和取值含义。例如，一开始对于"Buy"这个 Event，我们设计了一个数值类型的字段"Money"，描述这个购买行为对应的购买金额是多少元，然而后面我们期望把它改成分，那么我们建议不如废弃掉"Money"字段并且增加一个新的字段叫"MoneyByCents"，而不是去改变"Money"的含义。

3. User 实体

3.1 记录和收集 User Profile

每个 User 实体对应一个真实的用户，用 distinct_id 进行标识，描述用户的长期属性（也即 Profile），并且通过 distinct_id 与这个用户所从事的行为，也即 Event 进行关联。

神策分析提供了一系列 profile_xxx 类型的接口，用来对某个 user 的 Profile 进行记录和修改。

一般记录 User Profile 的场所，是用户进行注册、完善个人资料、修改个人资料等几种有限的场合，与 Event 类似，我们也强烈建议在后端记录和收集 User Profile。

应该收集哪些字段作为 User Profile，也完全取决于产品形态以及分析需求。简单来说，就是在能够拿到的那些用户属性中，哪些对于分析有帮助，则作为 Profile 进行收集。

3.2 字段记录在 Profile 还是 Event 的取舍

有些时候，我们可能会纠结，某个与用户相关的字段是应该记录在 Profile 还是记录在 Event，一个基本的原则就是，Profile 记录的是用户的基本固定不变的属性，例如性别、出生年份（请注意，记录的不是年龄而是出生年份）、注册时间、注册地域、注册渠道等。而还有一些字段，例如用户级别、设备类型、地域、是否是 Vip 等，虽然也是用户相关的字段，但是可能是会经常变化的，则应该在用户的某个 Event 发生的时候，作为 Event 的一个字段来进行记录。

4. Item 实体

神策 1.14 开始支持 Item 实体。

在 Event-User 模型中，出于性能和可解释性等各方面的考虑，Event 是被设计为不可变的。从逻辑上看似乎没有问题，因为 Event 代表的是历史上已经发生过的事件，一般来说不应该需要进行更新。

但是，在实际的应用过程中，并不一定是这么理想的状态。

如，在采集和分析中会发现：

Event 实体中一些基本信息中会有许多是不断变化的
埋点采集中，发现某些 Event 在最初的阶段采集到的数据不完善。
这时，可通过 Item 实体对 Event-User 模型进行补充。

这里的所谓 Item，在严格意义上是指一个和用户行为相关联的实体，可能是一个商品、一个视频剧集、一部小说等等。Item 的应用场景有很多，下面介绍两个最常见的应用场景。

4.1 神策分析系统中的 Item 应用

Item 模型的一个典型场景是用作神策分析的维度表，具体的使用请参考文档 使用 items 表作为维度表

4.2 神策推荐系统中的 Item 应用

想了解神策推荐服务的更多细节，请联系神策技术支持。

神策推荐核心价值是计算用户最有可能消费的物品（即 Item），并以推荐结果返回到产品前端供用户消费。神策推荐系统会以 Item 数据为基础构建推荐物品的画像（高维向量），计算用户最有可能消费的物品或者相似物品。

在对接神策推荐系统时，开发者需要通过 SDK 的 itemSet 系列接口来上传数据，同时神策也提供了管理后台对 Item 表进行直接的管理，例如管理员可以对某条待推荐的 Item 进行封禁或者调权以优化推荐效果。