Python数据分析实战：从采集到可视化搭建销量看板

事情的起因挺简单，有朋友想换机械革命的笔记本，来问我哪个型号卖得最好、什么时候买划算。我当时手头没有现成数据，就想着与其到处看评测猜来猜去，不如把销量数据自己跑一遍：采集、清洗、分析、可视化，最后做成一个能随时刷新的小看板。这个项目做完之后，我发现这套流程其实能复用到很多品类分析里，今天就把完整过程整理出来，给想做类似数据项目的朋友做个参考。

这个项目覆盖了数据采集、数据处理、数据分析、可视化这四个环节，用到的核心工具是 Python + Pandas + Plotly + Streamlit。数据源选的是公开可访问的电商页面和第三方比价平台，不涉及任何非公开接口，整体来说是一个标准的“从0到1”个人数据项目。无论你是刚接触数据分析的学生，还是已经工作、想练手数据工程的开发者，这篇内容都能给你一条能直接抄作业的完整路径。

1. 项目整体设计与思路拆解

1.1 为什么盯上“机械革命”这个品牌

选机械革命不是随手拍的。这个品牌的销量数据有个非常好的特征：产品线清晰、型号命名规律强、价格区间集中。机械革命的机型主要分几个系列，比如翼龙、蛟龙、耀世、极光X，每个系列下有不同配置版本，型号命名通常包含处理器代数和显卡型号，比如“蛟龙16 Pro R9-7945HX RTX4060”。这样规整的命名，对我来说做数据清洗和建模非常友好。

如果换成某些手机品牌，型号后缀一堆Pro、Ultra、S、SE、青春版，同一个型号还有不同存储组合和渠道专供版，数据清洗阶段就会耗掉大量时间。而机械革命的数据粒度清晰，核心字段就是“系列 + 处理器 + 显卡 + 价格 + 销量”，特别适合做一个从采集到可视化的全流程样板项目。

另外，机械革命在电商平台上的销量数据更新频率高，价格波动也比较明显，这让我在后续做时间序列分析时能观察到真实的市场变化，而不是一潭死水。比如大促节点前后价格和销量的联动关系，这种数据特征对分析练习来说比什么都值钱。

1.2 方案选型：先想清楚再动手

动手之前，我认真对比了几种方案组合。

第一套方案是“Scrapy + MySQL + Superset”。这套组合很重，优势是Scrapy能支持大规模并发采集，MySQL适合存储海量数据，Superset做BI报表很强。但它的劣势也很明显：环境配置复杂，对一个单人小项目来说有点“杀鸡用牛刀”。

第二套方案是“requests + Pandas + Matplotlib”。这套太轻了，Matplotlib做静态图表没问题，但交互性差，看数据的时候只能来回出图，体验不好。

最终我选的是“requests + Pandas + Plotly + Streamlit”这套组合。requests负责采集，Pandas做清洗和分析，Plotly负责生成交互式图表，Streamlit把整个分析结果打包成网页应用。这套组合最大的优点是：全部用 Python 完成，代码量控制在600行左右，不需要额外搭建数据库服务，数据量级在几千条这个级别时，Pandas + CSV文件完全够用。

还有一个很重要的考量是Streamlit的实时刷新能力。做销量数据看板，我最希望看到的效果是“每次运行脚本，图表自动更新”，Streamlit通过st.experimental_rerun和定时刷新机制让这个需求变得非常简单。

个人建议：不要一上来就追求大数据架构。数据量在1万条以内、单机能跑完的分析任务，用轻量级方案就能解决。真正在生产环境里，瓶颈往往在数据质量而不是数据量。

1.3 整体架构与数据流程设计

这个项目的整体数据流程分为五个阶段：

1. 采集阶段：通过公开页面获取机械革命各型号的数据快照
2. 存储阶段：原始数据落盘为CSV文件，按日期切片保存
3. 清洗阶段：处理缺失值、重复值、异常值，统一价格和销量的数据格式
4. 分析阶段：按系列、处理器、显卡、时间等维度做聚合计算
5. 可视化阶段：用Plotly生成交互图表，用Streamlit搭建设看板

