P7-1.2 基线与首次比较¶

Section ID: P7-1.2 Version: v2026.08.01

首次比较要先固定基线、候选规则、比较单位和指标，然后把结果分成事实、解释与下一问题。这样基线不只是一个数字，而是下一次调查的共同参照。

把数值放在基线上阅读¶

仅写“平均访问量为 150.7”或“某日最好”不能说明当前结果是否偏离平常范围。项目记录应说明：使用了什么基线、当前值是什么、差异是什么，以及哪一项值得先检查。

基线先于结论出现。没有基线，“高”或“低”只是形容词；有了基线，才能说某个渠道相对自身近期记录发生了多大变化。

不要把事实、解释和行动混在一句话里¶

“错误导致注册下降”是因果结论，而当前日志只显示错误率上升与转化率下降同时出现。更安全的写法是：“两项变化同时出现，因此需要进一步检查它们是否有关。”

flowchart TD
  A["最近渠道-日期记录"]
  B["与同渠道基线比较\n转化率和错误率"]
  C["转化率优先规则\n筛选候选"]
  D["错误率优先规则\n筛选候选"]
  E["两个规则的共同候选"]
  F["分开记录\n事实、解释、下一问题"]
  A --> B
  B --> C --> E
  B --> D --> E --> F

两种候选规则¶

本节继续使用 p7-1-traffic-log.zh.csv。比较单位是最近区间中的一个渠道-日期行；每行与同渠道的基线汇总比例比较。

百分点不是百分比增长率。-0.035 表示转化率比基线低 3.5 个百分点；0.009 表示错误率高 0.9 个百分点。这些阈值是安排审查顺序的规则，不证明原因或统计显著性。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

import csv
from collections import defaultdict
from datetime import datetime
from pathlib import Path

rules = [
    {"name": "转化率优先", "conversion_drop_max": -0.035, "error_rise_min": 0.009},
    {"name": "错误率优先", "conversion_drop_max": -0.025, "error_rise_min": 0.012},
]
rows = list(csv.DictReader(Path("docs/assets/part-07/chapter-01/p7-1-traffic-log.zh.csv").open(encoding="utf-8")))
for row in rows:
    row["date"] = datetime.strptime(row["date"], "%Y-%m-%d").date()
    row["visitors"] = int(row["visitors"])
    row["signups"] = int(row["signups"])
    row["errors"] = int(row["errors"])

cutoff = datetime.strptime("2026-06-08", "%Y-%m-%d").date()
baseline_rows = [row for row in rows if row["date"] < cutoff]
recent_rows = [row for row in rows if row["date"] >= cutoff]
totals = defaultdict(lambda: {"visitors": 0, "signups": 0, "errors": 0})
for row in baseline_rows:
    for field in ("visitors", "signups", "errors"):
        totals[row["channel"]][field] += row[field]
for total in totals.values():
    total["conversion"] = total["signups"] / total["visitors"]
    total["error"] = total["errors"] / total["visitors"]

candidates = {rule["name"]: [] for rule in rules}
for row in recent_rows:
    base = totals[row["channel"]]
    conversion_delta = row["signups"] / row["visitors"] - base["conversion"]
    error_delta = row["errors"] / row["visitors"] - base["error"]
    for rule in rules:
        if conversion_delta <= rule["conversion_drop_max"] and error_delta >= rule["error_rise_min"]:
            candidates[rule["name"]].append((row["date"].isoformat(), row["channel"], round(conversion_delta, 4), round(error_delta, 4)))
print(candidates)
print("common candidates =", sorted(set(candidates[rules[0]["name"]]) & set(candidates[rules[1]["name"]])))

代码先按渠道汇总基线，再逐行比较最近记录。它保留每个候选的日期、渠道、转化率差异和错误率差异，以便审查者回到原始日志，而不是只看候选数量。

共同候选为什么优先¶

两个规则不是同一个条件的宽松和严格版本。一个更重视转化率下降，另一个更重视错误率上升。因而同时通过两个规则的行，表示两个指标在各自阈值下都值得查看。

共同候选是审查优先级，不是根因结论。仍应检查访问量、注册数、错误类型、浏览器、部署记录和活动上下文。

改变规则时应记录什么¶

团队可能改变阈值、切分日期或假设的渠道情景。每次改变都必须保留原规则和新规则，以免把规则变化误读成数据变化。

