数仓 DW层 用户留存分析主题

数仓 DW层 用户留存分析主题

1. 背景

1. 在app运营和产品设计中，一般都是拉新和留存2个最关键指标来衡量对用户的吸引力程度。
2. 拉新，顾名思义， 拉新用户进来
3. 留存，顾名思义，让用户留下来，这里面有老用户也有新用户。从运营策略和效果来看，其实留住老用户的效果和成本都会比留住新用户更高，但在资本冲击之下，如果资本足够，往往会将资源往新用户上倾斜，这也是目前大数据杀熟被很多人吐槽的原因–老用户不再被重视和尊重。
   PS：在互联网的今天，固定类型的互联网群体其实已经差不多到顶了，也就是中国所有可以上网的人基本固定下来。国内现在各个app就需要从对方手里抢用户，这时候吸引新用户就至关重要了。只是在互联网媒体曝光之后，大家才发现大数据杀熟如此普遍，而新用户补贴在目前国内互联网用户市场饱和情况下会如此之多，以至于很多人会临时使用新手机号和新邮箱来享受这些福利和补贴。

2. 案例

经常可以看到的用户留存一般是上述的图所示

2. 技术分析

• 其实留存可以看成是一个用户在今天出现，在明天也出现，那就是次日留存。
• 一个用户在今天出现，在后天出现，那就是2日留存。至于明天是否出现，不重要。
• 这样一来，其实就可以反过来，
  
  计算每天数据，对比前一天，前2天，前3天，前四天，，，一直到前14天的留存数据。所谓留存数据就是今天出现了，此前第x天也出现了。那么只需要将2天的数据做一次join，join上的就是出现的用户。再统计join上的用户数即可
• 换一种思路，可以利用bitmap、bloomfilter、hyperloglog等高效算法，将每一天出现的用户guid换算为位标记。如果需要判定第x天和第y天之间的留存，只需要将2者的位标记做位运算，这样速度更快，而且可以运算效率更高。只不过除了bitmap算法之外，另外2种都有一定误差，需要结合业务考虑。

注意，大数据开发中，如果横表不好计算，可以考虑使用纵表来承载数据，可能就会豁然开朗

大数据开发中，思路比代码实现要优先，一定是现有数据处理思路，再动手写代码或者写sql。
在实际处理生产数据之前，一般都先伪造一些假数据进行流程和逻辑验证，确保无误之后，再验证生产的数据是否ok。

注意，大数据处理由于其特殊性，如果出现bug，由于数据量巨大，很多时候一些小的数据错误和偏差并不能很好察觉，一些bug一旦发生，影响的数据可能会非常大。
这也是为什么有些公司会将ODS数据保存不止半年，甚至会保存更久的原因，因为一旦计算出错，还可以从ODS层重新计算数据结果。