数据分析的基本流程是什么

刚上数据岗，最慌的不是不会写 SQL，而是不知道一件事该按什么顺序做：需求没问清就开始取数，取完发现口径不对，改完图又没人看。这篇把从接需求到交付的流程拆成几步，每步给一个能立刻做的动作和一条「做完怎么算过关」的判断标准，让你第一次接到活儿也有章可循。

刚上数据岗，最慌的往往不是写不出 SQL，而是不知道一件事该按什么顺序做。需求没问清就开始取数，取完发现口径对不上，图做完发出去没人看，回头还得重做一遍。这篇把从接需求到交付的流程拆成四步，每一步给一个能立刻上手的动作，再配一条「做完怎么算过关」的判断标准，让你第一次接到活儿也有章可循。

先把话说在前面：下面这套流程针对的是「有人提需求、有明确上线时间」的常规分析活儿。纯探索性的、老板让你「先随便看看有什么」的任务，流程要收紧范围而不是硬套；已经有成熟指标的团队，前半段可以直接跳过，重点放在验证和交付上。

第一步：把需求翻译成能验的问题

对方说「帮我看看最近怎么样」，这句话里没有任何能直接动手的东西。你要把它逼回三个要素：看哪个对象、比什么、什么算好什么算坏。三要素缺一个就先别取数，缺的那块大概率是对方脑子里也没想清楚，你问出来比你自己猜更省事。

1. 抽出三要素对象、对比基准、好坏标准。比如「某渠道近两周转化下降」就同时含了这三样，写下来再回读给对方确认。
2. 落成一句话假设把口头需求写成「因为 X，所以 Y 出现了 Z 变化」这种可被证实或推翻的句子，再列出验证它需要哪些字段。
3. 确认交付形式提前问清对方要的是一页结论、一张图还是一份可复现的过程文件，这决定你后面花多少时间在整理上。

第二步：取数与清洗，先对齐口径再动手

取数翻车基本都栽在口径上。动手前先确认三件事：时间范围怎么定义（自然日还是滚动窗口）、去重按什么键、异常值怎么处理。这三条不统一，后面所有结论都会互相打架，而且往往在交付当天才被发现。

• 清洗不是把脏数据全删掉，而是每一步留痕：筛掉了多少行、按什么规则筛的，写进备注供人复核。
• 同一个数用两种写法各跑一遍，结果能对上再往下走；对不上说明口径没定死，先停下来查，别硬凑。
• 清洗的通用规则站内已有专门文章讲透，这里不重复，遇到具体清洗手法去对应页面看即可。

第三步：分析与交叉验证

分析顺序建议先看总量再看拆分：整体趋势、按维度拆、最后看异常点。顺序倒了容易一叶障目，比如盯着某个小渠道的波动看了半天，其实大盘本身就在动。拆维度时优先拆那些业务上能被干预的维度，否则结论再漂亮也没人能用。

任何一条结论，至少找一个反向证据去撞它：换个时间窗口再算一遍、换个口径再算一遍、换个维度交叉看一下。结论撞完还稳得住，再写进报告。这一条能挡掉大部分交付现场被问住的尴尬。

事实

数据直接说出来的东西，比如某个指标在哪段时间涨了还是跌了。

推测

你对原因的猜测，必须单独标注为推测，并写明打算怎么验证它。

不适用条件

每个结论都要能说清它在什么范围、什么条件下不成立，比如样本太小或某维度缺数的时候。

第四步：交付与复盘

交付物分两层：给决策者的一页结论，包含结论、依据、建议动作和不确定项；给同行的可复现过程，包含口径、步骤或代码、数据来源。两层混在一起写，通常是决策者嫌太长、同行嫌太糙。

• 主动写出局限性：样本覆盖到哪、哪个维度没数据、结论在什么范围内适用，比等别人挑出来体面得多。
• 结论页控制在能被一口气读完的长度，细节全部放进可复现过程里。
• 交付后记一笔：这次哪个环节返工最多，下次同类需求从哪一步开始能省时间。
• 把这次用到的口径和字段整理成模板，同类需求下次直接改参数复用。
• 新人成长快慢，基本就靠交付后这一步有没有认真做。

数据源和依赖工具的选择也会影响交付节奏，涉及哪家 API 或中转服务的可用性，可以到站内工具目录和可信度检测页面核对当时的状况，别凭印象挑。

卡住了按这个顺序排查

卡住的时候最忌讳一上来就怀疑代码。按下面的顺序一层层往下走，多数问题在前两层就能定位，排查完也能说清是「哪一层出的问题」，而不是笼统的「数据不准」。

排查的价值不在解决这一次，而在于下次同类问题你能从中间直接切入。