一次只改变一个设定，才能解释候选为何进入或离开列表。

将候选写成下一问题¶

1
2
3
4
5

基线：广告渠道在切分日期之前的汇总转化率和错误率。
当前值：某个最近广告渠道-日期行。
事实：该行满足转化率和错误率的共同候选规则。
解释：广告渠道的变化可能与运营异常或投放变化有关。
下一问题：先检查该日期的错误类型、活动设置和追踪记录。

这个格式避免把“满足规则”写成“已经知道原因”。它也让后来的人知道下一次检查从哪里开始。

学习检查¶

1. 能否说明为什么基线必须先于解释出现？
2. 能否把一个句子拆成事实、解释和下一问题？
3. 能否解释两个规则的共同候选为何比单规则候选优先？
4. 能否把 -0.035 和 0.009 读成百分点差异？
5. 能否说明阈值规则不能证明什么？

读取本次运行的候选列表¶

在默认切分日期下，转化率优先规则选出 5 个广告渠道-日期候选；错误率优先规则选出 3 个。共同候选是 06-11、06-12、06-14 的广告记录。这个结果首先说明候选规则确实改变了优先级，而不是所有低转化率行都自动进入同一列表。

共同列表不意味着三天是同一个事件。它只说明在当前指标、阈值和切分日期下，这三行都值得优先回查。应分别检查每一天的错误类型、流量来源和部署记录。

将百分点差异变成可读记录¶

不要将 -0.0388 写成“下降 3.88%”而不说明是百分点。百分点比较的是两个比例之间的直接差；百分比增长还需要指定分母，容易把解释带到另一个问题。

为每个候选写五栏记录¶

这五栏能防止项目记录从一行数值跳到一个根因。基线和当前值告诉读者比较的输入；事实描述规则结果；解释保持条件性；下一问题把调查变成可执行动作。

解释句的边界¶

条件性表达不是削弱结论，而是让后续实验可以推翻或支持它。项目文档应让读者清楚知道哪些部分已经由代码确认，哪些仍需外部证据。

当规则或情景改变时重新比较¶

原始 CSV 不应为了试验而被覆盖。若想模拟广告渠道注册数减少或错误数增加，应在内存中记录一个明确的调整，并与默认情景分开输出。

1
2
3
4
5

默认情景：不调整最近行。
情景变量：目标渠道、注册数调整、错误数调整。
比较单位：仍为最近的渠道-日期行。
保持不变：数据文件、切分日期、两个规则和基线计算方式。
记录结果：每个规则的候选、共同候选、进入和离开列表的行。

情景实验的目的不是制造最醒目的图表，而是理解判断规则对哪些输入敏感。把情景变量与实际观测数据分开，能避免读者误把模拟结果当成日志事实。

共同候选之后的调查顺序¶

1. 回到候选日期的原始访问量、注册数和错误数。
2. 按错误类型、浏览器、页面或地区拆分，确认增长是否集中。
3. 对照当天的活动、落地页、追踪脚本和部署记录。
4. 与未进入共同列表的广告日期比较，寻找差异而不是只收集支持证据。
5. 写出一个最小验证动作，例如检查某次部署后错误类别是否增加。
6. 只有在证据支持时，才扩大到数据收集、修复或后续模型实验。

这个顺序从最接近记录的证据开始。它避免把一个候选直接升级为大范围项目改动。

反例也要保留¶

没有进入共同候选的行不是无用数据。它们可以帮助检查规则是否过于宽松、某种变化是否只发生在广告渠道，或一个拟议解释是否也应预测其他日期的相同行为。

良好的审查记录既保留问题行，也保留比较行。否则“解释”只能看到被规则选中的证据。

项目回顾示例¶

在当前切分日期和规则下，广告渠道的 06-11、06-12、06-14 同时满足转化率下降和错误率上升的审查条件。该事实把这些行列为优先候选，但不证明广告活动、页面或错误本身导致了注册变化。下一步将保留相同基线，检查每个日期的错误类别、访问量构成和部署记录，并与未进入共同候选的日期比较。

这段回顾包含比较条件、观察事实、解释限制和下一行动。若其中任一项改变，应写成新的运行记录而不是修改旧结论。

常见问题¶

提交前检查¶

