1.2.3.1 数据模型
本节将会对HubbleData的数据模型进行介绍，以帮助产品方进一步了解HubbleData。本节内容主要包括：
- event-user 模型的使用场景
- attributes && userProfile的使用以及定义
1.1. 事件数据模型的使用
本节主要介绍event-user模型的使用，并且对HubbleData的事件体系以及用户体系进行介绍。
1.1.1. 事件模型
HubbleData使用事件模型对用户的行为进行标记与分析。事件模型是互联网分析的基本模型，这一模型认为每一次交互行为都会触发一次事件，同时每一次事件对应不同的环境变量：
- 标志事件唯一性的eventId：'viewProduct'，'clickButton'等等
- 事件的环境变量：IP，OS，appVersion，browser等等
具体来看，HubbleData的每一个事件都是如下格式的数据样例:
"eventId": "da_screen",
"userId": "xxxxxx",
"deviceUuid": "xxxxx",
"time": 1527503487446,
"costTime": 0,
"dataType": "pv",
"occurTime": 1527503487,
"sessionUuid": "396FC7DE-D11D-4B76-B66C-9179A366A288",
"timeZone": "Asia/Shanghai",
"attributes": {
"$screenTitle": "HubbleData",
"$screenName": "SplashActivity",
"productID": "XXXApp"
},
具体来说，HubbleData中任意一条事件含有如下信息：
- 标志事件唯一性的eventId，需要特别说明是，SDK会自动采集开机，激活，注册等等设备事件。此部分后续将会详细说明
- 标志用户唯一性的
userId，userId需要调用loginUser接口上传。没有上传时，HubbleData将会使用deviceUuid作为userId； - 标志设备唯一性的
deviceUuid，此ID为SDK自动生成； - SDK默认采集的属性，例如time，IP，OS，browser等等；
- 用来标记当前环境变量的自定义属性（上例中attributes），例如productId（商品ID），productName（商品名称），bookId（书籍ID）等等。 备注：da_screen属于内部事件，此处默认采集screenTitle，screenName属于内置属性（$)
事件模型探讨与思考
具体来说事件模型描述了某一用户在 什么时间点 什么地方做了 什么事情，以及相关的 上下文信息 和业务方的 自定义信息
用户
事件的触发主体。在Hubble系统中对于“人”的标记有两种，业务方在调用SDK的loginUser接口之后，所有产生的事件数据我们都会使用此时传入的userId进行标记，这种我们称之为用户ID；在业务方未调用该接口的情况下，SDK会自动生成一个全局唯一的deviceUdid进行标记，这种我们称之为设备ID。所以理论上，一个正常的带登录功能的产品的用户，在Hubble系统上都会有两个账号进行标记。
时间
记录的是用户在终端(App/Web)上触发事件的时间occurtime，这里记录的是客户端时间，格式是绝对毫秒数。
地方
记录的是事件发生的位置。目前主要是根据客户端IP进行解析，进而获取的国家、省份、城市、区县信息。
事情或者行为
记录的是埋点事件名称eventid。在Hubble系统中存在两类事件，一类称之为内部事件，这是由SDK内置自行记录的事件，比如da_session_start,da_session_close,da_screen,da_login等等。第二类称之为自定义事件，这类事件就是业务方调用SDK进行埋点时定义的事件。
上下文信息
记录的是事件发生时的上下文环境信息。比如移动端的设备型号、手机类型、网络型号、软硬件参数、Web端的浏览器信息、url信息、refer信息等等。
自定义属性
这里是由业务方根据业务需要，自行埋入的属性信息。比如电商网站的订单信息，视频网站的播放信息，游戏APP的玩家行为信息等等。
事件模型以及相关分析
事件模型通过eventId（事件）记录用户当时的操作，通过eventId（事件）附带的attributes（属性或者维度）来对当时的环境变量进行刻画，从而精确描述用户当时的行为数据。我们通过事件``指标``维度的方式对用户行为进行分析，举例如下：
- 分析场景：过去7天不同商品的交易额
事件分析模型：
- 事件：eventId = payOrder
- 指标：sum（price）
- 维度：group by Date,productId
用户行为payOrder（支付订单），属性price（价格）作为计算指标以及productId（商品）作为维度，可以看到事件模型的魔力：
- 事件模型非常清晰的定义了用户行为，包括行为以及环境变量；
- 通过后续的分析模型搭建，可以对非常多的业务场景进行分析，具体来看：
- 某一个事件（往往对应产品功能）的使用次数以及人数
- 某一个业务，例如某一城市的销售额，某一篇文章的阅读次数等等
1.1.2. 事件用户模型
我们上一节主要对事件模型进行分析，分别介绍了事件模型的构成以及使用。但是互联网产品中同时非常需要对用户进行分析，那么事件模型是否满足这部分需求呢？通过行为结合当时的环境变量对用户行为进行分析，应该说可以支持部分场景。但是涉及到深入的用户分析，事件模型可能不能很好起作用，主要原因在于事件模型无法获取全量用户信息，主要场景如：
- 用户信息是不同行为的计算结果，此时在数据源头取不到这个信息。举例如，首次使用时间，最后使用时间，以及各种用户标签。
- 部分用户信息虽然由用户上传，但是并不会永久存在本地。举例如，用户注册时填写的性别信息，以及生日爱好等等。
这两种情况限制了事件模型的使用以及扩展，针对这种情况HubbleData在事件模型的基础上引入了用户模型，共同组成事件用户模型。典型用户模型如下：
"userId": "xxxxxx",
"userAccount": "微信",
"sex": "male",
"city": "北京",
"birthDate": ”199001010101",
"attributes": {
"hobby": "旅行",
"wealth": "中产"
},
引入用户模型，后续分析过程中可以我们通过userId对事件模型进行扩展。
事件用户模型以及相关分析
事件模型与用户模型通过userId进行关联，共同构成HubbleData的基础分析模型。通过以上模型的搭建，我们在分析阶段可以实现的分析场景如下：
- 分析场景：过去7天不同性别的用户产生的交易额分布
事件分析模型：
- 事件：eventId = payOrder
- 指标：sum（price）
- 维度：group by Date,user.sex
用户行为为payOrder（支付订单），事件属性price（价格）作为指标以及用户属性sex作为维度。通过以上模型的搭建我们可以实现对不同用户的行为进行对比以及分析。
HubbleData的处理以及使用
回到我们上述讨论的的问题：
用户信息是不同行为的计算结果：
针对这种场景HubbleData提供部分解决方案：HubbleData提供非常灵活的自定义用户分群，方便用户对用户属性进行定义。比方说HubbleData可以将
过去7天买过5次护肤品的用户定义为一个用户群，后续可以将这个用户群与行为数据进行结合。之所以说部分解决方案，是因为HubbleData目前尚不支持上传本地已经创建好的用户标签用户信息不会永远存在本地，仅在上传时提供信息：
此种方式HubbleData提供
set接口，方便产品方上传用户信息。需要特别说明的是，调用set接口时，HubbleData上报da_user_profile事件，HubbleData数据端会在每天对userProfile数据进行合并。``备注：1.通过实时方式仅能获取da_user_profile事件数据，并不能获取HubbleData数据端加工的user表，用户表仍然需要产品方自己加工；2.合并时，同一用户新的属性值会覆盖原属性值
1.1.3. 事件以及用户属性的使用
上文对HubbleData使用的事件用户模型进行介绍，我们在这个基础上引入以下问题：
- 部分属性是不是既可以作为事件属性又可以作为用户属性？
- 如果存在这种情况，我们应该怎么选择？
应该说第一种情况是存在的，例如，VIP，游戏等级，游戏角色等等。这些信息理论上每次都可以取到，那么这些信息应该存在事件的环境变量还是用户信息里面呢？回答这个问题，我们首先从事件以及用户的实现机制说起：
- 事件的属性对应事件当时的环境信息，所以属性值是变化的。例如IP地址。
- 对于用户属性来说，我们数据端每天会对用户属性进行合并，即同一个用户某一个属性仅会存在一个值。例如出生年月，性别。
所以如果某一个属性在用户的生命周期中是变化中，产品方应该把这个属性设到事件属性中，例如用户在游戏里面的角色。部分情况如果产品仅关心用户的最新属性（例如VIP等级），此时产品方可以把VIP等级设成用户属性。如果用户的某一个特征是稳定的，此时推荐将这个信息设成用户属性。