电商用户消费行为数据分析

Posted 2023-05-01

参考技术A 对于初级阶段的新电商来说，积累数据，找准运营方向，关注流量，开源是重点；
对于中级阶段的电商，稳定客流，提高店铺销量是首要任务；
对于很有规模的电商，更侧重留存与活跃，提升整体运营水平。

不同的阶段，对于数据分析指标的侧重点也不同。
本篇以某电商用户订单记录为例，侧重用户消费整体趋势和用户消费行为，对用户规模和用户黏性中的几个核心数据点进行分析展示：

分析过程思维导图：

数据来源于一家电商网站用户订单记录

观察数据：
1、日期需要转换格式
2、大部分的订单购买商品数量较少，平均值在2个左右，极值99很大，存在干扰
3、用户消费金额稳定，同样也存在极值干扰

时间格式转换：需要按月分析数据，这里直接转为月份，忽略具体日期

1、每月销量和销售额分布情况

销量与销售额走势一致

2、用户数量、订单数量分布情况

订单量和用户数量线性分布图

3、用户数量分布情况
使用数据透视表，查看每月用户数量、销量和销售额

用户平均消费金额不稳定，此消彼长

用户平均消费次数在1-2次之间，1997-1998呈上涨趋势

1、用户消费次数与消费金额

用户消费金额、消费次数分布散点图

根据散点图分布，极值影响严重，根据切比雪夫定理，筛选数据
95%的数据集中在距离平均值5个标准差之内

去掉极值，重新调整后的分布图

图形大致呈现线性回归，说明客单价稳定

用户消费次数直方图:

大部分集中在10次以内，小部分数据造成了干扰

用户金额次数直方图

大部分集中在250元以下，绝大部分呈现集中趋势,小部分数据造成了干扰

2、用户累计消费额占比

按消费金额排序，使用累计加和函数，计算用户消费额占比

用户人数是23750 50%的人只占了15%的消费额 消费总金额前4000名贡献了60%的消费额度
也就是维护好这前4000名客户，可以完成KPI的60%

3、新老客消费比

每月新客趋势图

每月老客趋势图

4、单次用户消费数量

只消费了一次的客户占比51.14%，有一半客户只购买了一次

按月对比：

5、用户分层——rfm模型
使用数据透视表，提取出用户消费额、最后一次消费日期、消费数量数据