如果这些项都能回答，首次比较就不仅是一张候选表，而是一份可复查的下一步调查计划。

为什么这种比较方式在实际工作中重要¶

运营团队通常同时看到大量指标、告警和报表。若没有统一的基线和候选规则，讨论很容易变成“我觉得这个数字很奇怪”。把比较写成同一格式后，不同角色可以围绕同一证据协作。

同一模板并不要求所有人有同一种解释。它要求解释先连接到可回查的行、规则和比较窗口。

从候选表到任务列表¶

任务不是“修复广告”。任务应该描述要增加哪一份证据，以及该证据会如何改变下一判断。

用两个规则做小型敏感性检查¶

两个规则让学习者看到结论如何依赖判断设定。可以在不改变 CSV 的情况下分别改变一个门槛，比较候选集合。

1
2
3
4
5

运行 A：转化率优先规则与默认切分日期。
运行 B：错误率优先规则与默认切分日期。
比较：共同候选、仅 A 候选、仅 B 候选。
保持固定：数据文件、渠道定义、基线计算和最近区间。
记录：每一行的百分点差异，不只记录候选数量。

敏感性检查让规则本身成为项目记录的一部分。这样阈值变动不会在以后看起来像数据突然改变。

进一步的练习¶

1. 将转化率优先规则的下降门槛改为 -0.025，比较新增的候选行。
2. 将错误率优先规则的上升门槛改为 0.009，说明它与第一条规则有什么不同。
3. 将切分日期推迟一天，写出哪些基线行和最近行发生移动。
4. 只为广告渠道设置一个模拟的错误数调整，并记录这是情景而非观测。
5. 选择一个只在单规则中出现的行，为它写五栏记录。
6. 为一个未被选中的广告日期写反例说明：它缺少哪一个信号？
7. 将共同候选和单规则候选分别交给“工程检查”和“运营检查”，说明所需证据为何不同。

每个练习都应保留原始运行输出。不要只留下修改后的最有趣结果，否则比较失去基线。

将结果转成下一次实验问题¶

候选表的最后一列不应是“结论”。它应该是能在下一轮得到新证据的问题。

问题需要能被证据回答。比如“为什么广告不好”太宽；“06-11 广告错误是否集中在某个部署后的页面路径”则可以由日志查询回答。

模板：事实、解释、下一问题¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

比较范围：
基线定义：
当前渠道-日期：
转化率差异（百分点）：
错误率差异（百分点）：
规则结果：
事实：
可能解释：
未验证的替代解释：
下一问题：
最小检查：
保留的反例：

模板中的“未验证的替代解释”很重要。它提醒作者不要只寻找支持第一种想法的证据。例如，广告错误率上升可能与页面有关，也可能与监控规则或流量构成变化有关。

完成标准¶

首次比较完成时，读者应能让另一人重建：使用了哪份数据、何时切分、每个规则如何筛选、哪些行共同出现，以及下一步要检查什么。若只能重建最后一句解释，项目记录还不够。

这套结构会在后续 Section 中反复使用：先建立可比较的基线，再保留错误或候选的证据，最后设计一个有限的下一步。

最后自查¶

在发布比较前，重新运行代码而不是手工编辑候选列表。 确认日期和渠道名称仍能在 CSV 中找到。 确认所有百分点差异都有相同的基线定义。 确认情景调整没有写回原始数据文件。 确认共同候选被称为审查优先级，而不是根因。 确认每个解释后面都有可执行的下一问题。 确认一个反例或稳定行仍在记录中。 确认读者可以区分默认运行和模拟运行。 确认阈值的来源和用途被写明。 确认没有把规则结果写成统计检验结果。 确认输出中的计数和比例能够回到同一输入行。 确认下一 Section 能使用这份记录继续分析。

规则的使用边界¶

候选规则用于安排有限的审查时间。 它们不替代异常检测模型、统计检验或因果分析。 规则改变时，应将旧候选列表保留在运行记录中。 若数据单位或时间范围改变，先重新定义基线再比较。 每个候选都需要原始计数和上下文作为后续证据。 不要只因某行进入列表就开始广泛修改系统。 先用下一问题收集能区分解释的最小证据。 让复查结果决定是否扩大调查范围。

来源与参考¶

本节的数据和示例为本书创建的练习材料。