1 用户
用户以设备为判断标准，在移动统计中，每个独立设备认为是一个独立用户。Android系统根据IMEI号，IOS系统根据OpenUDID来标识一个独立用户，每部手机一个用户。
2 新增用户
首次联网使用应用的用户。如果一个用户首次打开某APP，那这个用户定义为新增用户；卸载再安装的设备，不会被算作一次新增。新增用户包括日新增用户、周新增用户、月新增用户。
3 活跃用户
打开应用的用户即为活跃用户，不考虑用户的使用情况。每天一台设备打开多次会被计为一个活跃用户。
4 周（月）活跃用户
某个自然周（月）内启动过应用的用户，该周（月）内的多次启动只记一个活跃用户。
5 月活跃率
月活跃用户与截止到该月累计的用户总和之间的比例。
6 沉默用户
用户仅在安装当天（次日）启动一次，后续时间无再启动行为。该指标可以反映新增用户质量和用户与APP的匹配程度。
7 版本分布
不同版本的周内各天新增用户数，活跃用户数和启动次数。利于判断APP各个版本之间的优劣和用户行为习惯。
8 本周回流用户
上周未启动过应用，本周启动了应用的用户。
9 连续n周活跃用户
连续n周，每周至少启动一次。
10 忠诚用户
连续活跃5周以上的用户
11 连续活跃用户
连续2周及以上活跃的用户
12 近期流失用户
连续n(2<= n <= 4)周没有启动应用的用户。（第n+1周没有启动过）
13 留存用户
某段时间内的新增用户，经过一段时间后，仍然使用应用的被认作是留存用户；这部分用户占当时新增用户的比例即是留存率。
例如，5月份新增用户200，这200人在6月份启动过应用的有100人，7月份启动过应用的有80人，8月份启动过应用的有50人；则5月份新增用户一个月后的留存率是50%，二个月后的留存率是40%，三个月后的留存率是25%。
14 用户新鲜度
每天启动应用的新老用户比例，即新增用户数占活跃用户数的比例。
15 单次使用时长
每次启动使用的时间长度。
16 日使用时长
累计一天内的使用时间长度。
17 启动次数计算标准
IOS平台应用退到后台就算一次独立的启动；Android平台我们规定，两次启动之间的间隔小于30秒，被计算一次启动。用户在使用过程中，若因收发短信或接电话等退出应用30秒又再次返回应用中，那这两次行为应该是延续而非独立的，所以可以被算作一次使用行为，即一次启动。业内大多使用30秒这个标准，但用户还是可以自定义此时间间隔。
1）创建原数据表
hive (gmall)>
drop table if exists stud;
create table stud (name string, area string, course string, score int);
2）向原数据表中插入数据
hive (gmall)>
insert into table stud values(‘zhang3‘,‘bj‘,‘math‘,88);
insert into table stud values(‘li4‘,‘bj‘,‘math‘,99);
insert into table stud values(‘wang5‘,‘sh‘,‘chinese‘,92);
insert into table stud values(‘zhao6‘,‘sh‘,‘chinese‘,54);
insert into table stud values(‘tian7‘,‘bj‘,‘chinese‘,91);
3）查询表中数据
hive (gmall)> select * from stud;
stud.name stud.area stud.course stud.score
zhang3 bj math 88
li4 bj math 99
wang5 sh chinese 92
zhao6 sh chinese 54
tian7 bj chinese 91
4）把同一分组的不同行的数据聚合成一个集合
hive (gmall)> select course, collect_set(area), avg(score) from stud group by course;
chinese ["sh","bj"] 79.0
math ["bj"] 93.5
5） 用下标可以取某一个
hive (gmall)> select course, collect_set(area)[0], avg(score) from stud group by course;
chinese sh 79.0
math bj 93.5
1）date_format函数（根据格式整理日期）
hive (gmall)> select date_format(‘2019-12-14‘,‘yyyy-MM‘);
2019-02
2）date_add函数（加减日期）
hive (gmall)> select date_add(‘2019-12-14‘,-1);
2019-02-09
hive (gmall)> select date_add(‘2019-12-14‘,1);
2019-02-11
3）next_day函数
（1）取当前天的下一个周一
hive (gmall)> select next_day(‘2019-02-12‘,‘MO‘);
2019-02-18
说明：星期一到星期日的英文（Monday，Tuesday、Wednesday、Thursday、Friday、Saturday、Sunday）
（2）取当前周的周一
hive (gmall)> select date_add(next_day(‘2019-02-12‘,‘MO‘),-7);
2019-02-11
4）last_day函数（求当月最后一天日期）
hive (gmall)> select last_day(‘2019-12-14‘);
2019-02-28
以下是活跃用户需求的整体开发流程。
第一步：确定指标的业务口径
业务口径应该由产品经理主导，找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的，比如活跃用户是指启动过APP的用户。
第二步：确定指标的技术口径
技术口径是由建模工程师主导，此时产品经理要和模型设计师沟通整个指标的业务逻辑，另外就是要协调业务方的技术开发人员和我们的建模工程师一起梳理需要采集的用户行为，或者业务数据库层面需要用到表结构和字段。
第三步：原型设计和评审
由产品经理主导设计原型，对于活跃主题，我们最终要展示的是最近n天的活跃用户数变化趋势 ，效果如下图所示。此处需要建模工程师、数据开发工程师、后端开发工程师、前端开发工程师、UI共同参与，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。
第四步：模型设计
此时主导的是我们的模型设计工程师，一般会采用分层建模的方式把数据更加科学的组织存储。分为 ODS（操作数据层），DWD(明细数据层)、DWS（汇总数据层）、ADS （应用数据层），这是业务对数据分层常用的模型。模型设计工程师要清楚的知道数据来源自那里，要怎么存放。
以用户活跃需求为例，ods层需要存放start_log（启动日志），dwd层需要对数据进行清洗、过滤，dws层需要对数据进行轻度聚合，ads层需要得出最终统计指标的结果。
第五步：数据开发
此时主导的是大数据开发工程师，首先要和数据建模工程师沟通好技术口径明确好我们计算的指标都来自于那些业务系统，他们通过数据同步的工具如flume、sqoop等将数据同步到模型工程师设计的ODS层，然后就是一层一层的通过SQL计算到DWD、DWS层，一层一层的汇总，最后形成可为应用直接服务的数据填充到ADS层。
第六步：后端开发
此时由后端开发主导，后端开发工程师基于产品经理的功能定义输出相应的接口给前端开发工程师调用，由于ADS层的数据已经由开发工程师导出到常规的关系型数据库（如MYSQL等），此时后端开发工程师更多的是和产品经理沟通产品的功能、性能方面的问题，以便给使用者更好的用户体验。
第七步：前端开发
此时主导的是前端开发工程师。原型出来后产品经理会让UI设计师基于产品功能的重点设计UI，UI设计师经过反复的设计，UI最终定型后，会给我们的前端开发工程师提供切图。前端开发工程师基于UI的切图做前端页面的开发。
第八步：联调
此时数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。此时会要求大数据开发工程师基于历史的数据执行计算任务，数据开发工程师承担数据准确性的校验。前后端解决用户操作的相关BUG保证不出现低级的问题完成自测。
第九步：测试
测试工程师在完成原型评审后就要开始写测试用例，那些是开发人员自己要自测通过才能交上来测试的，那些是自己要再次验证的都在测试用例写清楚。此时有经验的产品经理会向运营人员要历史的统计数据来核对数据，不过运营人员的数据不一定准确，只是拿来参考。最终测试没问题产品经理协调运营人员试用，试用中发现的一些问题再回炉重新修改，此时整个研发过程就结束了。
第十步：上线
运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器。此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要每过一个周期内部再次验证，从而保证数据的准确性。
大数据实战（三十一）：电商数仓（二十四）之用户行为仓库（十）业务知识准备
原文：https://www.cnblogs.com/qiu-hua/p/13541668.html