这里有一个设计上的小细节：我把“原始层”和“清洗层”分开了。原始CSV文件不去动它，清洗之后的结果单独存一份。这样后面如果发现清洗逻辑有bug，不需要重新采集，只要跑一遍清洗脚本就行。

数据字段设计上，我最终确定了以下核心字段：

这个字段设计参考了标准数仓的建模思路，每个字段语义清晰，方便后续用 SQL 风格的操作做聚合分析。

2. 数据采集方案设计与实现

2.1 数据源摸底：能拿到哪些公开数据

做采集之前，最重要的事情是搞清楚“能拿到什么”。我当时调研了这几类数据源：

第一类是电商平台的搜索结果页。像京东、天猫这种平台，搜索结果里能看到每个商品的价格、累计评价数、店铺名。但有个问题是，商品页显示的是“累计评价数”而不是月销量，这个值和实际销量有一定偏差，趋势方向是一致的，但数值本身不能直接当销量用。

第二类是第三方比价和数据分析平台。市面上有一些做电商数据监测的服务商，通过前端展示页能看到部分公开数据快照。这类平台的信息是聚合处理过的，数据字段更干净，但更新频率不定，而且免费能看到的历史数据有限。

第三类是“什么值得买”这类消费决策社区。这些平台会有用户分享的爆料和商品信息，价格信息比较及时，但销量数据不完整。

综合对比下来，我觉得最可靠的做法是“以电商平台公开到货信息 + 第三方快照”做交叉验证，用多个数据源互相校准，而不是只依赖一个源。做数据项目的人一定要有这个意识：单源数据默认是不可信的，必须能让数据“对得上”。

提示：采集任何公开数据时，都要以不影响对方服务器正常运行、遵守相关服务条款为前提。个人学习项目控制采集频率，不搞并发轰炸，这是基本职业素养。

2.2 采集策略：增量式快照

我采用了“按天快照”的采集策略。每天在固定时间点跑一次采集脚本，把当天所有型号的价格和销量快照存下来。这样做的好处有三个：

第一，能追踪价格和销量的时间变化趋势。比如我想知道某个型号在大促前后的价格变化曲线，必须要有连续多天的快照数据。

第二，数据容错能力更强。如果某一天采集失败了，前面历史数据还在，不影响整体分析。

第三，可以为后续的销量预测模型积累训练数据。时间序列预测需要的就是连续时间点上的观测值。

单次采集的耗时控制在合理范围内。我的设置是每个请求间隔2-3秒，一共采集30个左右型号的页面，加上随机休眠时间，大约5分钟跑完全部。这个频率对个人项目来说算非常温和了。

2.3 采集代码实现

采集部分的核心代码是解析页面结构并提取关键字段。我简化了一下，用一个示例来展示整体思路：

python复制import requests
import pandas as pd
import time
import random
from datetime import datetime
from bs4 import BeautifulSoup

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
    "Accept-Language": "zh-CN,zh;q=0.9",
}

def fetch_sales_data(model_keyword, platform="京东"):
    """获取某个搜索关键词对应的商品信息列表"""
    url = f"https://example-search-url.com/search?key={model_keyword}"
    resp = requests.get(url, headers=HEADERS, timeout=10)
    soup = BeautifulSoup(resp.text, "html.parser")
    
    items = []
    for card in soup.select(".product-card"):
        # 提取商品名、价格、累计评价数
        title = card.select_one(".product-title").text.strip()
        price = card.select_one(".product-price").text.replace("¥", "")
        comments = card.select_one(".product-comments").text.replace("条评价", "")
        
        # 从标题中解析出处理器和显卡信息
        processor = parse_processor(title)
        gpu = parse_gpu(title)
        
        items.append({
            "model": model_keyword,
            "processor": processor,
            "gpu": gpu,
            "price": float(price),
            "sales": int(comments.replace("+", "")),
            "platform": platform,
            "date": datetime.now().strftime("%Y-%m-%d"),
        })
    
    time.sleep(random.uniform(2, 4))
    return items

