2、需求调研：如何与业务方沟通，明确指标定义、口径、维度与粒度

很多做实时指标的人，一上来就撸代码。选 Flink、搭 Kafka、写 SQL，忙得不亦乐乎。结果呢？上线第一天业务方就炸了：「这个数不对啊！」「口径跟我们理解的不一样！」「为什么昨天和今天的数据对不上？」

嗯，我踩过这个坑，而且不止一次。后来我总结了一句话：实时指标的成败，在需求调研阶段就已经决定了。代码写得再漂亮，需求没对齐，全是白费。

2.1 需求调研的四要素：定义、口径、维度、粒度

我跟业务方沟通时，脑子里始终绷着四根弦。少了任何一个，后面都会出问题。

要素	业务方常说的	我们需要明确的
定义	「我要看用户活跃数」	什么叫「活跃」？打开APP算？登录算？还是有点击行为才算？
口径	「跟昨天对比一下」	是日环比？周同比？还是累计值？去不去重？
维度	「按地区看看」	省份？城市？还是更细的区县？用户注册地还是IP归属地？
粒度	「我要实时数据」	秒级？分钟级？还是小时级？延迟容忍度是多少？

你看，业务方一句话，背后藏着这么多细节。我个人的习惯是，每次沟通都拿这张表去对，逐条确认，不留模糊地带。

2.2 定义：把「感觉」变成「公式」

业务方说「我要看订单转化率」。听起来很明确对吧？但一深挖就发现，每个人理解的「转化」都不一样。

• 是「下单」算转化，还是「支付成功」才算？
• 退款订单算不算？
• 刷单的要不要剔除？
• 同一个用户下了多单，算一次转化还是多次？

我曾经在一个电商项目中，跟运营团队开了三次会才把「转化率」的定义敲定。最后写成了这样：

指标名称：支付转化率
定义：当日支付成功订单数 / 当日下单订单数
排除条件：
  - 剔除测试账号（user_id 以 'test_' 开头）
  - 剔除金额为 0 的订单
  - 剔除支付后 30 分钟内全额退款的订单
计算周期：自然日（00:00:00 - 23:59:59）
更新频率：每 5 分钟刷新一次

你看，写清楚之后，开发、测试、业务三方都没有歧义。这就是「定义」的力量。

2.3 口径：统一「怎么算」

口径问题，说白了就是「算法」问题。同一个指标，口径不同，结果天差地别。

举个最常见的例子——去重。

业务方说「我要看今天的独立访客数」。你按 user_id 去重了，结果发现很多用户没登录，user_id 是 null。那这些算不算？

我遇到过的情况是：运营团队用设备 ID 去重，产品团队用 user_id 去重，两个数字差了 30%。两边都觉得自己是对的，最后拉我过去仲裁。

所以，口径必须明确到字段级别：

口径项	说明	示例
计算字段	用哪个字段做聚合	user_id、device_id、order_id
去重规则	是否去重，按什么去重	按 user_id 去重，null 值单独统计
时间窗口	滚动窗口还是滑动窗口	滚动 1 小时、滑动 5 分钟
数据源	从哪个表/流取数	订单流、埋点日志、业务库

2.4 维度：决定「怎么看」

维度是业务方分析数据的「切面」。维度选得好，分析效率翻倍；维度选得乱，报表变成天书。

我一般会问业务方三个问题：

1. 你平时最常用的筛选条件是什么？（比如：时间、地区、渠道）
2. 你希望看到哪些对比？（比如：今天 vs 昨天、A渠道 vs B渠道）
3. 有没有需要下钻的场景？（比如：从省份下钻到城市，再到区县）

然后我会把这些维度整理成一张「维度表」：

维度名称：地区
层级结构：国家 -> 省份 -> 城市 -> 区县
数据来源：用户注册信息表
更新频率：每日同步
空值处理：标记为「未知地区」

维度名称：渠道
枚举值：自然搜索、付费广告、社交媒体、直接访问、其他
数据来源：埋点参数 utm_source
更新频率：静态枚举，季度评审

这里有个坑——维度值的变化。比如渠道名称改了，或者地区划分调整了。如果不处理好，历史数据和新数据就对不上了。我建议在维度表里加一个「生效时间」字段，支持缓慢变化维度（SCD）的处理。

2.5 粒度：决定「多快」和「多细」

粒度是实时指标最敏感的话题。业务方总说要「实时」，但你真的能做到秒级吗？成本扛得住吗？

我一般会跟业务方算一笔账：

粒度	数据量（日均）	存储成本	计算延迟	适用场景
秒级	~1亿条	高	< 5秒	风控、实时大屏
分钟级	~2000万条	中	< 1分钟	运营监控、报警
小时级	~300万条	低	< 10分钟	日报、趋势分析

你看，秒级和小时级的成本差了不止一个数量级。业务方如果只是看个趋势，完全没必要上秒级。我通常会建议：核心指标用秒级，辅助指标用分钟级，分析类指标用小时级。这样既满足了实时性，又控制了成本。

2.6 需求调研的完整流程

说了这么多，到底怎么落地？我总结了一个五步法：

1. 预沟通：拿到业务方的初步需求，自己先过一遍，标记出模糊点。
2. 正式会议：拉着业务、产品、开发三方一起，逐条确认定义、口径、维度、粒度。
3. 输出文档：把确认结果写成《指标定义说明书》，发给所有人确认。
4. 原型验证：用少量数据快速跑一个 Demo，让业务方看到实际效果。
5. 签字确认：业务方在文档上签字，作为后续开发的基线。

这一步走扎实了，后面开发、测试、上线都会顺畅很多。我见过太多项目，需求调研只花了半天，后面返工花了两周。你说哪个划算？

2.7 需求调研的核心逻辑图

下面这张图，是我每次做需求调研时都会参考的框架。它把整个流程串起来了：

你看，整个流程是环环相扣的。从业务方的原始需求出发，拆解成四要素，然后输出文档，最后验证确认。每一步都走扎实了，后面才不会翻车。

2.8 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路：

• 不要相信「跟之前一样」——每次都要重新确认，因为业务逻辑可能已经变了。
• 不要忽略异常值——null、0、负数、重复数据，都要明确处理方式。
• 不要假设业务方懂技术——用业务语言沟通，用例子说明，而不是甩一堆技术术语。
• 不要一次性确认太多指标——一次聚焦 3-5 个核心指标，确认透彻了再继续。

我曾经在一个项目中，业务方说「跟上次一样就行」。结果上线后发现，上次的指标口径已经改了三次了，业务方自己都忘了。从那以后，我每次都会把历史文档翻出来，逐条对一遍。麻烦是麻烦了点，但总比返工强。

需求调研这件事，说白了就是「把丑话说在前面」。前期多花点时间，后期就能少加很多班。嗯，这个道理，我是在加了很多次班之后才真正明白的。