数据定义与结构

数据定义

在运营增长平台中，我们使用User（用户）和Event（事件）来描述用户和用户在产品上的各种行为，这也是运营增长平台所有的接口和功能设计的核心依据。 您可以简单理解为两张大表，一张记录人的属性，一张记录人的行为。两张表通过唯一ID进行关联。在User（用户）表里，每一个用户就是一条记录；在Event（事件）表，每一条用户行为就是一条记录，通过两张表的配合可以做各种维度分析。
在极光运营增长中，分别提供了接口供使用者上传和修改这两类相应的数据，在使用产品的各个功能时，这两类数据也可以分别或者贯通起来参与具体的分析和查询。对这两个概念，我们会在后文做具体的描述。

数据结构

Event（事件）

事件五要素

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

事件的划分和字段设计原则

事件的划分原则

• 为节约成本只记录那些会使用到的 事件 。记录事件是为了详细地了解用户是如何使用产品的，对于暂时不会使用到的事件，暂不记录。

• 对于存在共性的的事件，建议进行合并 。例如，某个产品比较关心对一系列商品分类页的访问情况，则可以抽象出一个访问事件，然后再将不同的商品分类以事件属性的形式进行记录。

  事件属性设计原则

• 先根据需求梳理分析的指标和维度，然后再从指标和维度倒推需要在每个事件记录的事件属性。

• 运营增长平台是服务于营销的系统，并不是一个日志存储和备份系统，所以，一些用不到的字段，例如 Cookie 的完整内容、后端请求返回码等，就没有必要作为一个事件的事件属性来进行记录和收集了。

• 预置事件属性中可以满足业务需求的，则建议尽量复用预置事件属性。对所有预置事件属性的说明，可以参看 事件与属性 中的相应说明。

• 某个 事件 的某个字段的设计一旦确定，则不要再修改它的类型和取值含义。例如，一开始对于"购买"这个 事件，我们设计了一个数值型的事件属性“购买金额(元)”，后来需要将金额单位改成“分”，建议直接增加新字段“购买金额(分)”不建议改变原有属性，否则会导致数据混淆。

User（用户）

记录和收集 用户属性

每个 用户 实体对应一个真实的用户，用 CUID 进行标识，描述用户的长期属性，并且该用户可与其所从事的行为，也即 事件 进行关联。 运营增长提供了一系列 SDK和API，用来收集用户属性。 应该收集哪些字段作为 用户属性，也完全取决于产品形态以及分析需求。简单来说，就是在能够拿到的那些用户属性中，哪些对于分析和使用有帮助，则作为 用户属性 进行收集。

属性记录在 用户属性 还是 事件属性 的取舍

用户属性 记录的是用户特征的属性，例如：出生地、性别、注册地、首次广告来源类型等；事件 里的 事件属性 ，记录的是事件发生时的特征，属性的取值具有场景性，例如 省份、城市 、设备型号、是否登录状态等。 拿 “地址”为例：事件属性 记录的是本次下单时使用的地址。用户属性 记录的往往是 “常用地址”。