def parse_processor(title):
    """从标题中解析处理器型号"""
    # 实际解析逻辑需要根据页面观察来写，这里做简化
    keywords = ["R9-7945HX", "R7-8845H", "i9-14900HX", "i7-14650HX"]
    for kw in keywords:
        if kw in title:
            return kw
    return "未知"

def parse_gpu(title):
    """从标题中解析显卡型号"""
    keywords = ["RTX4090", "RTX4080", "RTX4070", "RTX4060", "RTX4050"]
    for kw in keywords:
        if kw in title:
            return kw
    return "未知"

采集入口的逻辑就是遍历你要监控的型号列表，把每个型号的搜索结果都跑一遍，最后汇总到一个DataFrame里，追加写入CSV。这里有一个重要的经验：采集过程一定要做异常处理，某个请求失败不能中断整个任务，应该记录日志后继续下一个。

python复制def main():
    models = ["机械革命蛟龙16 Pro", "机械革命极光X", "机械革命翼龙15 Pro"]
    all_items = []
    
    for model in models:
        try:
            items = fetch_sales_data(model)
            all_items.extend(items)
            print(f"[OK] {model} 抓到 {len(items)} 条")
        except Exception as e:
            print(f"[FAIL] {model} 采集失败: {e}")
    
    if all_items:
        df = pd.DataFrame(all_items)
        df.to_csv("data/raw_sales.csv", mode="a", 
                  header=not os.path.exists("data/raw_sales.csv"), 
                  index=False)

2.4 采集过程中的几个坑

采集阶段最容易踩的坑有三个。

第一个是页面结构变动。电商平台的页面经常改版，CSS选择器可能一夜之间就失效了。我的应对办法是写一个“ sanity check ”，在每次采集结束后校验字段是否完整、价格范围是否合理，如果发现解析出来的价格大面积为0或者不在正常范围内，立刻报警提示手动检查页面结构。

第二个是反爬机制。请求频率太快会触发限制，但并不是越慢越好。我实测下来，单个关键词请求间隔2-3秒是一个比较平衡的点。同时也注意随机化请求间隔，而不是固定间隔，这样更接近真实用户的行为。

第三个是销量字段的口径问题。电商页面上显示的是“累计评价数”或“月售xx件”，不同平台的统计口径不一样，所以我在数据模型里专门加了platform字段，后续分析时可以直接做平台维度的对比，而不是把不同平台的数据直接相加。

3. 数据处理流程与清洗实战

3.1 数据质量问题的第一现场

采集回来的数据永远没有想象中那么干净。我第一次跑完采集，检查数据时发现了不少问题：

重复数据：同一个型号在同一天被采集了多条记录，可能是我多跑了一次脚本导致的。价格字段有脏数据：有的价格是“7499”还带了小数点和货币符号，有的直接是“预约抢购”这种文本，没办法转成数字。销量字段更乱：有的结果是“500+”，有的是“已拼500件”，有的干脆是空值。

时间字段格式不统一：有些日期是“2025-01-15”，有些是“2025/1/15”。处理器和显卡字段有缺失：部分商品标题没有写清楚具体型号，导致解析出来是“未知”。

这些问题如果不处理，后续分析和可视化全是错的。所以我把清洗阶段做了严格的流程拆分：缺失值处理、去重、格式统一、异常值剔除、字段工程。

3.2 清洗规则的具体实现

清洗的核心代码用Pandas实现。首先处理缺失值：

python复制import pandas as pd
import numpy as np

df = pd.read_csv("data/raw_sales.csv")
print("原始数据量:", len(df))

# 删除关键字段全为空的行
df = df.dropna(subset=["model", "price", "sales"], how="all")

