有些数据需求，刚接到时像一句人话。
比如：“帮我看下复购。”
六个字，听起来很清楚。做数据分析的同学打开表，找用户、找订单、写 SQL、算复购率。半小时后给出一个数。
业务看了一眼，说：“我说的不是这个复购。”
于是改第一次。
从“所有下单用户”改成“新客首购用户”。又跑一版，业务又说：“我们这次活动只看支付成功，不看退款后的订单。”
于是改第二次。
第三次，是老板在会上问：“这个复购，包含老客被重新拉回来的吗？”
群里安静了。
运营同学开始解释活动规则，增长同学补了一句渠道归因，财务同学问退款订单算不算。数据同学看着自己刚跑出来的 SQL，突然觉得它像一张写得很工整、但题目看错了的试卷。
这时候你才发现，问题可能不在 SQL。
问题在于，大家一开始就没有在问同一个问题。
“帮我看下复购”，其实不是一个需求
很多模糊需求都有一个共同特点：它们听起来像任务，其实只是一个话头。
“看下复购。”
“拉一下转化。”
“分析一下留存。”
“看这个活动效果怎么样。”
这些话都很像需求，但还不能直接开发，也不能直接分析。它们缺少几个关键东西：看谁、看什么时间、和谁比、用来决定什么。
如果这些东西没问清楚，数据同学就会自动脑补。
问题是，脑补通常很危险。
你以为复购是“买过一次后再次购买”。业务以为复购是“活动新客在 7 天内再次支付”。老板关心的可能是“这个渠道带来的客户，30 天内有没有自然回来”。
同一个词，三套问题。
这不是业务不专业，也不是数据同学不认真。很多业务词本来就是压缩包。你不能拿一个压缩包直接运行 SQL，得先解压。
更麻烦的是，模糊需求通常不会以“我很模糊”的样子出现。
它们往往很自然，很像日常沟通。业务同学站在你工位旁边，说“很快的，就拉一下”。群里有人补一句“老板下午要”。你也知道这事急，于是先跑起来。
可是一旦你把第一版数据发出去，这个数就开始有了生命。它会被截图、转发、贴进 PPT。后面每改一次口径，都会让人多问一句：“那刚才那个数还能不能用？”
所以需求澄清不是为了显得严谨。
它是为了让第一个发出去的数，不要太早变成错误共识。
第一次返工：对象没说清
复购的第一个坑，是对象。
到底是谁复购？
是所有用户，还是新用户？是首购用户，还是活动触达用户？是支付成功用户，还是下单用户？是自然访问用户，还是被优惠券召回的用户？
这些对象一变，结果就会变。
更麻烦的是，业务很多时候不是故意不说。他脑子里默认有一个场景，但没有把这个默认场景讲出来。
比如他说“这个活动的复购”，他可能默认只看活动拉来的新客。你如果按全量用户算，数当然也没错，但对他没用。
所以接到这类需求时，第一句话不要急着问“口径是什么”。这个问题对很多业务来说太抽象。
可以换成：
“你这次想看的是哪一批人？活动新客、所有下单用户，还是被触达过的人？”
这句话更像人在说话，也更容易把对象问出来。
第二次返工：动作没说清
复购的第二个坑，是动作。
什么叫“购”？
下单算不算？支付算不算？退款后算不算？取消订单算不算？只买试用装算不算？同一天买两次算不算？
这些听起来像细节，但在数据里不是细节。
它们会直接改结果。
尤其是电商、会员、课程、工具订阅这类业务，订单状态非常复杂。很多人习惯把“买了”当成一个简单动作，但系统里可能有创建订单、支付成功、发货、确认收货、退款、部分退款、换货、取消等一串状态。
数据分析师如果不问清楚，就很容易算出一个“逻辑上合理、业务上不被接受”的数。
这类问题可以这样问：
“这次复购只看支付成功，还是要扣掉退款？同一天重复购买要不要算第二次？”
你会发现，一旦问到这里，业务自己也会停一下。
这个停顿很有价值。
它说明需求正在从一句话，变成一个可以被验收的定义。
第三次返工：用途没说清
最容易被忽略的，是用途。
业务为什么要看复购？
如果是判断活动质量，他关心的是活动带来的用户有没有后续价值。如果是判断商品问题，他关心的是买过某类商品的人会不会回来。如果是判断渠道投放，他关心的是不同渠道的用户生命周期差异。
用途不同，指标拆法就不同。
同样是复购：
- 活动复盘要按活动批次看。
- 渠道评估要按渠道来源看。
- 商品分析要按首购品类看。
- 用户运营要按触达策略看。
如果你不知道用途，就只能给一个平均数。
平均数最适合写在日报里，最不适合拿来做判断。
所以第三个问题应该是：
“这个数最后要帮你做什么决定？继续投、调预算、改商品，还是评估用户质量？”
这句话能把分析从“查一个数”，推进到“支持一个动作”。
很多数据工作真正的分水岭，就在这里。
你是把 SQL 写出来，还是把判断路径问出来。
一个模糊需求，先问 4 个问题
下次再听到“帮我看下复购”“拉一下转化”“分析一下留存”，可以先别急着写 SQL。
先问 4 个问题。
第一，看哪一批对象？
用户、订单、商品、门店、渠道、活动批次，都要先定住。对象不清，后面都不稳。
第二，看哪个动作？
下单、支付、激活、访问、点击、退款、再次购买，这些动作要对应到系统里的状态。
第三，看什么时间窗口？
7 天、14 天、30 天，首购后还是活动后，自然日还是业务周期。时间窗口一变，趋势会完全不同。
第四，用来做什么决定？
如果没有决策用途，很多分析会变成“看了也知道，知道也不动”。
这 4 个问题不复杂，但能挡住大部分返工。
不是因为它们多聪明，而是因为它们把业务语言翻译成了数据任务。
实际工作里，不需要把这 4 个问题摆成审问。
更好的方式是把它们嵌进正常对话里。比如业务说“看下复购”，你可以接一句：“这次是想看活动新客 7 天内有没有再次支付，对吗？结果是用来决定下周还投不投这个渠道？”
一句话里，对象、动作、时间、用途都出来了。
如果对方说“对”，你就可以继续做。如果他说“不对，我想看的是老客召回”，那你避免了一次返工。
这就是澄清的价值。它不是多问几个问题，而是把错误方向尽早挡在 SQL 之前。
不要把需求澄清当成多嘴
有些做数据开发的朋友不愿意多问。
一方面怕显得自己不懂业务；另一方面也怕业务嫌麻烦。于是干脆先做，做完再说。
这是一种很常见的善意。
但它经常把自己带进坑里。
需求越模糊，越不应该靠勤快解决。你越快开始写 SQL，越快把一个没说清的问题固定成一个看起来很确定的答案。
等答案进了 PPT、进了会议、进了老板嘴里，再想改就很难看了。
需求澄清不是拖慢进度。
它是在保护进度。
还有一种情况也很常见：数据同学问了问题，但问得太像审表。
“分母是什么？分子是什么？时间窗口是什么？过滤条件是什么？”
这些问题对我们来说很清楚，对业务来说可能像突然被拉进了技术评审。对方本来只是想确认活动效果，结果被一串口径词问住，最后干脆说：“你按常规算吧。”
所以澄清不是把专业词倒给对方。
更好的做法，是把问题翻译回业务语境。不要问“分母是什么”，可以问“这次你想评估的是活动带来的新客，还是所有买过的人”。不要问“时间窗口是什么”，可以问“你是想看活动结束后一周，还是整个自然月”。
同样是澄清，后者更容易得到真实答案。
我把这类动作整理进了 ss-data-skills 里的“数据需求澄清”和“指标口径审查”两个技能。它们不是教你怎么写漂亮提示词，而是把日常数据工作里这些容易漏掉的问题拆成清单：https://github.com/shisuidata/ss-data-skills
你不一定要照着模板逐字问，但可以在接需求前扫一眼。特别是遇到“看一下”“分析一下”“拉一下”这种词，先停 3 分钟，比后面返工 3 次便宜得多。
说到底，业务要的不是 SQL。
业务要的是一个能站得住的判断。
SQL 只是你把这个判断算出来的方式。
我叫石头，在数据行业里摸爬滚打了十几年，也吃过不少“先拉一下”的亏。这里写的，就是这些教训——我觉得值得说出来的那部分。
