一、数据模型
1.传统的web端一般用页面模型来描述用户在产品上的行为，而移动端则使用事件模型，事件模型主要包含两个主体：事件+用户;（即event+user）一个 Event 就是描述了：一个用户在某个时间点、某个地方，以某种方式完成了某个具体的事情。
2.移动端event的打点，分为客户端打点和服务端打点，再选择哪个端打点时要考虑几个要素：
1）客户端打点可能会因为网络原因延迟上报，服务端不会；
2）客户端打点修改后需要等版本发布才生效，而服务端不用
综上，除非该行为只在客户端发生，对后端没有任何请求，才在客户端打点
疑点1：很多行为，如下单等，他们的很多字段在前端（App 和 Web 界面）是拿不到的。甚至有些行为，如用户线下消费等，前端根本就没有提供相应的功能，就更拿不到对应的数据。此话怎讲？下单过程什么字段是前端拿不到的
3.user部分
1) Profile 记录的是用户的基本固定不变的属性
2) 在 Event-User 模型中，出于性能和可解释性等各方面的考虑，Event 是被设计为不可变的。从逻辑上看似乎没有问题，因为 Event 代表的是历史上已经发生过的事件，一般来说不应该需要进行更新
二、数据格式
疑难点：
5. Item 相关操作
Item 相关操作，主要是用来设置 Item 的具体内容，提供了如下一系列接口：
5.1 item_set：
直接设置一个 Item，如果 Item 的字段已存在，则覆盖，不存在则自动创建。
数据样例：
{"type":"item_set","item_id":"12","item_type":"dub","project":"ebiz_test","properties":{"title":"because of u","sub_title":"st","xxx":"xxx"}}
对上述字段的解释如下：
type：item_set 表明是设置一个 item；
item_id：表示 item 的 id
item_type：item 表的类型，区分不同的 item 表。需是合法的变量名，即不能以数字开头，且只包含：大小写字母、数字、下划线和 $，且 item_type 字段长度最大为 100；
project：这条数据所属项目名，若不指定该参数，则需要使用该字段时取值 default，即默认项目。指定的项目必须是系统中已经存在的项目，否则这条数据将无效，更多项目相关请参见多项目；
properties：这个 item 的具体属性，以 dict 的形式存在。属性名需要是合法的变量名，不能以数字开头，且只包含：大小写字母、数字、下划线；
5.2 item_delete：
删除整个 Item 内容。
数据样例：
{"type":"item_delete","item_id":"16","item_type":"dub","project":"ebiz_test"}
以上整段没有理解？