# 价格为空的行，用同型号同配置的最近有效值填充
df["price"] = df.groupby(["model", "processor", "gpu"])["price"].transform(
    lambda x: x.fillna(method="ffill")
)

然后去重。我用的去重逻辑是：同一天内，同一个型号、处理器、显卡、平台，只保留一条记录。价格取最后一次采集的值，销量取最大值。

python复制df = df.sort_values("date")
df = df.drop_duplicates(
    subset=["model", "processor", "gpu", "platform", "date"],
    keep="last"
)

再处理格式统一。价格字段去掉货币符号和“元”字，销量字段去掉“+”和“件”字，统一转成数值类型。

python复制# 清洗价格字段
df["price"] = df["price"].astype(str).str.replace("¥", "")
df["price"] = df["price"].astype(str).str.replace("元", "")
df["price"] = pd.to_numeric(df["price"], errors="coerce")

# 清洗销量字段
df["sales"] = df["sales"].astype(str).str.replace("+", "")
df["sales"] = df["sales"].astype(str).str.replace("件", "")
df["sales"] = df["sales"].astype(str).str.replace("已拼", "")
df["sales"] = pd.to_numeric(df["sales"], errors="coerce")

# 统一日期字段
df["date"] = pd.to_datetime(df["date"])

3.3 字段工程：从原始字段到分析字段

光把数据洗干净还不够，为了让分析更顺手，我还做了一些字段工程。

第一个是增加“价格区间”字段。把连续的价格变量分箱成离散的区间，比如“5000-6000”、“6000-7000”、“7000-8000”，这样后续做价格带分布分析非常方便。

python复制bins = [0, 5000, 6000, 7000, 8000, 10000, 999999]
labels = ["0-5K", "5-6K", "6-7K", "7-8K", "8-10K", "10K+"]
df["price_range"] = pd.cut(df["price"], bins=bins, labels=labels)

第二个是增加“处理器代际”字段。从处理器型号里提取出代数信息，比如R9-7945HX是7000系列，i9-14900HX是14000系列。这样就能分析新一代处理器对销量的带动效应。

python复制def extract_cpu_gen(processor):
    if isinstance(processor, str):
        if "7945" in processor or "8845" in processor:
            return "新一代"
        elif "12700" in processor or "13650" in processor:
            return "上一代"
    return "其他"

df["cpu_gen"] = df["processor"].apply(extract_cpu_gen)

第三个是增加“是否大促”字段。根据日期判断当天是否处于618、双11等大促周期内。这个字段能在后续分析中帮我看清促销对销量的真实拉动效果。

3.4 清洗后的数据校验

清洗完成后，不要急着进入分析，先做一套数据质量校验，确认数据是可信的。我一般用这几个检查项：

• 数据量检查：清洗后数据量是否在合理范围内，如果比之前少了超过10%，可能清洗逻辑有问题。
• 唯一性检查：去重后的主键组合是否真的唯一。
• 范围检查：价格是否都在合理区间内，比如机械革命笔记本价格一般在4000到30000之间，超出这个范围的多半是脏数据。
• 时间连续性检查：按天统计记录条数，看有没有某一天的数据整体缺失。

python复制# 数据量检查
print("清洗后数据量:", len(df_clean))

# 重复性检查
dup_count = df_clean.duplicated(
    subset=["model", "processor", "gpu", "platform", "date"]
).sum()
print("重复记录数:", dup_count)

# 范围检查
print("价格范围:", df_clean["price"].min(), "-", df_clean["price"].max())
print("销量范围:", df_clean["sales"].min(), "-", df_clean["sales"].max())

# 时间连续性检查
daily_counts = df_clean.groupby(df_clean["date"].dt.date).size()
print("缺失日期数:", pd.date_range(
    start=df_clean["date"].min(), 
    end=df_clean["date"].max()
).difference(daily_counts.index).size)

提示：数据校验不是可选项，而是必选项。我见过太多“分析一时爽，清洗火葬场”的项目，最终结论全是错的，就是因为少了这一步校验。

