
简介本资源是一个基于Python开发的电商用户行为分析与可视化系统面向数据分析初学者、电商运营人员及Python学习者旨在解决用户行为数据清洗、统计建模、多维洞察与业务可视化呈现等实际问题。压缩包共52个文件包含9个核心Python源码如app.py、models.py、blueprints/模块化结构、7个HTML前端页面、4个CSS与2个JS实现交互展示、2个Excel分析结果样例及2个Word项目说明文档辅以配置文件与静态资源整体3.02MB结构清晰、模块解耦便于理解Flask后端架构与前后端协同逻辑。已有109人学习下载资源提供完整可运行系统框架涵盖用户画像构建、行为路径分析、热销商品识别及热力图/折线图/饼图等多样化可视化方案代码含注释且配套需求文档与项目说明适合动手实践、课程设计或中小电商数据分析场景快速落地。 打开后台导出的用户行为表第一反应大概率是“这都啥”。几百万行日志里每行记录的是谁在什么时间点了哪个商品行为类型还分浏览、收藏、加购、购买光靠Excel根本拉不动更别说看出用户到底是怎么流失的。最近我把这套基于Python的电商用户行为分析及可视化系统完整跑了一遍从数据清洗到RFM用户分层再到FlaskPyECharts的交互大屏整个过程收获很大也踩了不少坑。这篇东西就把完整的实现思路、操作步骤和问题排查整理出来给准备做数据分析项目、或者想在电商场景里落地用户行为分析的朋友做个参考尤其是刚接触Python数据分析的同学可以直接照着把项目跑起来。1. 项目概述与整体设计思路1.1 这个系统到底解决什么问题电商后台每天产生大量用户行为日志但原始日志基本不具备可读性。举个实际例子一条记录可能只是“用户A在某个时间点浏览了商品B”单独看没有任何价值但把几十万条这样的记录聚合起来就能回答很多运营关心的问题今天有多少人访问了商城多少人把商品加进购物车却最终没有下单哪个品类的商品被浏览最多但转化率最低哪些用户是真正的高价值用户这个项目的核心目标就是把“原始行为日志”转化成“可对外展示的经营指标”再通过可视化系统把指标变成图表。整个项目拆开看其实是三条线数据清洗线原始日志到干净结构化数据、指标计算线PV/UV/转化率/复购率/RFM分层、可视化展示线图表生成与Web交互。三条线串起来才是一个完整的分析系统而不是孤立的几个脚本。从我实际开发的角度来说最容易被忽略的是第一条线。很多人拿到数据后急着画图结果图是出来了但因为数据没洗干净算出来的指标根本不可信。比如同一个用户在同一个商品页刷新了三次这算三次浏览还是算一次这个口径如果不定清楚后面所有分析都是空中楼阁。所以这个项目在设计时就强制把数据清洗和指标口径定义放在最前面。1.2 核心分析指标体系怎么定电商用户行为分析不是指标越多越好而是要先问“业务到底关注什么”。我在这套系统里按“用户-商品-时间”三个维度定义了一套核心指标体系流量指标PV页面浏览量、UV独立访客数、人均浏览深度PV/UV转化指标整体转化率购买用户数/总用户数、各个行为节点的转化率浏览到加购、加购到下单留存指标次日留存率、7日留存率、30日留存率价值指标复购率、RFM用户分层商品指标热门商品Top N、品类热度分布这套指标体系的好处是“什么都能往里装”。用户画像分析可以看性别年龄地域分布行为分析可以看一天里哪个时间段访问量最高漏斗分析可以看从浏览到购买的流失环节用户分层可以找出核心价值用户。可视化大屏上的每个图表背后都对应这些指标之一而不是为了画图而画图。另外一个实际经验是指标口径一定要在开发前用文字写清楚。比如“转化率”这个指标不同项目定义完全不同。有的算“购买用户数/总访问用户数”有的算“下单次数/总访问次数”有的算“支付用户数/唯一用户数”。我在这套系统里统一成“购买用户数/总用户数”并且全程保持一致这样后续验证数据的时候才不会乱。1.3 为什么选Python生态而不是其他方案坦白说这类分析用BI工具比如Power BI、Tableau也能做但选择Python有几个BI工具替代不了的优势。第一是分析逻辑完全可控每个指标怎么算、每个字段怎么处理代码里写得明明白白出问题能精准定位。第二是自动化能力数据更新后跑一遍脚本就行不需要手动刷新报表。第三是灵活性可以结合爬虫、机器学习做扩展后续想加预测模型也不需要换技术栈。在Python生态里我最终确定的技术组合是Pandas NumPy做数据处理PyECharts做可视化图表Flask做Web展示层。Pandas处理表格数据的效率很高groupby、merge、pivot_table这几个方法就能完成绝大部分聚合需求。PyECharts是国内团队开源的可视化库生成的是HTMLJS图表交互流畅不用自己写前端代码。Flask则是轻量级Web框架能快速把图表挂到网页上。这个组合还有一个特别实际的好处对开发者电脑配置要求不高。整个项目跑起来只需要Python环境加几个依赖库不需要装数据库不需要装Node.js也不需要额外启动前端服务。对于做课程设计、个人项目或者小团队内部报表来说这套组合的开发成本和维护成本都非常友好。2. 技术选型与开发环境搭建2.1 依赖库版本与安装方法这个项目依赖的库不算多但版本坑不少。核心依赖是Pandas、NumPy、PyECharts、Flask另外建议装openpyxl方便后续导出Excel报表。安装时优先用国内的镜像源不然下载速度真的让人崩溃。pip install pandas numpy pyecharts flask openpyxl -i https://pypi.tuna.tsinghua.edu.cn/simple我实测下来PyECharts的版本兼容性比较特殊。1.x版本和0.5.x版本的导入方式完全不同0.5.x用的是from pyecharts import Bar这种老写法1.x用的是from pyecharts.charts import Bar配合options配置项。网上很多教程还是老版的写法直接复制到新版环境里会报ImportError或者找不到图表类型。建议安装时指定pyecharts1.0代码统一按新版写。Pandas版本也有影响。Pandas 2.x对部分API做了调整比如append方法被移除了如果看到DataFrame object has no attribute append的报错基本都是因为代码里用了旧写法。建议安装时用pip install pandas2.0代码里避开旧API就好。开发环境方面我个人的建议是建一个独立虚拟环境再装依赖不要直接装到系统Python里。原因很简单数据分析项目的依赖库更新频率高今天装的版本可能过两个月就被新版本踩了接口独立环境可以保证项目随时能跑起来不受其它项目干扰。python -m venv ecommerce_analysis source ecommerce_analysis/bin/activate # Windows下执行 ecommerce_analysis\Scripts\activate2.2 数据集结构与字段说明这套系统使用的电商用户行为数据标准字段结构一般是5列包括用户ID、商品ID、商品类目ID、行为类型、时间戳。行为类型有四种取值pv浏览、cart加入购物车、fav收藏、buy购买。这四种行为组成了电商用户转化的核心链路先浏览商品感兴趣就收藏或加购最后下单购买。实际跑项目之前我建议先把这个结构吃透。拿一条样例数据来说10001, 25631, 823, pv, 1700000000表示用户10001在时间戳1700000000时刻浏览了商品25631这个商品属于类目823。这里的user_id是用户唯一标识item_id是商品唯一标识category_id是商品所属类目。有一条非常容易踩的坑原始数据里没有订单金额字段只有行为类型。这意味着经典的RFM模型里“M金额”维度的计算需要另想办法。我在项目里采用的方案是用每个用户的购买次数作为“M”的替代——也就是将“用户购买行为计数”作为消费金额的近似指标。如果你的原始数据里有成交金额字段那最好直接用金额算RFM会准确得多。3. 从原始日志到可分析的干净数据3.1 数据清洗分析前最重要的一步数据清洗是整个项目里最枯燥但最关键的环节。我拿到的原始数据有将近200万行刚开始图省事直接读进来算指标结果算出来的转化率高达60%多明显不对。后来排查发现数据里有大量重复记录和异常时间戳有些时间戳甚至是2030年这些脏数据把指标彻底带偏了。清洗流程我整理成四个步骤第一步是读数据时先看基本信息确认行列数和字段类型。用df.info()能快速发现字段类型是不是对的时间戳是不是object类型user_id是不是被误读成了数值型。第二步是去重。电商行为日志里重复记录很常见比如用户刷新页面可能导致同一条行为被记录多次。处理时我按所有字段完全一致的标准去重保留第一条。这里有个细节如果只按“用户ID商品ID行为类型”去重可能会误删用户在同一秒内的连续操作所以一定要用全字段去重。第三步是处理异常时间戳。原始时间戳是Unix时间戳格式大概是10位或13位数字。读取后先判断是否在合理范围内比如在最近一年内超范围的直接过滤掉。然后统一用pd.to_datetime转换成标准时间格式。第四步是行为类型校验。四种取值之外的记录直接删掉同时把大小写统一成小写。别小看这个步骤我遇到过一次数据里混了Pv和BUY如果不统一大小写分组统计的时候会出现两个“浏览”类目。3.2 核心指标的计算逻辑数据清洗干净后指标计算就水到渠成了。先说最基础的PV和UV。PV是页面浏览量直接统计行为类型为pv的记录数UV是独立访客数统计去重后的user_id数量。pv df[df[behavior_type] pv].shape[0] uv df[user_id].nunique()这两个指标是所有分析的基石。人均浏览深度可以用pv / uv得到这个数值越高说明用户对平台的粘性越强或者运营推荐做得越精准。统计每日PV和UV的时候先把时间戳转成日期字段再按日期分组聚合。转化率是电商项目最关心的指标之一。这里我按“行为链路”设计了一个漏斗计算逻辑浏览用户数、收藏用户数、加购用户数、购买用户数每一层都是去重后的用户数。以“购买用户数/浏览用户数”计算的浏览-购买转化率是整体转化率的主要参考而相邻环节之间的转化率则用于定位流失最严重的环节。user_counts df.groupby(behavior_type)[user_id].nunique() browse_users user_counts.get(pv, 0) buy_users user_counts.get(buy, 0) conversion_rate buy_users / browse_users if browse_users else 0计算复购率时要注意口径。我的定义是“购买次数大于等于2次的用户数 / 有过购买行为的用户数”。代码上先筛出所有buy行为按用户分组后统计每个用户的购买次数再对购买次数做条件计数。3.3 RFM模型怎么在行为日志中落地RFM模型是用户价值分析的经典方法三个字母分别代表最近一次购买时间、购买频率、购买金额。在只有行为日志的项目里M维度没有真实金额可以用我采用“购买次数”代替“金额”来做近似分层这一点在项目文档里必须写清楚否则别人看报告时会对M的含义产生误解。RFM实现分为三步。第一步是计算每个用户的R值、F值、M值。R值是距今最近一次购买行为的天数用当前日期减去用户最后一次购买日期F值是用户购买行为的总次数M值这里用每次购买的累计次数代理。第二步是把三个值分别划成高低两组针对R值天数越小说明越活跃属于高分组R中位数记为高针对F和M数值越大越有价值属于高分组。第三步是把高/低组合成8种用户类型但实际业务中最关注的是几个典型类型高R高F高M是重要价值用户低R高F高M是重要保持用户低R低F低M是一般挽留用户。r_score (reference_date - last_buy_date).dt.days f_score buy_freq m_score buy_count r_flag r_score.apply(lambda x: 高 if x r_score.median() else 低) f_flag f_score.apply(lambda x: 高 if x f_score.median() else 低) m_flag m_score.apply(lambda x: 高 if x m_score.median() else 低)RFM的分层结果最终会输出成Excel表同时把每个用户分层的汇总数画成可视化图表。这个模型最大的价值在于“可行动”运营可以直接把“重要价值用户”名单导出来做定向优惠把“一般挽留用户”用做唤醒活动而不是对所有用户一视同仁地发短信。4. 可视化大屏与交互系统实现4.1 可视化模块怎么设计才不乱可视化不是把图堆在页面上就行而是要有信息层级。我在设计大屏时把内容分成三块顶部是核心KPI卡片PV、UV、转化率、复购率中部是趋势类图表每日PV/UV趋势、各品类浏览分布下部是用户和商品深度分析RFM分布、热门商品Top10、行为漏斗。这样用户从上往下看先了解整体再看趋势最后看细节逻辑是顺的。还有一个设计原则是“一张图只讲一件事”。很多人做可视化喜欢把多个维度塞进一张图里比如既要看时间趋势又要把每个品类的数据都放在同一张折线图上结果图上一堆线条根本看不清。我的做法是每个图表独立输出必要时用Tab或者下拉框做切换。PyECharts的Tab组件可以很好地解决这个问题把多个图组合成带页签的页面既能展示足够信息又不显得拥挤。前端展示层我用了Flask。Flask在这里的职责很清晰接收浏览器请求从数据文件里读取或计算指标渲染模板并返回页面。整体流程是Python脚本先做数据清洗和指标计算结果保存为CSV或直接存在内存里Flask路由函数读取这些结果通过render_template把图表HTML嵌入页面。4.2 PyECharts核心图表的实现方式PyECharts最大的优势是API设计得比较直观。画柱状图先初始化图表对象再用add_xaxis和add_yaxis添加数据最后用set_global_opts配置标题和坐标轴。下面这段代码是每日PV趋势的折线图实现from pyecharts.charts import Line from pyecharts import options as opts line ( Line() .add_xaxis(date_list) .add_yaxis(每日PV, pv_list, is_smoothTrue) .set_global_opts( title_optsopts.TitleOpts(title每日PV趋势), tooltip_optsopts.TooltipOpts(triggeraxis), ) ) line.render(charts/daily_pv.html)漏斗图在PyECharts里叫Funnel非常适合展示浏览-收藏-加购-购买的用户流失链路。这里有个细节需要注意漏斗图的数据顺序是从上到下按数量从大到小排列传入的数据格式是[(浏览, 100000), (收藏, 30000), (加购, 20000), (购买, 8000)]这样的列表。如果你传反了顺序图会很难看。地图和饼图也很有用。如果原始数据里有用户所在城市字段可以用Map做地域分布图如果没有地域字段就用Pie做品类占比、行为类型占比等分析。饼图的标签建议显示百分比和数值只显示分类名会让读者完全不知道占比关系。4.3 Flask接入与多页面组织方式Flask部分的代码量不大但要注意静态资源和模板的组织。我的项目目录结构是这样的app.py作为入口templates/存放HTML模板static/存放CSS和JS文件charts/存放PyECharts生成的HTML文件data/存放清洗后的数据和报表。目录清晰之后哪怕几个月后再打开项目也能迅速找到对应功能的代码。from flask import Flask, render_template app Flask(__name__) app.route(/) def index(): return render_template(index.html) app.route(/rfm) def rfm_page(): return render_template(rfm.html) if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)运行python app.py后浏览器访问http://localhost:5000就能看到系统主页。debugTrue模式在开发阶段非常有用代码修改后服务会自动重启不用手动关掉再启动。但部署到服务器时一定要把debug关掉否则会暴露调试信息存在安全隐患。多页面组织上我建议按分析主题拆分成独立路由比如首页是核心指标总览/behavior是用户行为分析/rfm是用户分层/product是商品分析。每个路由渲染对应的模板模板里通过iframe嵌入PyECharts生成的HTML文件。这种方式简单可靠不需要额外的前端框架。5. 完整运行流程与关键代码演示5.1 六步跑通整体项目我整理了一套从零到一跑通项目的标准步骤照着做基本不出错第一步准备数据。把原始行为日志命名为user_behavior.csv放到data/目录下面。确认字段名和项目代码一致如果不一致需要在代码里做字段名映射。第二步安装依赖。创建虚拟环境按上面提到的安装命令装好所有依赖库。安装完成后用pip list确认关键库已经装好。第三步运行数据清洗脚本。这个脚本会读取原始数据输出去重、时间格式化后的cleaned_data.csv。如果数据量大这一步可能需要跑几分钟属于正常现象。第四步运行指标计算脚本。脚本会输出指标汇总结果到data/metrics_summary.csv同时生成RFM分层结果。第五步运行可视化图表生成脚本。这个脚本把所有指标换成PyECharts图表输出到charts/目录。第六步启动Flask服务。运行python app.py浏览器访问就能看到完整的可视化系统。每个步骤生成的文件都有明确用途这样无论是自己做后期维护还是别人接手项目都能快速理解整个流程的输入和输出是什么。5.2 数据清洗脚本的关键代码数据清洗脚本是整个项目的基石部分我把其中两个比较关键的代码块拿出来单独讲。第一个是时间戳的解析。原始数据里的时间是Unix时间戳需要先判断是秒级还是毫秒级。简单判断方法是看位数10位是秒级13位是毫秒级。秒级直接pd.to_datetime(df[timestamp], units)毫秒级则把单位改成ms。这个细节很实际很多人在这一步栽过跟头。import pandas as pd df pd.read_csv(data/user_behavior.csv) if df[timestamp].max() 10**12: df[time] pd.to_datetime(df[timestamp], unitms) else: df[time] pd.to_datetime(df[timestamp], units) df[date] df[time].dt.date第二个是去重逻辑。我用的方案是subset参数指定所有字段keepfirst保留第一条重复记录。如果去重后数据量减少了超过5%建议回去检查原始数据来源是否出了问题少量重复是正常的大量重复就需要谨慎了。5.3 指标计算与可视化联动的实现指标计算脚本的输出直接服务于可视化所以两者之间最好约定好数据格式。我通常把指标计算结果统一保存成CSV可视化脚本只负责读取CSV并绘图两类代码互不耦合。这样做的好处是后续如果换了数据源只需要重新生成CSV文件图表代码不用动。可视化脚本里有一个值得注意的联动技巧所有生成的图表HTML文件统一输出到charts/目录文件名使用固定前缀比如daily_pv.html、conversion_funnel.html、rfm_bar.html。Flask模板里用固定的iframe标签引用这些文件模板代码非常稳定。如果哪天想把图表从柱状图改成折线图只需要改生成脚本然后重新运行不需要改模板。6. 常见问题与排查技巧实录6.1 环境与安装问题项目运行过程中最常遇到的是环境问题我把几个高频率的坑列出来。第一个是PyECharts导入报错。如果看到cannot import name Bar from pyecharts基本可以确定是装了老版本或者代码写法不对应。解决办法是统一用新版APIfrom pyecharts.charts import Bar。第二个是Pandas读取CSV时中文乱码或编码错误。原始数据如果包含中文文件编码通常是utf-8或gbk。读取时指定编码参数报UTF-8错误的就换GBK看看df pd.read_csv(data/user_behavior.csv, encodingutf-8) # 如果报错改成 encodinggbk第三个是Flask模板里图表打不开。这种情况通常是iframe的src路径写错了检查路径是否从/开始以及charts/目录是否和templates/在同一个项目根目录下。我在项目中就把charts/放在静态资源路径下避免路径混乱。6.2 数据清洗与计算口径问题数据相关的问题往往最难排查因为不容易报错只会让结果看起来“怪怪的”。我遇到过最有代表性的一个问题是UV统计比实际用户数高出好几倍。排查后发现原始数据里同一个用户ID出现了两种不同的写法比如数字型和字符串型。解决办法是在清洗阶段统一把user_id转成字符串再聚合df[user_id] df[user_id].astype(str)另一个高频问题是转化率计算结果异常偏高或偏低。如果偏高多半是数据没去重如果偏低要检查是不是把浏览行为也当成用户基数了实际上如果业务要求算“从访客到下单”的转化率那么基数应该是浏览用户数而不是全部记录数。还有一个容易被忽略的坑是“跨天行为”的时间边界。比如用户当天23:59浏览了商品第二天00:01购买这算两天内的行为还是同一个完整链路我的做法是统一以购买时间为准来归属转化链路同时在报告中注明日期归属口径避免业务方对数据产生质疑。6.3 可视化输出与性能优化可视化模块常见的问题是图表数据量过大导致页面卡顿。PyECharts在前端渲染时如果一次性塞入太多数据点浏览器会明显变卡。解决办法有两个一是对时间序列做降采样比如只展示每周的趋势而非每天二是对Top类图表只展示前N条数据比如热门商品只看Top10而不是把所有商品都画出来。另外一个建议是尽量把耗时的数据计算和图表生成拆开。第一次运行脚本时可以把计算结果缓存成CSV后续打开页面时只读取缓存不再重复计算。尤其是几百万行数据的项目每次刷新页面都重新计算会让Flask服务响应非常慢。最后提一个调试技巧PyECharts生成的HTML文件可以直接用浏览器打开查看。如果某个图表显示空白先直接用浏览器打开charts/目录下对应的HTML文件定位到是数据问题还是Flask路径问题不要一上来就改Flask代码。这样能省下大量排查时间。我从实际跑这个项目的过程中体会最深的一点是做数据分析系统工程能力和分析思维缺一不可。工程上要把环境、依赖、目录结构这些基础打牢分析上要把指标口径、业务逻辑想清楚。很多人拿到项目代码就跑不通大部分问题不是出在代码本身而是环境和数据准备环节。另外在动手写代码之前我强烈建议先花点时间把原始数据看一遍用df.describe()和df.head()感受一下数据的实际形态再决定清洗策略。这套系统跑通之后再往里加新图表、新指标就会非常顺。本文还有配套的精品资源点击获取