基于 Python 的手机品牌销售数据分析与可视化系统
有需要本项目的代码、文档、完整资源，或者需要部署调试的朋友，可以私信博主。
图 1 系统整体技术链路展示
一、项目起点：把手机销售数据变成可以行动的判断
我做这个系统的出发点很直接：手机销售数据量大、字段杂、变化快，如果只靠 Excel 或零散脚本去看，很难真正看清市场节奏。一次促销活动什么时候爆发、哪些省份贡献更高、哪些型号更受欢迎、会员和学生用户有什么差异、售后和退货是否跟销售高峰同步，这些问题都藏在订单明细里。只有把数据整理成一条完整链路，才能让分析结果从“看过了”变成“能用上”。
整个项目围绕手机品牌销售数据展开，原始数据包含订单时间、支付时间、出库时间、完成时间、手机型号、销量、价格、会员身份、学生身份、收货省市区、售后处理等信息，整体规模达到百万级。开发时我没有把它做成单纯的图表集合，而是按照数据工程的思路，先完成数据清洗和仓库分层，再设计指标表，最后接入可视化大屏和后台管理页面。后续又补充了配送时长预测模型，让系统从统计分析进一步走向智能预测。
图 2 原始订单数据集字段展示
二、数据处理：先解决“数据能不能用”的问题
项目第一步不是画图，而是把数据处理干净。原始订单来自多个 CSV 文件，不同文件字段数量和字段格式不完全一致，直接拼接很容易造成列错位、时间格式混乱、缺失值误判等问题。我先通过 Python 批量读取文件，统一字段名称，再对订单时间、支付时间、出库时间、完成时间等字段做标准化处理，使它们能够被后续 SQL 分组、趋势统计和模型训练稳定调用。
文本字段也做了必要清理，例如商品名称、会员标识、学生标识和售后标志中可能存在空格、特殊字符或格式不统一的情况。对于这类内容，我用正则和字段映射方式完成归一化，避免同一个含义在数据库里被拆成多个类别。值得注意的是，部分售后字段为空并不一定代表数据质量问题，它更多是业务状态没有触发，所以没有简单删除，而是结合业务含义保留。这样处理后，数据既保持真实业务特征，又能支撑后续分析。
图 3 数据合并、清洗与字段映射过程
三、仓库分层：让百万级数据跑得稳、查得快
清洗后的数据继续以 CSV 形式保存并不合适。百万级订单加上二十多个字段，文件体积大，筛选慢，也不利于复用。我把数据写入 MySQL，并参考数据仓库的思想设计了 ODS、DWD、DWS、ADS 四层链路。ODS 层负责保存原始数据，保证可追溯；DWD 层完成字段标准化和明细清洗；DWS 层提前聚合常用指标；ADS 层直接面向可视化页面和业务查看。
这个分层设计最大的价值是把“原始明细”和“可视化结果”分开。前端不需要每次都从百万级明细表重新统计，页面只要读取已经加工好的指标表，就能快速展示结果。比如每日订单量、每日销售额、每日退货率、各省订单量、城市订单排名、机型销量、平均售价、会员购买量、学生用户购买量等指标，都可以在汇总层提前计算好，再由应用层直接读取。
图 4 MySQL存储与数据仓库分层结果
四、指标分析：从销售趋势看到市场结构
在销售趋势部分，我重点关注订单量、完成量、销售额、售后申请和退货率几个指标。图表中可以明显看到大促节点附近的尖峰，销售额和订单完成量在短时间内集中上涨，随后快速回落到平稳区间。售后申请和退货订单并不是同步爆发，而是相对销售高峰有一定滞后，这一点很符合真实电商业务规律：订单集中发出后，质量问题、物流体验、冲动消费带来的退换货会在后续几天逐步显现。
地域分析可以帮助判断市场重点区域。省份热力图和城市排名显示，东部沿海以及人口密集省份订单量更高，深圳、北京、广州等城市表现突出。对企业来说，这类结果不是简单“哪个地方卖得多”，而是能反向提示渠道投放、仓储布局和营销资源分配。用户画像方面，Plus 会员订单占比接近普通用户，说明会员群体对平台活动和品牌促销有较强响应；学生用户占比较小，但与高性价比机型之间存在潜在关联，适合进一步做细分营销。
产品层面，系统展示了不同型号的销量排名和平均售价。高销量机型通常集中在性能与价格平衡较好的产品上，而高端折叠屏或旗舰机型虽然销量没有绝对优势，但平均售价更高，利润贡献可能更明显。把销量、价格和用户身份放在一起看，就能从“卖了多少”进一步分析“卖给谁、以什么价位卖、在哪些区域卖”。
图 5 销售趋势、售后申请与退货率分析
图 6 区域分布与用户画像分析
图 7 产品价格、销量、城市与订单结构分析
五、可视化大屏：从静态页面到动态系统
可视化部分我做了两套路径。第一套是基于 Pyecharts 的组合大屏，适合快速生成 HTML 页面，部署简单，图表美观，浏览器打开就能查看。对于项目汇报、成果展示或者离线演示来说，这种方式非常轻量，也便于把多个图表组合在同一个页面中。
第二套是 Flask + ECharts 的动态大屏。这里的思路是把后端数据接口和前端图形渲染解耦：Flask 负责读取 MySQL 中的指标表，并通过 API 返回 JSON；ECharts 负责在浏览器端渲染折线图、柱状图、饼图、地图等组件。相比静态 HTML，动态大屏更适合频繁更新的数据场景，后端数据一变，前端刷新即可重新获取结果，不需要重新生成页面文件。
大屏布局上，我把销售趋势、订单完成、退货率、城市订单、产品销量、省份热力、会员画像等模块放到统一页面里。左侧偏趋势，中间偏核心业务结果，右侧偏结构和画像。这样看数据时不用在多个页面反复切换，整体的视觉冲击力和信息密度都更强。
图 8 Pyecharts与ECharts大屏展示
六、系统集成：把可视化结果放进可登录平台
单独的大屏页面虽然能展示结果，但实际使用时还需要入口、权限和管理功能。因此我进一步把可视化页面集成到 Flask 系统中，做了登录、注册、用户管理、权限升级、个人信息管理、主题切换和页面跳转等功能。普通用户可以进入系统查看分析结果，管理员可以维护用户信息和权限。
系统前端使用 HTML、CSS、JavaScript 和 Layui 实现页面布局与表格交互，后端通过 Flask 负责路由、会话管理和数据接口。对于管理端，用户列表支持编辑、删除、权限调整等常见操作；对于展示端，用户可以通过侧边栏进入不同分析页面，也可以切换主题和全屏查看大屏。部分界面截图在整理时已经做了账号、邮箱、电话等信息脱敏，只保留功能结构和页面效果。
图 9 系统登录、指标查看与后台管理界面
七、配送时长预测：把机器学习接到业务链路中
除了销售数据可视化，我还扩展了订单配送时长预测模型。这个模块使用 LightGBM 回归模型，把“出库时间”到“完成时间”的间隔作为预测目标，并从订单、用户、商品、价格、时间和地域中提取特征。比如收货省份、收货城市、收货区县、是否 Plus 会员、是否学生、订单类型、订单种类、手机型号、优惠幅度、出库星期、出库日期等字段，都可以为模型判断配送时长提供线索。
一开始只使用静态字段时，模型能够捕捉到城市、省份和会员身份带来的差异，但对节假日、周末、大促后积压这类时间因素不够敏感，预测误差偏高。后续加入出库星期和出库日期后，模型对配送节奏的理解明显增强。优化后结果中，R² 提升到 0.8109，MAE 降到约 0.3846 天，说明时间特征对履约预测非常关键。
特征重要性也给了比较直观的解释：优惠幅度、出库星期、出库日期、收货城市、收货省份等变量贡献较大。这个结果很好理解，优惠幅度往往对应促销场景，促销又会带来集中下单和履约压力；时间特征反映仓库与快递节奏；地域特征对应物流网络和距离差异。这样一来，模型不只是给出一个预测值，还能帮助解释配送时长为什么会变长。
图 10 LightGBM配送时长预测特征工程
图 11 配送时长预测模型训练、评估与特征重要性
八、技术栈与项目完整性
从开发链路看，这个项目覆盖了数据分析系统中比较完整的一套技术组合：Python 负责数据清洗和分析脚本，pandas 处理原始文件，MySQL 承载数据仓库和指标表，SQL 完成多维聚合，Pyecharts 适合快速生成离线图表，Flask 提供 Web 服务和接口能力，ECharts 负责动态大屏渲染，Layui 用于后台管理界面，LightGBM 则负责配送时长预测。
我在设计时尽量把每一层职责分清楚：原始数据不直接暴露给前端，指标分析不写死在页面里，模型预测也不和图表渲染混在一起。这样做的好处是后续扩展比较方便。将来如果要接入新的品牌数据、增加销量预测、加入用户聚类、做地区库存预警，或者把定时任务加到数据更新流程里，都可以在现有结构上继续迭代。
整体来看，这个项目既可以作为 Python 数据分析与可视化练手项目，也可以作为毕业设计、课程设计、项目展示或企业数据看板的基础模板。它不是只有几张图，而是从数据清洗、数据库建模、指标加工、动态可视化、系统集成到机器学习预测都有覆盖，比较适合展示完整的数据项目能力。
九、后续可以继续优化的方向
后续我会优先考虑三类优化。第一类是数据更新自动化，把每日新增订单通过定时任务写入数据库，并自动刷新 DWS 和 ADS 指标表。第二类是预测能力增强，除了配送时长，还可以继续做销量预测、退货风险预测、会员价值分层和区域需求预警。第三类是可视化体验升级，比如加入筛选器、时间范围选择、品牌对比、异常提醒和导出报告功能。
如果要进一步向企业级场景靠近，还可以引入缓存、消息队列和流式计算，让系统支持更高频率的数据刷新。大屏端也可以加入更多交互逻辑，例如点击某个省份后联动展示城市和机型，点击某个型号后展示价格趋势和用户画像。这样系统就不仅是展示结果，而是能支持运营人员逐层追问。
每文一语
真正有价值的数据项目，不是把图表做得更热闹，而是让每一次整理、每一次分析、每一次预测，都更接近真实业务中的下一步行动。