「销量为什么跌了」不是需求，是 5 个没人告诉你的前提-CDA数据分析师官网

热线电话：13121318867

首页大数据时代「销量为什么跌了」不是需求，是 5 个没人告诉你的前提

「销量为什么跌了」不是需求，是 5 个没人告诉你的前提

2026-10-03

写在开头

老板在微信上甩来一句：


"帮我看下为什么销量跌了。"
”

你回工位，打开 SQL，开始写。查订单表、拉近三个月、按天拆、按品类拆……两天后你把一份二十页的分析发过去。

一分钟后，对方回你一句：


"这不是我想看的。"
”

问题出在哪？不在你的 SQL，在你直接开始写 SQL 了。

真实的业务问题，几乎都是这种"半句话需求"。它不是一份分析规格说明书，它是一句省略了大量前提的口语——而把这句话补齐的过程，才是分析师真正的工作。

原文给出的判断很干脆：一个业务问题，平均藏着 5 件对方没说出口的事。把这 5 件敲定，写查询只要几分钟；跳过它们，你会把错的东西做两遍。

一、每个业务问题，都藏着 5 个没人说出口的东西

拿一句最典型的问题举例——"哪些客户快要流失了？"

这根本不是一次查询。它会映射到十几种完全不同的写法，取决于下面这 5 个问题的答案：

"客户"指什么？ 是一个账户？一份订阅？一个付费主体？还是一个用户？在很多公司里，这是四样不同的东西，在数据库里对应四张不同的表。
"快要"是多快？ 未来 30 天内？在续约日之前？还是本季度结束前？
"流失"指什么？ 取消订阅？到期不续？降级到免费版？还是用量掉到某个阈值以下？每一种定义，都会产出一份不同的名单。
"风险"用什么信号判断？ 用量下滑？客服工单？没参加季度回顾会？支付失败？销售副总心里大概有直觉，但他没说出来。
他们拿到答案要做什么？ 如果目的是派客户成功经理上门挽回，名单要按可挽回程度排序；如果目的是预测收入，就要按合同金额排序。


这些不是极端情况。**业务负责人问的每一个问题，都带着这种模糊性。**在把模糊解开之前就开始查数的分析师，会拿到一批"技术上完全正确、但回答了错问题"的结果。
”

更麻烦的是组织动力学的部分：副总不想花 20 分钟跟你定义术语，他觉得他问了个很简单的问题，理应很快得到答复；而你也不想显得不配合，不想甩出一长串澄清问题把人劝退。

于是最常见的剧本是：你猜了一下，花一天把查询做出来，交付，然后听到那句"这不是我的意思"，接着进入下一轮。

**一个小时的定义工作，换掉的是一到两轮返工。**这笔账，几乎永远划算。

二、先判断是"哪一类问题"，就知道该先解哪个歧义

来自销售和收入条线的提问，绝大多数落在 5 个类别里。知道它属于哪一类，你就知道该先追问哪一件事。

问题类别	典型问法	翻译时要先定下来的事
健康与风险	"哪些客户有风险？"	用什么行为信号定义健康/风险、阈值划在哪、评估窗口多长
业绩表现	"这个季度我们做得怎么样？"	看哪个指标、看哪个层级、拿什么做基准
预测	"这个数我们能完成吗？"	预测区间、预测方法、以及方法里隐含的假设
分群	"谁是我们最好的客户？"	分群维度、"最好"怎么量化、分群结论要支撑什么决策
归因	"到底是什么起了作用？"	结果怎么精确定义、候选原因有哪些、用哪种分析能给出有用的信号

逐个拆开看：

1. 健康与风险类


"哪些账户有风险？""我们的企业客户健康吗？""该担心谁？"
”

这类问题要求你基于可观察的信号构建一个健康分或风险分。翻译工作包括三件事：定义哪些行为信号代表健康、哪些代表风险（登录频次、功能使用、客服互动、增购行为）；设定区分健康与风险之间的阈值；选择评估用的时间窗口。

同一个"14 天没登录"，在一个日活产品里和一个月度报表产品里，是完全不同的信号。

2. 业绩表现类


"这个季度我们做得怎么样？""哪些销售代表表现好？""目标达成了吗？"
”

需要澄清三件事：看哪个指标（签约额、管道额、赢单率、成交周期）、看到哪个层级（公司、团队、个人、单笔交易）、跟什么比（目标、上季度、去年同期）。

同一句"我们做得怎么样"，会因为这三个选择而变成完全不同的分析。

3. 预测类


"我们能完成目标吗？""管道覆盖够不够？""有多少收入有流失风险？"
”

