2 篇博文 含有标签「数据分析」

TL;DR​

同一份投放账单，两个「获客成本」：线索成本 ¥8，询盘成本 ¥41——差 5 倍。一间店铺的关键词周账实测：线索 4,111 对询盘 824。线索是宽口径（收藏、加购、领券、点击联系全算，还按次数累加），询盘只有旺旺询单一种。看人气用线索，做预算只用询盘——拿 ¥8 的口径去配预算，缺口从一开始就是 5 倍。

处境：¥8 的获客成本，提气得让人想加预算​

月报里「线索成本」那条线漂亮极了：¥8 拉一个意向客户。按这个数配下一季度的获客预算，逻辑闭环。

直到把「询盘成本」摆在旁边：¥41。同一个账户、同一份消耗、同一个月，两个数字差 5 倍。本次对账来自开发 AI 运营 过程中的指标口径核查。

数据：5 倍的差距，和一个单向包含​

最后两行是关键：有询盘必 有线索，反之大不然。这说明线索是询盘的超集——（专业注：线索口径把收藏、加购、领券、点击联系等互动全部计入，且按次数累加；同一买家点三次「联系」，就是三条线索。询盘只有一种：买家主动发来的旺旺询单。两者不是「两个指标」，是「全部互动」和「其中最值钱的那种」。）

那 269 条「有线索、零询盘」的记录，就是热闹与生意的距离：互动发生了，询单没发生。

值多少：5 倍的预算缺口​

拿线索成本 ¥8 做预算底仓，市场费用会按「¥8 拉一个客户」配置；真实口径 ¥41，缺口从第一天起就是 5 倍。这不是乐观，是系统性错配——所有下游决策（报价、毛利、放量节奏）全部建在一个虚的分母上。线索口径可以用，只允许用在一件事上：看素材和活动有没有把人气做起来。

给运营者的纪律​

1. 两个口径分开记账，名字里带上口径：「线索成本 ¥8」「询盘成本 ¥41」——混着叫「获客成本」的报表，迟早出事。
2. 预算、调价、商品盈亏，只用询盘口径：询单不可灌水、紧跟成交，是唯一算数的分母。
3. 线索当人气温度计：线索突涨去看素材和活动；它上个月是你的人气参考，永远不是你的成绩单。
4. 人群调价同理：考核人群看询盘成本，完整逻辑见 询盘成本只差 10%，ROI 差 4 倍：人群报表要用两把尺子。

常见问题​

1688 的线索数和询盘数差在哪？​

询盘是旺旺询单，一个算一个；线索把收藏、加购、领券、点击联系按次数累加。实测同一账户：线索 4,111 对询盘 824，差 5 倍。

汇报该用线索成本还是询盘成本？​

对外报喜可以用线索口径，预算决策只能用询盘成本——实测两者 ¥8 对 ¥41，拿 ¥8 报预算就是给自己挖坑。

有线索没询盘说明什么？​

实测 269 个关键词·周有线索、零询盘——互动没走到询单那一步。看素材人气可以，别当获客成绩。

这套「指标口径分账」的做法，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。两个口径差 5 倍的指标，不该共用一个名字。

排查一个数据看板线索：某广告 offer 在「诊断明细」里被判疑似停投、并附了再投资建议，点进「建议投放」清单却查无此 offer——明细页指着一张清单，清单里没有这行。

在开发 AI运营 时遇到此问题——基于大语言模型的智能分析平台，自动洞察市场趋势、用户行为与销售数据；诊断明细与建议清单分别来自管道里两个相邻查询的产出。

TL;DR​

两个查询对同一个业务谓词（「疑似停投」）用了不同的聚合粒度：明细查询按 计划×offer 粒度判定——任一计划末周无消耗即判疑似；候选清单按 offer 整体粒度判定——挂着的全部计划末周均无消耗才入选。某 offer 在其中一个计划末周仍有消耗，于是「明细判疑似、汇总不入选」，呈现层指向的明细悬空。修法三件套：口径统一收紧到整体粒度、两侧判定 CTE 逐字同源、引用对方行集前校验包含关系。

问题现象​

两个查询各自定义「疑似停投」：

