我第一次踩进“数据分析”这个坑，是在一家年营收不到五千万的制造企业做运营顾问。老板说：“我们系统里存了三年数据，你帮我分析一下为什么今年利润下滑。”我当时信心满满地打开销售系统，结果数据库里“客户ID”字段填的是手机号、座机号、空值和“不详”四种格式，“订单金额”字段居然出现了负数，而“下单时间”这一列，有将近四分之一的记录是2099年。那一刻我意识到，学数据分析之前，得先学会跟数据打架。
后来我发现，绝大多数人，包括我自己早期，都犯了一个根本性错误：把“数据分析”当成了一堆术语的集合，然后试图用背单词的方式去理解它。结果就是，当你真正面对一张满是“p值”、“归因模型”、“数据湖”的报表时，你连从哪儿开始看都不知道。
这篇文章不是为了让你“认识”这些术语而写的。市面上那种“100个术语一网打尽”的清单，你收藏了也不会打开第二次。我打算换一种方式：按照一个数据分析师从接到需求到交付结论的完整工作流，把这20个核心术语放在它们实际出现的位置上去讲。你不需要记住它们，只需要理解它们为什么出现在那里，以及它们帮你解决了什么问题。读完这篇文章，你至少能做到一件事：拿到一份业务报表或数据需求时，能清晰地判断出“这活儿我该从哪一步开始干”。
先给你一个核心判断，这也是我从业七年、带过四届数据助理之后最想说的结论：数据分析不是一门“记忆型”学科，而是一门“逻辑型”学科。你记不住“假设检验”的定义没关系，但你得知道它解决的是“这个结果到底是不是运气”这个问题。你搞不清“数据湖”和“数据仓库”的官方定义也没关系，但你得知道你在做报表的时候，数据是从哪个“池子”里捞出来的，以及这个“池子”里的数据到底能不能直接用。
我见过太多人，包括一些号称“转行上岸”的数据分析师，把时间花在背诵术语定义上，结果做项目的时候，花了两周时间清洗数据，又花了两周跑模型，最后发现业务方想要的只是一个“上周销量为什么跌了”的归因分析。他们根本不需要什么“时间序列预测”，他们只需要把“周六促销”和“竞品降价”两个事件列出来，做一次简单的对比归因。所以，与其记住100个术语，不如掌握一条清晰的分析逻辑线。
我把它总结为“六层逻辑阶梯”：
这六个台阶，就是你现在看到的这篇“术语梳理”文章的真实骨架。每一个术语，都会被放在它所属的台阶上，告诉你它解决什么问题、它和上下级概念之间是什么关系。这才是真正“一网打尽”的方式，不是用网把鱼捞起来堆在岸上，而是用网把鱼按照它们的位置串起来。
在我辅导过的三十多个项目中，有超过一半的项目，问题出在“数据源头”上。不是数据不准，而是分析者根本不知道系统里那个“数据”是怎么来的。就好比你用超市里买回来的面粉做面包，但你不清楚这个面粉是哪个品种的小麦磨的、有没有掺了其他东西，做出来的面包好不好吃，全凭运气。
这是最基础、也最容易被低估的概念。很多人以为“数据就是Excel里的表格”，但实际工作中，80%的精力要花在把“非结构化数据”变成“结构化数据”上。
我的判断：如果你是一个刚转行的数据分析师，别急着学什么“机器学习”，先学会怎么把JSON和PDF里的数据变成Excel表格。这一步做不好，后面的所有分析都是空中楼阁。
ETL是“Extract（抽取）、Transform（转换）、Load（加载）”的缩写。简单说，就是把你从各个系统里“抽”出来的数据，经过“清洗”和“转换”，最后“加载”到统一的数据仓库或数据湖里。
我见过一个典型场景：一家零售企业，销售数据在“金蝶”里，会员数据在“CRM系统”里，库存数据在“WMS系统”里。三个系统之间没有打通。每周一，运营部的小姑娘要花大半天时间，从三个系统分别导出Excel，然后手动复制粘贴到一个表格里。这就是最原始的“手工ETL”。
行动建议：如果你所在的公司还没有上ETL工具，可以先从“自动化脚本”开始。用Python写一个简单的脚本，每天定时从三个系统导出数据，然后自动合并成一个Excel。这个脚本的成本可能不到一千块，但它能直接帮你把一个“数据采集”的痛点变成一个“数据可用”的起点。
这一层是最“脏”的活，也是最容易出成果的活。我常说一句话：数据分析这个行业，90%的时间在跟数据打架，10%的时间在写报告。而“打架”的主要战场，就是数据清洗。
数据清洗，不是“把脏数据去掉”这么简单。它包含三个核心动作：
专业判断逻辑：数据清洗不是“一刀切”的。你首先要搞清楚，你分析的这个“数据”是用来回答什么问题的。如果是为了分析“用户画像”，那么“用户年龄”的缺失值就不能随便删除，因为缺失本身也是一种信息。如果是为了分析“销售额”，那么“订单金额”的异常值就需要仔细甄别，是“促销满减”导致的负数，还是“系统错误”导致的负数，处理方式完全不同。
这两个概念，很多人讲不清楚，我换个方式讲：
我的判断：对于中小企业来说，一开始别急着建“数据湖”。先建一个“数据仓库”，把最核心的销售、财务、客户数据整理好，能做到“周报自动生成”就已经很好了。等数据量大了、业务复杂了，再考虑“数据湖”的事情。我见过太多中小企业在“数据中台”这个坑里浪费了几十万甚至上百万，最后发现连一个“月度销售报表”都跑不顺畅。
如果你把数据清洗干净了，接下来要做的第一件事，就是“描述数据”。描述性分析的核心，就是回答“发生了什么”这个问题。这一步是所有分析的起点，也是最容易出“错误结论”的环节。
这是很多新手最困惑的一对概念。我告诉你一个最简单的区分方法：指标是“被衡量的东西”，维度是“看这个东西的角度”。
具体案例：你问“上个月销售额是多少？”，这是指标。你问“上个月北京地区新用户的销售额是多少？”，这是指标“销售额”加上维度“北京”和“新用户”。
常见误区：很多人把“指标”和“维度”混为一谈。比如，在分析“用户留存率”时，把“用户活跃天数”当成了维度。其实，“用户活跃天数”本身也是一个指标，它可以用来划分“高活跃用户”和“低活跃用户”这个维度，但你不能直接拿它去“切片”分析。
描述性分析离不开统计量。但很多人只会用“平均值”，这是一个巨大的坑。
我的判断：在描述性分析阶段，永远不要只汇报“平均值”。至少加上“中位数”和“标准差”，才能让读者对数据有一个完整的认识。我辅导过的一个学员，在汇报“用户平均使用时长”时，一直被老板质疑“用户没用那么久”。后来我让他加上“中位数”和“标准差”，发现“中位数”只有平均值的一半，标准差却很大。这说明，数据被一小部分“超级用户”严重拉高了，大多数用户的使用时长其实很短。这个发现直接改变了公司的产品策略。
描述性分析告诉你“发生了什么”，诊断性分析则要回答“为什么会发生”。这是数据分析中最有价值、也最考验逻辑能力的阶段。
这是数据分析领域最经典的“雷区”。相关性不等于因果性，这句话你肯定听过，但真正理解它的人很少。
我的判断：在业务分析中，不要轻易下“因果”结论。你能做的，最多是“相关性”结论，然后提出“可能的原因”，再通过A/B测试去验证。我见过一个最典型的失败案例：一家电商公司发现“页面弹窗”和“用户转化率”之间存在负相关（即弹窗越多，转化率越低），于是直接把弹窗全部下线了。结果转化率没升反降。后来才发现，影响转化率的真正原因是“页面加载速度”，而弹窗只是恰好跟“加载速度慢”这个变量“共现”了，因为公司正好在弹窗系统上线后，同时上线了一个“更重的图片加载库”。
这是诊断性分析中一个非常经典的反直觉现象。简单说，就是：在分组情况下，每个组都呈现出某种趋势，但当把数据合并起来看时，趋势却完全相反。
具体案例：某大学有两个专业，A专业和B专业。A专业录取率是30%，B专业录取率是70%。但如果你把男女分开看：
你会发现，无论是在A专业还是B专业，男生的录取率都低于女生。但合并后，男生的总录取率（50%）却高于女生（40%）。
原因：因为女生大量报考了录取率较低的A专业（报考人数多），而男生大量报考了录取率较高的B专业。这个“分组内的样本量差异”导致了“总体的趋势反转”。
行动建议：在做诊断性分析时，一定要先“分组”再“合并”。如果发现“分组”和“合并”的结果不一致，就要警惕“辛普森悖论”的存在，找到那个导致“反转”的“隐藏变量”（在这里是“专业选择”）。
如果你已经能回答“发生了什么”和“为什么会发生”，那么下一步就是“接下来会发生什么”以及“我们应该怎么做”。这就是预测性和规范性分析做的事情。
A/B测试是“因果分析”的黄金标准。它的原理很简单：把一个用户群体随机分成两组（实验组和对照组），对实验组施加一个“干预”（比如改变按钮颜色、修改文案），对照组保持不变，然后比较两组的结果指标。
具体案例：我在一家电商平台做顾问时，负责“优化注册页面”。我们想测试“把注册按钮从蓝色改成绿色，是否会影响注册转化率”。我们做了三天的A/B测试：
看起来绿色按钮更优。但我们需要用“假设检验”来判断，这个0.6%的差异是“真实效果”还是“随机波动”。
假设检验是A/B测试的“裁判”。它告诉你，你这个实验结果“靠谱”的概率有多大。
我的判断：很多业务人员只看“p值”是否小于0.05，但p值本身不能告诉你“效果有多大”。你需要同时看“置信区间”和“效果量”。我见过一个案例，A/B测试结果显示p值小于0.05，但效果量只有0.1%。这意味着，虽然统计上“显著”，但实际业务价值几乎为零，你花了一周时间做测试，最后只提升了0.1%的转化率，这个投入产出比非常低。
终于到了“交付”环节。数据可视化不是为了“好看”，而是为了“高效沟通”。一个糟糕的可视化，会让你的分析结论大打折扣，甚至完全被误解。
我见过太多人，用“饼图”去展示“时间趋势”，用“柱状图”去展示“占比”。图表类型选错，比不画图更糟糕。
我的判断：“饼图”是初学者最容易滥用的图表。我建议你尽量少用“饼图”，多用“柱状图”或“条形图”。因为人对“面积”和“角度”的感知不如对“长度”的感知准确。一个“三分之二”占比的饼图，你可能看不出它到底是“65%”还是“70%”，但一个柱状图，你可以精确地看出它“高”了多少。
数据可视化不只是“画图”，更是“讲故事”。一个合格的仪表盘，应该能让读者在30秒内理解“核心结论”。
行动建议：在交付可视化报告时，永远先写“结论”和“建议”，再展示“数据”和“图表”。你的老板和业务方，没有时间也没有耐心去“读”你的图表。他们需要你直接告诉他们“发生了什么、为什么、怎么办”。
现在，我们把这六个台阶串起来，回顾一下：
这就是一个完整的数据分析工作流。你不需要记住每一个术语的官方定义，但你需要在面对一个具体问题的时候，能清晰地判断出“我现在处于哪个台阶”，以及“下一步该往哪里走”。
最后给你一个行动建议：下一次，当你拿到一个数据分析任务时，不要急着“跑数据”。先花10分钟，用这个“六层逻辑阶梯”框架，画出你的“分析路线图”。你是从“数据清洗”开始，还是从“描述性分析”开始？你的“诊断性分析”需要用到“相关性分析”还是“A/B测试”？你的“可视化”应该用什么图表类型？把这个线路图画清楚，你的分析效率至少能提升50%。
如果这篇文章对你有帮助，你可以把它当作一个“工具书”，在遇到具体问题时回来翻一翻。你也可以在评论区告诉我，你工作中最常用的数据分析术语是哪个，以及你用这个术语解决过什么问题。
我刚开始学数据分析，看到很多教程直接讲模型和可视化，但实际工作中我发现大部分时间都在处理脏数据。数据清洗到底包括哪些步骤？有没有什么高效的方法？
数据清洗是数据分析最基础也最关键的环节，包括缺失值处理、异常值检测、重复值删除、格式统一等步骤。我曾经处理过一个电商订单数据，因为系统bug导致10%的订单金额为负数，如果不处理直接分析，平均订单金额会被严重拉低。我的经验是数据清洗没有捷径，但可以建立标准化流程。
比如用Python的pandas库，我会先写一个清洗函数，包括检查缺失率、异常值阈值、重复项等。对于缺失值，如果缺失率低于5%，我通常删除；如果高于5%，我会用均值或中位数填充，但必须注明。对于异常值，我会用3σ原则或箱线图识别。数据清洗不是一次性的，每次数据源变更都要重新检查。
我建议新手养成先看数据概况的习惯，用df.info()和df.describe()快速了解数据质量。
我在做报表时，经常听到业务同事说“我要看用户数”，但有时他们又按地区、按时间看。指标和维度这两个词听起来很简单，但实际沟通中经常搞混，导致报表做错。到底怎么清晰区分？
指标是衡量业务结果的数值，比如销售额、用户数、转化率；维度是观察指标的角度，比如时间、地区、产品类别。一个经典比喻：指标是温度计上的读数，维度是测量地点和时间。我曾在某零售企业做分析，业务人员要求"看销售额"，但没说维度。我追问后才知道他们要按门店和月份看。如果维度不明确，指标没有意义。
我的判断是：区分它们的关键是问"这个数值是怎么计算的？"（指标）和"我们想从哪些角度切分？"（维度）。在数据表中，维度通常是分类变量，指标是数值变量。我建议业务人员用"按XX维度看XX指标"的句式，比如"按月份看销售额"，这样沟通清晰。还有一个常见错误：把"占比"当成维度。
占比是指标计算的结果，不是维度。比如"地区销售额占比"中，地区是维度，销售额占比是指标。
我们公司业务增长很快，数据越来越多，IT建议建数据仓库，但CTO说数据湖更灵活。作为数据分析师，我该支持哪个？实际使用中两者到底有什么不同？小公司资源有限，如何选择？
数据仓库是经过清洗、建模的结构化数据存储，适合报表和固定分析；数据湖是存储原始格式数据的集中式存储，适合探索性分析和机器学习。我曾在某初创公司，一开始为了灵活性建了数据湖，结果数据质量参差不齐，业务部门抱怨报表出不来。
后来我们调整为"数据湖+轻量级数据仓库"的混合方案：数据湖保留原始数据，然后通过ETL抽取关键数据到数据仓库（用PostgreSQL+dbt建模）。我的经验是：小公司如果分析需求明确，优先建数据仓库，成本低、见效快；如果业务模式不确定，需要大量探索，则先建数据湖。
但一定要有数据治理，否则数据湖会变成数据沼泽。具体数据：我们当时数据湖存储成本每月2000元，数据仓库建模后报表开发时间从2周缩短到2天。建议：别盲目追求"湖仓一体"，先解决核心报表需求。
我最近在学习统计学，看到辛普森悖论的例子：两组数据分别看趋势一致，但合并后趋势相反。这听起来很反直觉，实际工作中真的会遇到吗？怎么避免被误导？
辛普森悖论是指当数据分组时呈现的趋势，在合并后消失甚至反转。我亲身经历过：某电商平台分析转化率，整体看A渠道转化率5%，B渠道4%，A更好。但按用户新老分组后，新用户中B渠道转化率更高，老用户也是B更高。原因在于A渠道吸引了大量新用户，新用户本身转化率低，拉低了整体。
这个悖论告诉我们：只看汇总数据可能得出错误结论。我的判断是：数据分析师必须养成"分层分析"的习惯，在做对比时，要考虑混杂变量。具体方法：用辛普森悖论检测工具或手动计算分组和总体趋势。我建议在分析报告中先展示总体趋势，再按关键维度分组展示，并注明是否存在悖论。
这对决策非常重要：如果只看整体，可能会错误地放弃B渠道。实际案例中，某医疗研究也因为辛普森悖论导致错误结论。所以，永远不要轻信汇总数据。
读者评论
文章用工作流串联术语的方式很实用，比单纯背定义强多了。我当初学的时候就卡在数据清洗上，看了这个终于知道怎么处理缺失值和异常值了。
作者对数据仓库和数据湖的比喻很形象，图书馆和仓库的例子让我一下子明白了区别。中小企业确实应该先建仓库，别盲目跟风搞数据湖。
最常见的问题就是把指标和维度搞混，文章里那个销售额加上北京和新用户的例子太接地气了，终于知道怎么正确切片分析了。
六层逻辑阶梯的框架值得收藏，特别是从数据采集到可视化的一整套流程，新手照着这个顺序学能少走很多弯路。
文中提到90%时间在跟数据打架，10%写报告，太真实了。手动ETL那个场景我深有体会，建议很实用，先写个自动化脚本确实能解决大问题。