预测类问题特别难，因为它要求把历史数据和前瞻性假设拼在一起。翻译工作包括：定义预测区间、选择预测方法（加权管道、历史转化率、回归模型），以及把每种方法里隐含的假设明确说出来。

比如"按管道加权"的预测，假设是各阶段转化率稳定——但如果市场或产品已经变了，这个假设就不成立了。

4. 分群类


"谁是我们最好的客户？"
”

听起来简单，但"最好"可以是收入最高、增长最快、互动最深、留存最好，或者最愿意转介绍——每一种定义产出一份不同的名单，指向不同的战略含义。

分群类问题需要你定义三件事：维度（凭什么把一群客户和另一群区分开）、指标（每群里你到底在衡量什么）、目的（这个分群要支撑什么决策）。

如果副总想知道"最好的客户"是为了做案例宣传，那答案跟"为了定价格策略"要的名单完全不同。

5. 归因类


"什么在起作用？""流失为什么突然涨了？""企业单量增长是什么带动的？"
”

归因类最难翻译，因为它问的是因果关系，而数据本身很少能证明因果。翻译工作包括：精确定义结果、列出候选原因、选择一种能给出有用信号的分析方法（相关性分析、队列对比、时间序列分析）——同时对"用观察数据做因果推断"的局限保持诚实。

三、翻译清单：把问题落到"能查"的 5 个要素

判定了问题类别、把明显的模糊点解开之后，就把问题映射到具体、可查询的指标上。按顺序走这 5 个要素，这件事就变得系统化。

1. 定义实体（Entity）

**分析的单元是什么？**账户、用户、商机、订阅，还是别的？

这决定了你的查询从哪张表或哪个数据源开始，也决定了结果集的粒度：一行一个账户、一行一个用户，还是一行一笔交易。

2. 定义指标（Metric）

**针对每个实体，你在衡量什么？**收入、用量、转化、健康分，还是别的？

计算口径要精确。"收入"可能是签约年经常性收入（ARR）、确认收入、月经常性收入（MRR），或者历史累计付款——在大多数数仓里，它们来自不同的字段。

3. 定义时间范围（Timeframe）

**这个问题覆盖哪段时间？**本季度、滚动 90 天、客户生命周期至今，还是同比？

时间范围同时影响查询逻辑和结果解读：

滚动区间指标能平滑季节性
固定区间指标对齐业务汇报周期
生命周期指标能看全量历史，但会掩盖近期趋势

4. 定义对比基准（Comparison）

这个问题要的是一个绝对值，还是一个对比？

大多数有用的分析都是对比的：本期 vs 上期、这一群 vs 那一群、实际 vs 目标。

副总问"留存怎么样"，回答"82%"远不如回答：


"82%，比目标低 3 个点，比去年同期低 5 个点。"
”

5. 定义阈值（Threshold）

如果问题里带判断（"有风险""最好""表现不佳"），那么定义这个判断的数字阈值是多少？

这一步往往是把副总脑子里的直觉变成明文的地方。"有风险"可能是：用量环比下滑超过 30%、健康分跌破 60，或者 21 天内没登录。

在跑查询之前把阈值谈定，就能避免结果出来时那句"这看着不对啊"。


这份五要素清单，把一句模糊的业务问题变成一份精确的分析规格。走一遍只要五分钟，省下的是几个小时的返工。
”

四、让 AI 来做这次"翻译"，行不行？

上面这套清单，描述的是一个好分析师在脑子里做的事。它同时也是大模型必须做的事——而绝大多数 AI 分析在这里翻车。

你把一份表结构粘进 ChatGPT 或 Claude，问"哪些客户快要流失了"，你会得到一段看起来很靠谱的 SQL：它用的字段可能存在也可能不存在，它采用的流失定义是模型自己编的。输出很自信，而且要逐行读才能验证。

问题不在模型，在它拿到的表结构是猜的。

解决办法是给它一份不用猜的真实结构。原文作者的思路是：让工具自己扫描站点、自己配置埋点，这样 AI 看到的事件和属性就是你产品里真实的那些，名字和类型都是对的。你再用大白话提问，它会拿这份真实结构去解析问题、把指标或报表建出来、并且把用过的定义存下来。那些更难的、人类分析师要用 join 或窗口函数才能回答的问题，由系统内部自己组合查询路径。如果 AI 把某个事件名认错了，你可以在源头改，而不用去改 SQL。

AI 仍然决定不了的两件事

第一，阈值和目的。

AI 能很好地确定实体、指标、时间范围——因为这些能从表结构和你的措辞里读出来。但它定不了阈值，也不知道答案要被拿去做什么决策。