-- 查询④ 诊断明细：pair 粒度（计划 × offer）
WITH consumption_paused_q4 AS (
  SELECT offer_id, campaign_id
  FROM spend_weekly
  GROUP BY offer_id, campaign_id        -- 每个计划单独看
  HAVING SUM(spend) FILTER (WHERE is_last_week) = 0
)

-- 查询⑤ 建议投放候选：offer 粒度（跨全部计划汇总）
WITH suspected_paused_q5 AS (
  SELECT offer_id
  FROM spend_weekly
  GROUP BY offer_id                     -- 整个 offer 一起看
  HAVING SUM(spend) FILTER (WHERE is_last_week) = 0
)

出问题的 offer 挂在多个计划下，其中一个计划末周仍有消耗（3.09）：

查询④（pair 粒度）：  计划A 末周消耗 0     → 判疑似 ✓，并给出建议
查询⑤（offer 粒度）： 跨计划汇总末周消耗 3.09 → 不入选 ✗
呈现层：明细页说「见建议投放表」，建议投放表里没有它

任务不报错、行数对得上大数，悬空只有顺着某条明细点过去才会撞见。

根因​

「同源」契约有覆盖盲区。管道规范要求相邻查询的特征列 CTE 逐字同源——这条契约被严格遵守了；但它只约束特征列，判定集（WHERE 之前的那个业务谓词）不在契约范围内。「疑似停投」在两个查询里被独立实现了两次，粒度不同：pair 级判定对「单个计划内无消耗」敏感，offer 级判定对「所有计划都无消耗」敏感。同一个 offer 两种结论，数学上必然存在交叉带。

跨查询引用把分叉放大成了悬空：呈现层拿查询④的行当明细、查询⑤的表做入口，却没人校验过「④的行集 ⊆ ⑤的行集」。聚合口径不一致是数据仓库最经典的一致性陷阱之一——此前写过的 SUM 比率列导致聚合后指标暴涨是它的另一种形态：聚合发生在了错误的层级上。

解决方案​

步骤 1：先定口径，再写 SQL​

业务问题只有一个答案：「这个 offer 还投不投」是 offer 级决策，判定就该收紧到整体粒度——挂着的全部计划末周均无消耗、且无任何运营标注行，才判疑似。口径变更升 rule_version，可追溯。

步骤 2：判定集 CTE 逐字同源​

把判定 CTE 抽成同一段文本，两个查询直接引用；契约同步升级：逐字同源覆盖判定集（含粒度），不止特征列。从此同一谓词只有一处定义，改口径只改一处。

步骤 3：跨查询引用前，校验行集包含关系​

把「标记集 ⊆ 对方行集」做成固定校验（可入库为测试）：

-- 悬空检测：④ 判了疑似、⑤ 却查无此行
SELECT q4.offer_id
FROM consumption_paused_q4 q4
LEFT JOIN suspected_paused_q5 q5 USING (offer_id)
WHERE q5.offer_id IS NULL;

这条查询返回 0 行，呈现层才有资格把两个产出拼在同一张页面上。

步骤 4：重放验证后上线​

新口径对历史快照重放：逐行核对翻转方向（疑似↔正常）全部正确、零误伤、零悬空，再重跑生产验证通过，才完成收口。

常见问题​

为什么两条 SQL 对同一份数据给出不同结果？​

常见三个差异：聚合粒度（GROUP BY 维度不同——本例的计划×offer 与 offer 整体）、过滤口径（WHERE/HAVING 条件不同）、取数时点（查询时间不同）。粒度分叉最隐蔽：两条 SQL 各自都对，结论却可以相反。

SQL 的 HAVING 和 WHERE 在聚合判定里怎么选？​

WHERE 在分组前过滤行，HAVING 在分组后过滤组。但选对关键字之前先选对粒度——「以什么为一组」决定了判定的灵敏度：粒度越细越容易命中（单组满足即判），越粗越保守（全部满足才判）。两条 SQL 粒度不同，判定结论就可能相反。

如何避免报表之间的数据口径不一致？​

同一业务谓词只在一处定义，判定 CTE 多查询逐字同源；跨查询引用对方行集前跑包含关系校验（A ⊆ B）；口径变更升版本号并对历史数据重放验证。一致性不靠约定俗成，靠契约加校验。