4. 数据分析核心思路与关键结论

4.1 分析维度与思路

数据清洗完之后，我正式开始做分析。这个项目的分析思路不是随便拍脑袋，而是围绕“消费者购买决策”这个核心问题来展开的，什么问题值得分析，就看它是否能帮助回答“我该买哪台机器”这个问题。

我最终确定了四个分析维度：

第一个是“系列销量对比”。机械革命的几个系列各有定位，翼龙是轻薄本，蛟龙是性能本，极光X是性价比走量款。分析各系列的销量占比，能看出市场真正买单的细分品类是什么。

第二个是“价格带分布分析”。把销量按照价格区间聚合，看看消费者对机械革命这个品牌的接受价格带集中在哪个区间。

第三个是“处理器和显卡偏好分析”。不同处理器和显卡配置对销量的影响，本质上是消费者用钱投票的结果。这个维度能看出什么样的配置组合最受欢迎。

第四个是“时间趋势分析”。按天或者按周聚合销量和价格，观察整体走势，并结合大促节点做对比。

4.2 关键结论解读

分析结果有几个很有意思的发现。

系列销量上，极光X系列占到了总销量的40%以上，明显高于蛟龙系列。这说明在机械革命的用户群体里，性价比依然是第一驱动力，轻薄和高性能的溢价空间在笔记本市场并没有想象中那么大。

价格带上，6000-7000元这个区间贡献了最多的销量，5000-6000元紧随其后。有意思的是，8000元以上区间的销量占比很低，但单台利润更高，这符合笔记本市场“两头小中间大”的经典结构。

配置偏好上，RTX4060显卡是绝对的出货主力，占到了近一半的销量。R9-7945HX这颗处理器在高端配置中出现频率很高，但走量的反而是搭配R7的性价比版本。这个结论对想买的人有多少参考价值，取决于你是否愿意为“高U低显”或者“低U高显”的配置组合多花预算。

时间趋势上，我捕捉到了非常明显的促销脉冲效应：大促前一周销量走低，大促当天销量冲到峰值，大促结束后明显回落。价格口径也很有意思，大促期间降价幅度主要集中在300-800元，超过1000元的降价反而很少见。

python复制# 系列销量占比分析
series_stats = df_clean.groupby("model")["sales"].sum().sort_values(ascending=False)
series_pct = (series_stats / series_stats.sum() * 100).round(1)
print(series_pct)

# 价格带销量分析
price_stats = df_clean.groupby("price_range", observed=True)["sales"].sum().sort_values(ascending=False)
print(price_stats)

# 显卡偏好分析
gpu_stats = df_clean.groupby("gpu")["sales"].sum().sort_values(ascending=False)
print(gpu_stats.head(5))

4.3 从分析到洞察：为什么要做交叉分析

单一维度的分析只能告诉你“是什么”，交叉分析才能告诉你“为什么”。

比如我只分析系列销量，只能得出“极光X卖得好”这个结论。但如果把系列和价格带做交叉分析，就能看到极光X之所以卖得好，是因为它把RTX4060的价格打到了6000元价位段，精准击中了主流游戏本用户的预算上限。

再比如把处理器代际和价格带做交叉，就能看出新一代处理器产品是否真的有溢价能力，还是只是“加量不加价”的排列组合。

python复制# 系列与价格带交叉分析
cross = pd.crosstab(df_clean["model"], df_clean["price_range"])
print(cross)

# 显卡与价格带交叉分析
gpu_price = pd.crosstab(df_clean["gpu"], df_clean["price_range"])
print(gpu_price)

交叉分析的价值在于，它能帮你从“数据里有这个现象”推进到“这个现象背后的逻辑是什么”，这是整个项目里最有含金量的部分。

5. 可视化大屏的实现

5.1 可视化设计原则

