获取数据不是「找个 Excel 打开」。它要回答：这个问题的数，现在落在哪套系统里、以什么形态存在、你能不能拿到、拿到的是明细还是已经加总过的结果。来源选错，后面所有计算都在替错误的表找理由。
一、分析用的数，通常不在一张「最终表」里
业务系统为了把订单做完、把货发出去、把钱记下，会把信息拆开存。分析要的「6 月每个渠道的支付金额」，往往是事后从这些拆开的记录里拼出来的。
常见来源可以分成六类。每一类能回答的问题不同，缺的东西也不同。
1. 业务库（交易正在发生的那套库）
店里每下一单、付一笔款、发一次货、退一次款，都会立刻记进一套库。这套库首先是给业务系统用的：保证下单成功、库存扣对、状态能改。分析只是事后来读。
好处是新、细：订单号、用户、商品、状态、精确到秒的时间都在。坏处是：它不是按「分析好用」来建的。测试单、未支付、已取消和成交单常常在同一张表里；同一笔订单还会改很多次。
例：一笔订单 6 月 8 日 10:00 下单，状态是待支付；10:07 付款，变成已支付；6 月 20 日退了一部分，又变成部分退款。你要「6 月已支付金额」，至少会碰到两种取法，数字不同。
| 取法 | 留下什么 | 6 月合计会怎样 |
|---|---|---|
| 当前状态 = 已支付 | 你取数那一刻，库里仍显示已支付的单 | 后来全额退掉的单，从 6 月里消失 |
| 曾经支付成功，按支付时间归月 | 只要 6 月付过钱 | 后来退款的单仍留在 6 月；和财务「实收」又会对不上 |
还必须定用哪一个时间：下单、支付，还是最后一次改状态。月末那几天，换一列时间，整批订单会搬到另一个月。
分析「卖了多少」时，测试单、未支付、已取消通常要排除。排除写在取数条件里。业务库不会因为你在做分析，就自动把这些行藏起来。
这套库同时在给前台下单用。大促时把几个月订单全扫一遍，可能拖慢下单。所以分析一般不直接打正在交易的那套库，而是用下一类已经同步好的分析库，或只允许读、不允许写的副本。
2. 数据仓库 / 分析库
上一类库正在给前台下单用，分析一般不直接打它。另有一套库，专门给分析读：把业务库里的订单、用户，以及日志、外部数据，按固定节奏抄过来，整理成比较稳定的表。这套库常叫数据仓库，也叫分析库。下面简称数仓。
和业务库比，数仓通常更适合取数：测试单可能已经剔除，同一指标尽量只保留一套算法，还有按天、按渠道加过总的结果表。代价是不新。常见是今天白天只能看到截止到昨天的完整数据，今天的订单要明天才进来。这种更新方式叫 T+1。周一上午做日报，表里最新一天往往是上周日，不是「本周一」。
数仓里至少要分清两层，不要拿错：
| 你取到的 | 一行是什么 | 还能做 | 做不了 |
|---|---|---|---|
| 订单明细 | 一笔订单里的一件商品（或一笔订单） | 按渠道、品类、天再切；抽查某一单 | 没有访客列时仍算不了转化率 |
| 销售日报 / 月报 | 某一天或某月已经加总后的一个数 | 复述「昨天 12 万」「6 月 80 万」 | 再拆商品、拆省份；和明细加总对不上时，多半不是算错，是口径本来就不是同一层 |
例：日报按财务口径，6 月是 62 万（不含税、已关账）。你用同一张日报去拆「哪个品类在掉」，拆不开，因为品类列已经在加总时丢掉了。你改去明细里按支付金额加，得到 80 万，和日报对不上。两数都可以对，差在含税、退款、确认时点。不要为了对上而改明细。要对，先问日报用的是哪一套口径。
日常分析取数，优先用数仓里的明细，而不是正在交易的业务库。用日报可以看趋势；解释「差在哪一块」，仍要回到还没丢掉维度的那一层。
3. 业务后台导出
运营后台、电商后台、客服系统里通常有一个「导出」按钮。点下去得到的是文件（Excel 或 CSV），不是库里的表。还拿不到数仓权限、或者只要应急看一眼时，这是常见办法。它是合法来源，但文件里装的只是：当前这个账号、当前这一屏筛选条件能看见的那一块。
看不见的事业部、已经归档的历史、界面上根本没展示的字段，导出里也不会有。你导出的是「华南 6 月已完成」，就不要把合计写成全国。
文件本身还容易在你不知情时少行、改列：
| 发生了什么 | 你看到的 | 实际 |
|---|---|---|
| 后台最多导出前 1 万行 | 合计 48 万，界面没报错 | 第 10001 行起整段消失，合计偏小 |
| CSV 用错编码打开 | 渠道变成乱码 | 「抖音」对不上，分组会裂开 |
| Excel 把文本当数字 | 用户号 0012 变成 12；长订单号变成 1.23E+15 | 再存一遍，主键坏了，以后对不上单 |
| 两次导出勾选不同 | 今天 80 万、昨天 73 万，以为掉了 | 一次含「今日未完结」，一次不含 |
例：周一导出勾了「已完成」，周二忘了勾，未完成单混进来，环比会跳。不是业务变了，是两次文件不是同一套筛选。
所以每次导出都要记下：谁导的、什么时候、日期范围、勾了哪些状态。下周要复现，靠的是这些记录，不是文件名里的「最终版」。打开 CSV 指定 UTF-8；订单号、用户号按文本导入，不要让 Excel 自动转成数字。导完立刻数一下行数：若刚好是 10000、50000 这种整数上限，先怀疑被截断，不要直接加总交差。
4. 投放 / 广告平台
巨量引擎、腾讯广告、Google Ads 这类后台，提供的是投放侧的数：花了多少钱、有多少曝光和点击，有时还有平台自己统计的「转化」。它回答「广告花得怎样」，不负责给你订单表里那一笔真实支付金额。
两边都叫「转化」，往往不是同一件事。
例：用户 6 月 28 日点了广告，7 月 2 日才付款 200 元。
| 来源 | 这笔 200 元算到哪 | 依据 |
|---|---|---|
| 广告后台 | 常算进 6 月那条广告（点击后 7 天内成交，记在点击日） | 平台的归因规则 |
| 订单表 | 算进 7 月（按支付成功当天） | 支付时间 |
一个算进 6 月投放效果，一个算进 7 月销售额。没有对错，只是规则不同。把后台的「转化金额」和订单表的「支付金额」画在同一张图上，却不加说明，读的人会以为两个数在比同一件事。
谈投放值不值，常用 ROI：成交 ÷ 花费。分母是花费，必须来自广告后台（或财务认的投放成本）。分子用哪一套成交，必须写明。
| 6 月 | 花费 10 万 | ROI |
|---|---|---|
| 分子用广告后台转化金额 40 万 | 4 | |
| 分子用订单表支付金额 28 万 | 2.8 |
两套都可以报，不能混成一个「ROI」去打架。没有花费这一列，就不要谈 ROI，只能描述成交。有花费，也不等于分子已经和订单对齐。要对齐，得先声明：成交用平台回传，还是用订单支付；时间用点击日，还是用支付日。
5. 财务关账文件
财务按入账规则认收入：含不含税、何时确认、是否已关账。这是和「后台销售额」最容易打架的来源。
- 能提供：对账、报税、管理层认的收入。
- 不能提供：按渠道、按商品拆开的运营动作（财务表常常没有渠道，或渠道粒度很粗）。
- 风险：6 月运营看「支付成功 80 万」，财务看「6 月确认收入 62 万」。两数都可以对，只是规则不同。取数时必须指定你这次用哪一套，并在结果里写明。不要为了「好看」挑一个。
6. 同事转发的表格
邮件、聊天工具里的「最新版销售.xlsx」。
- 能提供：别人已经算过的中间结果，有时能救急。
- 不能当权威：不知道筛选、不知道是否去重、不知道是第几版。文件名写「最终_真的最终_v3」仍然可能不是最终。
- 纪律：若必须用，复制一份存档，问清口径，能追溯到哪张底表。能自己按底表重取，就不要建立在别人的透视结果上再透视。
二、明细和汇总：取错一层，后面全部拆不动
同一句「要 6 月销售额」，可能拿到两种完全不同的东西。
明细：一行还对应一件真实发生过的事。例如订单明细里，一行是「某张订单里的一件商品」。
汇总：一行已经是加总结果。例如「2026 年 6 月 / 抖音 / 120 万」。
| 你拿到的 | 还能做的 | 做不了的 |
|---|---|---|
| 订单商品明细 | 按渠道、省份、品类、天再切；核对某一单 | 没有访客列时仍算不了转化率 |
| 按月全国合计 | 复述「6 月 80 万」 | 第 2 节的拆解：差在哪一块 |
| 按渠道月合计 | 渠道之间比 | 渠道内部再按品类切（除非再去取更细的） |
取数的第一条判断：后面要按哪些维度切，现在就必须把这些维度作为列取回来。 汇总表把维度丢掉了，清洗无法补回。不是脏，是这一层数据回答不了这个问题。
例：只要「月报上的 80 万」去解释为什么掉，你只能对着一个数发呆。必须取回带渠道、日期的明细（或至少取回「日期 × 渠道」的汇总）。后面写取数清单时，这一条会变成：后面要按哪些维度切，现在就必须把这些列取回来。
三、同一指标，多套系统对不上是常态
「销售额」在三处同时存在，并不保证三个数相等。
| 来源 | 这个「销售额」常常指 | 6 月可能得到 |
|---|---|---|
| 订单后台 | 下单金额，含未支付、含取消 | 95 万 |
| 数仓支付事实表 | 支付成功金额，未扣退款 | 80 万 |
| 财务 | 不含税、已关账收入 | 62 万 |
取数不是从三张表里挑一个「看起来合理」的。是指定这一次分析用哪一套，写出时间字段、含税与否、含退与否。另外两套如果必须出现，就并列成两列，各标注口径。
权威口径：组织里约定「对外公布、对财务对齐」时用哪一套。运营周报可以继续用支付金额，但必须在表头写「支付成功、未扣退款」，避免被财务当成入账收入。
四、拿不到，和拿错了，不是同一类失败
拿不到：数仓没有访客表，后台也导不出曝光。正当结论是：本次不做转化率。写进数据说明。不要用清洗去「估一个访客数」。
拿错了更危险：有订单明细，但取成了「当前状态 = 已完成」且用了发货时间，于是 6 月 30 日支付、7 月 2 日发货的单全部落到 7 月。问题能答，答案是错的。表面上交得出一张表。时间窗、去重、连接、口径，都是「拿错了」的高发点。
五、数还没取回来，先问清三件事
来源选对了，仍可能取回一份「看起来完整、其实不能当全国 6 月」的表。取之前问清下面三件。问不清，合计会偏，而且很难从数字本身看出来。
1. 这张表更新到哪一天
分析用的表，往往不是每秒都在变。常见情况是：今天白天看到的，只到昨天结束。今天发生的订单，要明天才进来。
例：周一上午做「本周日报」，表里还没有周一的单，最新一天其实是上周日。若标题写成「本周一」，读的人会以为周一已经卖完了。正确写法是把截止日期写出来：数据截至 2026-06-07（周日）。
这种「今天看到的是截止到昨天」的更新方式，常叫 T+1（T 是业务发生的那一天，+1 是隔一天才能用来分析）。不是所有表都是 T+1，有的更慢。取数前问一句：我现在取，能取到哪一天为止。
2. 你看见的是全部，还是一部分
账号权限会裁掉行。你只能看华南，导出或查询的结果里本来就没有华北、华东。合计比全国小，不是 6 月真的只卖了这么多。
例：全国 6 月实际 80 万，你的账号只有广东、广西，取回来 18 万。按「全国」去环比、去拆渠道，结论全错。取回来之后先问：这是全国，还是我权限内的那一块。权限内的分析可以做，但标题必须写「华南」，不能写「全国」。
3. 里面有没有不该进本次合计的单
业务库里，测试单、内部采购、加盟店订单往往也是合法记录，系统不会自动帮你剔除。分析「自营 6 月卖得怎样」时，这些单通常要排除。排除写在取数条件里，不要指望从十万行里用眼睛挑。
例：测试账号每天下一笔 0.01 元，全年几千行。不排除，订单量会被抬高，客单价被拉低。加盟店若算进自营，渠道结构也会歪。取之前问清：本次要不要测试单、要不要加盟、要不要未支付。问完写进筛选条件；没问就取，等于默认「所有状态、所有主体都算卖了」。
六、手里有什么表，就决定能回答什么问题
前面六类来源，不是让你背名单。拿到表之后要能立刻判断：这是哪一类、上面有哪些列、缺的东西要去哪一类找。缺的列，清洗变不出来。
假设现在手里只有两张表：
- 订单明细：一行是某张订单里的一件商品。属于上面第 2 类里的分析用明细，不是财务关账，也不是广告后台。
- 用户表：一行是一个注册用户。注册日期、性别在这张表上，订单明细里没有。
用「6 月为什么掉」对一下：
| 你想查 | 需要哪一类来源 | 这两张表有没有 |
|---|---|---|
| 6 月各渠道、各省卖了多少 | 订单明细：日期、金额、渠道、省份 | 有 |
| 人来少了，还是来了不买了 | 还要访客或曝光 | 没有。转化率 = 成交 ÷ 来人，缺「来人」就不能算 |
| 投放花得值不值 | 还要广告花费 | 没有。只能说卖了多少，不能说值不值 |
| 扣掉退款后实收多少 | 还要退款流水或财务关账 | 没有。金额是未扣退款的成交，不能叫实收 |
因此用这两张表，只能把「掉了」拆到渠道、省份、品类、新老客，不能写成「转化变差」或「投放不值」。真实取数也一样：常常只有订单，没有流量、没有花费。缺了就缩小问题，把限制写进结论，不要补一列假访客。
七、本课要点
获取数据，是从具体来源里，按已经写清的问题，把对的一层、对的范围拿到手。来源包括业务库、数仓、后台导出、投放平台、财务文件、同事表格；每一类能答的问题和会踩的坑不同。
明细才能再切；汇总只能复述已经加总过的结果。同一中文指标在不同系统可以同时正确但不相等，必须指定用哪一套。
下一篇讲表、行、主键、粒度。不先搞清一行是什么，后面把订单量加成明细行数，是取数里最常见的错。