2. 数据基础

2.1 什么是用户分析

回过头来，我们要重新学习一下数据底层日常工作中，您可能会遇到如下问题：
新上线的产品功能，每天有用户在使用？新设计后的订单页面成交比率有没有提高？ 运营刚上线的活动，用户参与情况怎么样？用户是在哪一步发生流失的？
渠道投放的广告，有多少用户点击了？这些用户后来有在落地页上发生注册吗？

2.2 如何描述用户行为

在神策分析中，我们使用“事件模型（Event 模型）”来描述用户的各种行为，事件模型包括事件
（Event）和用户（User）两个核心实体。

2.2.1 Event 实体

一个完整的事件（Event），包含如下的几个关键因素： Who：即参与这个事件的用户是谁。 When： 即 这 个 事 件 发 生 的 实 际 时 间 。 Where：即事件发生的地点。

How：即用户从事这个事件的方式。这个概念就比较广了，包括用户使用的设备、使用的浏览器、使用的 App 版本、操作系统版本、进入的渠道、跳转过来时的 referer 等，目前，神策分析预置了如下字段用来描述这类信息，使用者也可以根据自己的需要来增加相应的自定义字段。
What：以字段的方式记录用户所做的事件的具体内容。不同的事件需要记录的信息不同，下面给出一些典型的例子：

2.2.2 User 实体

每个 User 实体对应一个真实的用户，每个用户有各种属性，常见的属性例如：年龄、性别，和业务相关的属性则可能有：会员等级、当前积分、好友数等等。这些描述用户的字段，就是用户属性。

2.3 埋点方案的制定——事件设计

采集用户行为数据，首先需要根据业务分析需求明确采集的目标行为，进一步搞清楚应该在哪些地方埋 什么样的点。这个环节的输出物一般被称之为“埋点需求文档（DRD）”。在大部分互联网公司，规范的产品迭代流程是，业务侧产品经理在输出“产品需求文档（PRD）”的同时，数据产品经理或分析师等角色需要同步输出 DRD，双方的需求同步进入开发和测试验收。
由于神策的底层数据模型是 Event + User 的事件模型，因此埋点在神策分析里被称之为“事件”，埋点需求文档则被统称为“采集方案设计”，本节的工作需要借助神策方提供的《数据采集方案》模板来完成

2.3.1. 采集方案思路

采集方案设计的核心思路，大体来说分为如下几点：
1. 将用户指标拆解为单个或多个行为动作；
2. 将需要分析的目标动作抽象为“事件”，添加事件维度；
3. 根据业务需求，整体完善采集方案设计；

2.3.2. 不同事件设计

行为颗粒度
对于相似场景，比如，提交门票订单，提交机票订单，在设计事件时是针对每个场景单独设计还是合并 成一个事件？有两种设计思路共参考：
A. 设计为同一事件，适用场景：各事件所需属性相差不大；平时分析场景多整体分析。
B. 设计为不同事件，适用场景：各事件所需属性相差很大；分析场景多分别分析。如果采用本思路，也 建议在一些相同属性上用一样的属性名称，便于今后使用“虚拟事件功能”来整体分析。
例 : 简单 的统计三个按钮 A、B、C 的点击情况时，不需要做成 “点击 A 按钮”、“点击 B 按钮”、“点击 C
按钮” 三个事件，而是做成 “点击按钮” 事件，将 A、B、C 三个按钮以属性 “按钮名称” 进行传递。

被动事件
被动事件：由于神策分析中的漏斗分析、留存分析等都需要事件的触发主体是同一个人，所以在一些场 景下需要给用户触发被动事件，如用户提交认证后，需要审核，审核并不是由用户主动触发，可设置为 被动事件。
User表注意
单边，双边用户
单双边是针对产品有多个身份使用用户时才会进行区分。单边用户，即仅有一 类用户的产品，如健身产品Keep，聊天工具 QQ 等 ; 双边用户如 O2O 产品，用户可能是普通消费者，也可能是商家用户。需要根据产品的不同，提前对用 户识别和相应属性进行设计。
缓慢变化维
如果遇到一些会发生变化的属性，比如用户的 VIP 等级，不能只作为用户属 性传进用户表中，还需在事件表中，记录一个 “当前发生事件 VIP 等级” 这个 属性。因为当前会员等级的统计，和发生事件时用户 的会员等级统计是两种情况。