报表项目最大的返工来源不是技术，而是"这个数不对"。而不对的原因，九成出在口径没写清楚——同一句"月活用户"，两个部门能给出三种算法。
一、口径：先定义，再开发
每个指标都应该有一张口径卡，写清楚四件事。缺一项，后期就会有人来问"这个数怎么算的"。
- 计算公式：分子分母分别是什么，去重规则如何
- 统计范围：包含哪些组织、哪些渠道、是否含测试数据
- 时间归属：按下单时间、支付时间还是完成时间
- 精度与单位：保留几位、金额单位、百分比基数
口径表要签字
口径确认后请业务方签字或线上确认留痕，它是后续所有争议的裁判依据。省这一步，后期就要用会议来裁决，成本高得多。
二、维度与粒度
维度组合不是越多越好。每增加一个维度，数据量按维度基数成倍增长，查询性能也随之下滑。建议按"先定必选、再定可选"的顺序推进。
- 必选维度：日常决策离不开的，通常三到四个
- 可选维度：按需要组合查询，用参数控制而非预生成全部组合
- 粒度要统一：日粒度与明细粒度不要混在同一张表里
三、数据来源与刷新频率
| 时效类型 | 典型场景 | 建议频率 |
|---|---|---|
| 实时 | 监控看趋势、看异常 | 分钟级 |
| 准实时 | 日常经营看板 | 小时级 |
| 离线 | 分析、考核、结算 | 天级 |
把频率定下来的最大好处是：可以明确告诉业务"这个数什么时候更新"，而不是每次都被追问"怎么还是昨天的"。
四、性能预算
性能必须在开发前谈，而不是上线后救。三个问题问清楚，方案自然收敛：多少人看？什么时候一起看？能接受几秒出结果？
- 并发峰值常见于早会与月末，别按平均用户数设计
- 首屏控制在 3 秒内，明细导出允许更长但要排队
- 重度查询加缓存或预计算，不要指望数据库硬扛
五、五类常见返工原因
- 口径未确认，上线后重新对数
- 维度漏项，业务临时要"按渠道看"
- 数据源未清洗，含测试与重复数据
- 权限未设计，业务看到不该看的明细
- 性能未评估，上线即超时
这五条都能在需求阶段避免，方法也很简单：把口径卡、维度清单、数据源确认单做成模板，每个报表项目都跑一遍。花在前期的一天，能省后期的一周。
#报表开发#指标口径#需求分析#性能预算