数据分析做完，下一步是把它做成一个能看得爽的可视化看板。我之前用过ECharts、Apache ECharts、Grafana等各种工具，最后这次项目选择了Plotly + Streamlit的组合，原因是这两样东西组合在一起，可以用纯Python代码实现极高的交互性，不需要前后端分离。

在设计可视化的时候，我给自己定了三条铁律：

第一，一屏一主题。大屏名字就叫“机械革命销量数据分析看板”，那所有图表都必须围绕这个主题展开，不相关的图一律不放。

第二，图表要有层级。顶部放核心KPI卡片（总销量、总销售额、平均单价、监控型号数），中部放系列对比和价格带分布，底部放时间趋势和配置偏好，形成从“整体概览”到“细节拆解”的阅读路径。

第三，颜色有语义。用同一个色系代表同一个系列，在不同图表间保持一致。这样用户一眼就能认出“橙色这条线是极光X”，不需要看图例也能跟上信息流。

5.2 Plotly图表实现

Plotly最常用的三种图表在项目里都用上了。

销量趋势用的是折线图。X轴是日期，Y轴是销量，不同系列用不用颜色区分。Plotly的折线图默认支持悬停显示数据详情，鼠标放在点上就能看到具体数值，做数据查看非常顺手。我还加了一个范围滑块，可以自由缩放时间区间。

python复制import plotly.express as px

fig_trend = px.line(
    df_clean,
    x="date",
    y="sales",
    color="model",
    title="各系列销量趋势",
    labels={"date": "日期", "sales": "销量", "model": "系列"},
)
fig_trend.update_layout(
    hovermode="x unified",
    legend_title_text="系列",
)

价格分布用的是箱线图。箱线图能同时展示价格的分布区间、中位数、异常值，比单纯看平均值要信息量大得多。我能直观地看出不同系列的定价差异和稳定性。

python复制fig_price = px.box(
    df_clean,
    x="model",
    y="price",
    color="model",
    title="各系列价格分布",
    labels={"model": "系列", "price": "价格(元)"},
)

配置偏好用的是水平条形图。用条形图展示不同处理器、显卡组合的销量排名，比表格更直观。

python复制# 显卡销量排名
gpu_stats = df_clean.groupby("gpu")["sales"].sum().sort_values(ascending=False).head(10)

fig_gpu = px.bar(
    gpu_stats,
    orientation="h",
    title="显卡型号销量TOP10",
    labels={"value": "销量", "index": "显卡型号"},
)

5.3 Streamlit看板布局

图表做出来之后，我用Streamlit把页面搭起来。

Streamlit的布局体系很简单，核心是st.sidebar做筛选器区域，st.columns做多列布局，st.metric做KPI卡片，st.plotly_chart放图表。最终我做出来的是一个三行结构：第一行四个KPI指标卡片，第二行两个图表并排（系列销量占比和价格带分布），第三行是一个大图（时间趋势），最后一排是两个并排图（价格分布箱线图和配置偏好条形图）。

python复制import streamlit as st

st.set_page_config(layout="wide", page_title="机械革命销量分析")

st.title("机械革命销量数据分析看板")

# 侧边栏筛选
with st.sidebar:
    st.header("筛选器")
    selected_models = st.multiselect(
        "选择系列", 
        options=df_clean["model"].unique(),
        default=list(df_clean["model"].unique())
    )
    min_price, max_price = st.slider(
        "价格区间", 
        min_value=4000, 
        max_value=30000, 
        value=(4000, 20000)
    )

# 应用筛选
filtered_df = df_clean[
    (df_clean["model"].isin(selected_models)) &
    (df_clean["price"] >= min_price) &
    (df_clean["price"] <= max_price)
]

# KPI指标
col1, col2, col3, col4 = st.columns(4)
with col1:
    st.metric("监控型号数", filtered_df["model"].nunique())
with col2:
    st.metric("总销量(台)", f"{filtered_df['sales'].sum():,}")
with col3:
    st.metric("平均单价(元)", f"{filtered_df['price'].mean():.0f}")