将最后一次消费日期转为最后一次消费日距今的天数
(由于数据是很早之前的，为了更好的展示数据，将对比标准改为所有用户最后一次消费的日期）

数据以平均值作为x、y、z轴标准值，编写python函数，将用户M、R、F数据，划分象限，使用0、1作为标准值上下象限之分，给用户分别贴上标签。
8类标签分别是：重要保持客户、重要价值客户、重要发展客户、重要挽留客户、一般保持客户、一般价值客户、一般发展客户、一般挽留客户

统计各标签用户的总销售额、总的消费频率，和人数

一般挽留客户最多，重要保持客户第二，重要保持客户销售金额占比最高

rfm客户分层散点图：

从RFM分层可知，大部分用户为重要保持客户，但这是由于极值影响，拉高了平均值，用户划分不够准确

6、用户分层——新老用户、活跃、回流、流失用户

使用数据透视表，统计每月各用户消费情况，1表示当月购买过，0表示当月没有购买

使用python函数，根据用户每月消费情况，贴上标签

统计每月各类用户的数量

更直观的面积图：

计算回流率加入表中

7、用户生命周期
计算用户第一次购买和最后一次购买的时间差

平均生命周期为135天，最长544天

用户的生命周期受只购买过一次的用户影响比较厉害，可以剔除

剔除只购买一次的用户，可以看出，用户生命周期首位两端人数比较多，中间值相对少

8、用户购买周期

9、复购率
复购率指自然月内，购买多次的用户占比

使用applymap函数对用户购买各月购买次数进行标记

复购率线形图

复购率稳定在20%左右，前一个月因为有大量新用户，只购买了一次，拉低了复购率

10、回购率
回购率指曾经购买过且在某一时期内再次购买的用户占比

使用前面分好的购买标记
0为本月未购买，1为本月购买

编写python函数，对用户回购情况贴上标签

回购率线形图

大数据项目之电商数仓-用户行为数据采集

数据仓库简介

数据仓库是为企业所有决策制定过程，提供所有系统数据支持的战略集合，通过数据仓库中的数据的分析，可以帮助企业改进业务流程、控制成本、提高产品质量等。

项目需求

• 实时采集买点的用户行为数据
• 实现数据仓库的分层搭建
• 每天定时导入业务数据
• 根据数据仓库中的数据进行报表分析

技术选型角度： 数据采集传输、数据存储、数据计算、数据查询

系统架构图设计

系统数据流程设计

集群资源规划设计

	服务器一	服务器二	服务器三
HDFS	NameNode、DataNode	DataNode	DataNode
Yarn	NodeManager	ResourcemManager、NodeManager	NodeManager
Zookeeper	Zookeeper	Zookeeper	Zookeeper
Flume(采集日志)	Flume	Flume
Kafka	Kafka	Kafka	Kafka
Flume(消费Kafka)
Hive	HIve
MySQL	MySQL

买点数据的基本格式

{
"ap":"xxxxx",//产品字段 app key
"cm": {  //公共字段
		"mid": "",  // (String) 设备唯一标识
        "uid": "",  // (String) 用户标识
        "vc": "1",  // (String) versionCode，程序版本号
        "vn": "1.0",  // (String) versionName，程序版本名
        "l": "zh",  // (String) 系统语言
        "sr": "",  // (String) 渠道号，应用从哪个渠道来的。
        "os": "7.1.1",  // (String) Android系统版本
        "ar": "CN",  // (String) 区域
        "md": "BBB100-1",  // (String) 手机型号
        "ba": "blackberry",  // (String) 手机品牌
        "sv": "V2.2.1",  // (String) sdkVersion
        "g": "",  // (String) gmail
        "hw": "1620x1080",  // (String) heightXwidth，屏幕宽高
        "t": "1506047606608",  // (String) 客户端日志产生时的时间
        "nw": "WIFI",  // (String) 网络模式
        "ln": 0,  // (double) lng经度
        "la": 0  // (double) lat 纬度
      },
"et":  [  //事件
            {
                "ett": "1506047605364",  //客户端事件产生时间
                "en": "request",  //事件名称
                "kv": {  //事件结果，以key-value形式自行定义
                    "your key1": "your value1",
                    "your key2": "your value2",
                    "your key n": "your value n"
                }
            }
        ]
}

Flume日志采集

Flume一般都是部署在服务器上，由运维统一配置部署。此处直接读log日志的数据，log日志的格式是app-yyyy-mm-dd.log，可以直接读取。本项目中自定义了两个拦截器，分别是：ETL拦截器、日志类型区分拦截器。
ETL拦截器主要用于，过滤时间戳不合法和json数据不完整的日志。日志类型区分拦截器主要用于，将错误日志、启动日志和事件日志区分开来，方便发往kafka的不同topic。

Flume采集系统组件解析

1. Taildir Source
   在Flume1.7之前如果想要监控一个文件新增的内容，我们一般采用的source为exec tail，但是这会有一个弊端，就是当你的服务器宕机重启后，此时数据读取还是从头开始，这显然不是我们想看到的！ 在Flume1.7没有出来之前我们一般的解决思路为：当读取一条记录后，就把当前的记录的行号记录到一个文件中，宕机重启时，我们可以先从文件中获取到最后一次读取文件的行数，然后继续监控读取下去。保证数据不丢失、不重复。在Flume1.7时新增了一个source的类型为taildir，它可以监控一个目录下的多个文件，并且实现了实时读取记录保存的断点续传功能。但是中如果文件重命名，那么会被当成新文件而被重新采集。

2. Channel
   • Memory Channel
     它把Event保存在内存队列中，该队列能保存的Event数量有最大值上限。由于Event数据都保存在内存中，Memory Channel有最好的性能，不过也有数据可能会丢失的风险，如果Flume崩溃或者重启，那么保存在Channel中的Event都会丢失。同时由于内存容量有限，当Event数量达到最大值或者内存达到容量上限，Memory Channel会有数据丢失。
   • File Channel
     File Channel把Event保存在本地硬盘中，比Memory Channel提供更好的可靠性和可恢复性，不过要操作本地文件，性能要差一些。
   • Kafka Channel
     Kafka Channel把Event保存在Kafka集群中，能提供比File Channel更好的性能和比Memory Channel更高的可靠性。
3. Sink
   • Avro Sink
     Avro Sink是Flume的分层收集机制的重要组成部分。 发送到此接收器的Flume事件变为Avro事件，并发送到配置指定的主机名/端口对。事件将从配置的通道中按照批量配置的批量大小取出。
   • Kafka Sink
     Kafka Sink将会使用FlumeEvent header中的topic和key属性来将event发送给Kafka。如果FlumeEvent的header中有topic属性，那么此event将会发送到header的topic属性指定的topic中。如果FlumeEvent的header中有key属性，此属性将会被用来对此event中的数据指定分区，具有相同key的event将会被划分到相同的分区中，如果key属性null，那么event将会被发送到随机的分区中。

如何设计kafka集群的大小

• Kafka的机器数量
  先要预估一天大概有多少数据量，算出峰值是多少数据的速度。然后再去用压测的标准计算一天能承受多少的负载。在上面乘以一个n倍(考虑写一份，存在n倍的同时冗余，ISR，如果我们的冗余是2，那么就是2)，就是大概的数据量。数据量我们都是算多少M每秒。一般我们压只压一下写的速度，不让数据在业务层积压。比如我压测测出写入的速度是100M/s一台，峰值的业务数据的速度是200M/s，如果我们追求实时性，那么我们需要（200*2/100=4，然后需要2n+1台，就是9台，能达到实时性）。参数说明：200是峰值速率；2是副本个数，100是经验值。2n+1是经验值
• Kafka的硬盘大小
  Kafka的硬盘大小设置成能至少存一周的数据就可以满足了
• Kafka的日志留存设置
  Kafka的日志留存一般有两种，一种是时间，一种是大小。我们设置至少保留3天的数据量，取中间的最大值。大小和性能并无太大关系，都是O(1) ，所以越大越好。
• Kafka监控
  公司自带的agent部署在每台服务器上面，出现程序奔溃则会报警。负载过高也会报警（磁盘，cpu，内存等）
• Kakfa分区数
  分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。
• 分区数和冗余数的设定？
  冗余数一般我们设置成2个。根据ISR，分区数的话一般是3个。

日志消费Flume配置