你的埋点数据里没有任何东西能告诉你，"有风险"到底是"用量跌 30%"还是"60 天没登录"。那是业务决策。你不做，模型就会替你挑一个"看起来合理"的，而且不会告诉你它替你挑了。

可行的做法是：把阈值直接写进你的提问里，剩下的交给 AI。

第二，分歧。

AI 修不了"人跟人定义不一致"的问题。如果销售和财务对"收入"的定义不同，AI 会很乐意把两个数字都算出来——**争论只是从"查询"转移到了"答案"。**下面要说的术语表工作，仍然是你的活儿。

五、把一次结论变成资产：可复用库

同一类问题会反复出现。把每一个已经定清楚的问题存下来，可以把一个几天的项目变成一次查表。

在作者描述的工作方式里，一个通过对话回答的问题会被保存成一个指标或一张报表，这样下一个人再问同样的问题时，跑的是同一套定义，而不是一个全新的解释。


习惯比存储方式更重要：定义一次，给它一个大家认得出来的名字，然后复用。
”

一个查询模板该长什么样

好的查询模板有四个组成部分：

它回答的业务问题——用大白话写清楚
每次需要填的参数——时间段、分群、阈值
查询或分析方法——参数位置标注清楚
结果解读指南——怎么看结果，有哪些注意事项

模板示例一：流失风险

业务问题："哪些账户在未来 X 天内可能流失？"
参数：风险窗口（默认 60 天）、用量下滑阈值（默认 30%）、最低合同金额（默认不限）
查询逻辑：找出"近 30 天用量相比上一个 30 天下滑超过阈值"的账户，且续约日期落在风险窗口内
输出字段：账户名、合同金额、用量下滑幅度、最后登录时间、负责的客户成功经理——按合同金额倒序排，让最值钱的流失风险账户排在前面

模板示例二：分群表现

业务问题："指标 X 在各群之间表现如何？"
参数：指标（如净收入留存率 NRR）、分群维度（如公司规模）、时间区间（如滚动 12 个月）
查询逻辑：按分群维度的每个取值算出该指标，同时给出每群的实体数量与环比变化
一个模板顶几十个变体：按公司规模看 NRR、按行业看赢单率、按来源看成交周期

怎么把模板库建起来

第一步：把你们团队上个季度收到的所有分析需求列出来。

按上面那 5 个类别归类（健康、业绩、预测、分群、归因）。每个类别里，找出最常见的那两三个具体问题，先给它们建模板。

一份精心做好的短清单，就能覆盖大部分来量——因为需求本身就是高度集中在少数几个反复出现的问题上。

第二步：把模板放在分析师和业务方都能看到的地方。

当业务方能浏览这个库，他们会开始照着已有的模板来组织自己的提问，于是大部分的澄清往返在开始之前就消失了。

再配上一套业务方能自助探索的指标，简单问题就根本不会流到分析团队了——这正是目的所在。分析师的时间应该留给那些真正需要判断的翻译工作。

数据字典怎么做？

**从你们最重要的 5 到 10 个指标开始。**每一个，记录四件事：

精确定义（什么算、什么不算）
计算公式
主要数据源
已知的注意事项或局限

放在共享、可搜索的地方：一个 wiki 页面、一个 Notion 数据库，甚至一张整理好的表格。

每季度复核一次，跟上埋点的变化。最常见的失败是——字典写完就再也没更新过。给每个指标指定一个负责人，专门负责让定义保持最新。

一个"活着的"数据字典，能终结每次跨部门会议上浪费几小时的"到底谁的数字对"之争。它同时还能让 AI 的答案可审计——你可以拿它用过的定义，去对你跟大家约定好的那一版。

核心要点

**每一个业务问题里，都藏着实体、指标、时间范围、对比基准、阈值这五重模糊。**在任何人动手写查询之前，先把这五件事敲定。
销售与收入类问题分成五类：健康与风险、业绩、预测、分群、归因。知道是哪一类，就知道哪个歧义会先咬你。
AI 能很好地处理实体、指标和时间范围，因为这些能从表结构里读出来。但它挑不了你的阈值，也不知道答案要支撑什么决策——所以这些必须写进你的提问里。
**AI 写的 SQL 好不好，取决于它看到的表结构。**一个自己采集事件的工具，能给模型一份真实的表结构，而不是粘贴进去的猜测——这才是不出现"凭空捏造字段名"的原因。
把每一个定清楚的问题存成指标或报表，让重复提问变成一次查表。维护一份共享术语表，让"流失""收入""活跃"在全公司只有一个意思，也让 AI 的答案始终可审计。