with col4:
    st.metric("数据记录数", len(filtered_df))

5.4 实时刷新与自动更新

看板搭建最后一步是让它能自动更新数据。我的做法是写一个定时任务，每天凌晨2点跑一遍采集脚本，把当天数据写入CSV，然后Streamlit端通过st.experimental_rerun()和time.sleep()实现定时自动刷新。这样每天打开看板，看到的就是最新的数据状态。

python复制# 页面内定时刷新（30分钟一次）
if "auto_refresh" not in st.session_state:
    st.session_state.auto_refresh = True

if st.session_state.auto_refresh:
    time.sleep(1800)  # 30分钟
    st.experimental_rerun()

# 手动刷新按钮
if st.button("立即刷新数据"):
    st.experimental_rerun()

提示：Streamlit默认不自动刷新页面，如果不加定时刷新机制，你看到的永远是最初加载时的数据。做看板项目时，这个细节一定要处理好。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

整个项目做下来，我确实踩了不少坑，这里整理成一份问题排查表，给大家做个参考。

6.2 印象深刻的两个调错经历

第一次做这个项目时，我遇到过一个很隐蔽的问题。销量数据里出现了一个特别离谱的值，某个型号在一天内销量突增十倍。刚开始我以为是数据源有问题，后来仔细排查发现，是采集脚本在解析时碰到了一款促销活动页，页面结构里多个商品区块公用了一个销量元素，导致解析的时候把别人的销量算到了这个型号头上。这个问题真的不好肉眼发现，最后还是通过“按天检查单型号销量标准差”才发现异常的。

第二个印象深刻的问题是Streamlit的中文显示。默认情况下Plotly图表的中文文字在一些系统字体下会显示成方块。解决办法是在update_layout里显式设置字体：

python复制fig.update_layout(
    font=dict(
        family="Microsoft YaHei, SimHei, sans-serif",
        size=12,
    )
)

这个问题看似小，但如果忽略它，看板颜值直接掉一半，阅读体验会变得很差。

6.3 避坑经验总结

做这类数据项目，有几条经验我特别想分享。

第一，所有原始数据必须留底。不要直接改原始CSV，一定要在清洗后才覆盖。不然一旦清洗逻辑有bug，原始数据已经被污染，你就只能重新采集了。

第二，分析结论必须能溯源。任何一个你写出来的结论，都必须能通过一串代码重现，而不只是“我记得好像是这样的”。这要求所有中间结果都有产出记录，最好是每个分析步骤生成一个独立的输出文件。

第三，关注异常值，不要一砍了之。异常值可能代表脏数据，也可能代表真实发生的特殊事件。做清洗时要结合业务理解来判断，而不是机械地按照3σ原则把所有离群值删掉。

第四，代码和报告要分开。分析脚本负责产出数据，博文或报告只负责呈现结论。这样数据更新时，只需要重跑脚本，不需要改报告。

最后再分享一个关于做数据项目的心得

这个项目从开始到成型，前后花了我大约三周时间，大部分时间其实消耗在数据清洗和页面调试上，真正写代码的部分反而不多。但正是这个过程让我确信了一件事：一个数据项目的核心价值不是用了多牛的技术框架，而是你有没有把数据弄清楚，并从中读出真实的业务含义。

对于想自己动手做类似项目的朋友，我的建议是不要一上来就追求复杂。先从一个你真正关心的品类入手，比如某个你熟悉的数码品牌、美妆产品或者本地餐饮门店，把“采集、清洗、分析、可视化”这条链路完整跑一遍，你获得的东西会远超任何一门教程。

等这套流程跑顺了，再往里面加真实业务场景，比如自动化的增量更新、多数据源交叉验证、异常检测、甚至简单预测。每一步都是在前一步基础上自然生长出来的，而不是一开始就设计一个庞然大物。

数据项目的乐趣就在于，每一次分析都可能发现一个此前没注意到的小规律，这种从原始数据里挖出金子的过程，是其他工作很难替代的。