ad-account-diagnostic

账户诊断

在任何人动手之前，找出广告账户表现不佳的根本原因。这项工作完全在于拒绝凭直觉修复：一个「不再奏效」的账户至少有七个可能的故障层，而最常见的应对方式——提高预算、替换创意、怪罪算法——都把一个未经证实的假设当作定论。这项技能按固定顺序逐层排查，首先检查测量，因为所有后续数据都取决于转化信号：正如 Adspirer 所说，检查清单「按照经验丰富的 PPC 经理实际处理问题的顺序排列：先检查测量（因为如果追踪出了问题，其他所有数据都是错的）」。

它会拆解指标链，在判断原因之前定位出问题的环节；将账户与自身历史数据比较，而不是行业基准；绝不作出数据无法支持的判断。输出内容是附带置信度、证据和优先级交接计划的诊断，而不是已执行的变更。

这项技能止于账户边界；点击之后的一切都交由其他技能处理，而且它绝不会变成预算技能——它存在的意义，恰恰是因为「提高预算」不该是默认做法。

• 点击之后（消息匹配、页面阻力、页面修复清单）：mbfinotti/advertising-skills@paid-landing-page-audit。这项技能只会指出「证据表明问题出在点击之后」，并进行交接。
• 碎片化判断（合并计划）：mbfinotti/advertising-skills@ad-campaign-consolidation。
• 创意层判断（衰退分析）：mbfinotti/advertising-skills@ad-creative-fatigue；如果原因并非创意问题，该技能会将问题交回这里，两者互为补充。
• 追踪判断（修复清单）：mbfinotti/advertising-skills@ad-conversion-tracking。
• 跨平台差异量化：mbfinotti/advertising-skills@ad-attribution-gap。
• 搜索词挖掘：mbfinotti/advertising-skills@ad-negative-keywords。
• 定向设计：mbfinotti/advertising-skills@ad-audience-targeting。
• 预算与出价决策：mbfinotti/advertising-skills@ad-budget-pacing、mbfinotti/advertising-skills@ad-spend-allocation、mbfinotti/advertising-skills@paid-media-scaling 和 mbfinotti/advertising-skills@ad-bidding-strategy。

访谈

打开任何数据前先提问。每条消息只问一个问题；尽可能提供多选答案；已提供或能从数据中看到的信息就跳过。

• 账户投放在哪些平台？（搜索 / 付费社交 / 视频 / 原生广告 / 多个平台）
• 面向 B2B 还是 B2C/电商？
• 月花费是多少？针对账户优化的事件，每月大约有多少次转化？（这决定证据门槛是否可能达标。）
• 哪个时间段受到怀疑——表现何时开始下滑？是与哪个此前的时间段比较？
• 有哪些变化，具体发生在什么时候？（预算、出价、创意、定向、优化事件、落地页、网站发布、同意横幅、价格、促销日历——具体日期比变化清单更重要。）
• 可以导出哪些数据，粒度如何？（按广告系列逐日的数据是实际工作的最低要求；按广告组和广告拆分的数据则可用于定位问题。）
• 目标 CPA/ROAS 是多少？它是根据单位经济效益推导得出的，还是沿用了仪表板中的数值？
• 能否获取 CRM 或后端收入数据进行核对？（可以直接获取 / 可以通过他人获取 / 不可以。）
• 报告使用哪种归因窗口和计数设置？这些设置在该时间段内是否有变更？
• 谁负责落实修复措施？他们可投入的精力上限是多少——可用工时、由谁负责（开发人员、营销运营、创意工作室、页面负责人），以及允许的变更可逆性如何？（交接计划面向这些负责人；关于精力上限如何重塑待办队列，请参阅“优先级排序”。）
• 最迟要在什么日期前从报告中看到恢复？（硬性期限会优先考虑见效快的修复措施——修复追踪问题、为确实受预算限制的广告系列解除限制；而离线结果数据接入和创意方案的优先级会降低，因为它们通常要过一两个时间窗口才能见效。）
• 目标是一次性恢复，还是打造能持续增效的资产？（如果要求持续增效，应优先考虑离线结果反馈闭环和结构性整合，而不是快速见效的措施；请参阅“优先级排序”。）

工作流

1. 运行访谈；在接触数据前收集所有回答。

2. 先核对，再解读。 在归因滞后期已充分成熟的窗口内，将平台报告的转化与 CRM／后端的真实数据进行比较，并参考 OnlyDeb 的从业者参考值：

   • 差距超过约 40%：说明出了问题——停止分析，记录跟踪 FAIL，并移交处理。
   • 差距在约 10% 以内：继续检查其他层。

   这些只是归因的起始参考值，并非定律——真正的判断标准是账户自身的历史比率，以及该比率周与周之间是否_稳定_。如果无法访问后端数据，则后续所有发现的置信度最高只能为中等，结论中必须说明这一点。

3. 使用 references/metric-decomposition.md 对失败指标进行拆解。沿着漏斗逐级分析——展示 → 点击 → 转化 → 收入——并将结果表示为 CPM × CTR × CVR × AOV（Pigeon Digital），找出实际发生变化的单个环节。在定位到失败环节之前，不要指出任何原因。

4. 细分并比较。 先按广告系列提取失败指标，再按广告组、广告逐层细分，并分别与账户自身的历史数据比较——绝不使用行业基准。AdStellar 关于 CPM 的规则也适用于其他指标：如果所有项目都普遍偏高，原因可能在外部；如果问题集中于某个分支，则可能是有针对性的内部原因。此步骤用于区分内部原因与外部原因。

5. 按固定顺序逐层检查（见下文），并使用 references/layer-evidence.md。每层都记录以下四种状态之一——pass（证据排除了该原因）、FAIL（证据确认该原因）、unknown（缺少证据）、not applicable，并为其分别标注严重程度和置信度。切勿简化为二元判断：unknown 不等于 pass；把未经检查的层视为正常，是审计出错最常见的原因。

6. 应用证据门槛（见下文）。如果未通过，结论应为 insufficient evidence：明确说明需要增加多少天的数据、多少支出或哪些访问权限才能满足要求，然后停止分析。数据不足以支撑结论时，不得下结论。

7. 给出根因结论（见下方区块；示例见 references/examples.md）。复合结论——即确认存在两个互不相关的原因——是合理的；应按优先级排序。

8. 按效率排列发现（见“优先级排序”部分），并撰写交接内容：按层级顺序说明每项发现由哪个关联技能或负责人接手。

9. 记录预测。 每项结论都必须说明建议的修复上线后，哪个指标应朝哪个方向变化，大约变化多少——这些信息将作为“衡量”部分的原始材料。

10. 将复查日期设为修复上线后一个完整的对比窗口，并确保归因滞后期成熟度一致。

11. 如果运行环境支持持久记忆，请记住账户基线、各层筛查结果、结论、已实施的修复、预测和复查日期，以便下次运行直接从历史记录开始，而非重新推导。如果不支持，则输出一段简短的状态信息块，供用户粘贴到下次会话中。

如果运行环境可以读取导出文件或执行计算，请直接完成每一步；否则，给出确切的导出步骤和电子表格公式（列、比率、变化值 (current - baseline) / baseline），让用户执行并反馈结果。

层级顺序

顺序固定，因为只有前面的层级成立，后续层级的证据才可读：

• 追踪会污染每个数字。
• 结构会污染目标定位和创意分析所依赖的数据汇总与学习。
• 出价分析默认其上游的竞价输入合理。
• 优惠与后续环节位于点击之后。
• 外部原因属于排除性诊断，只有在内部证据排除其他原因后才能认定——第 4 步的统一性测试可以快速得出这一结论，但绝不能跳过追踪检查。

Baker 的 8 层框架说明了原因：如果某个账户的像素会传入 56% 的错误数据，那么在该账户上审核创意“得出的结论看似正确，但在数学上毫无意义”；他还报告称，在每月支出 $3K-$250K 的 B2B SaaS 账户中，80% 的表现不佳都与像素健康状况和创意多样性有关，而非出价或预算。这是一个流程，而不是菜单：这些层级不能任选其一，因此不存在效率排名——每一层都要按此顺序检查。排名要到下一步才会出现，针对的是检查得出的_修复项_（见“优先级排序”）。

1. 衡量 / 追踪——转化信号是否真实、已去重且已获得同意？
2. 结构——账户碎片化、相互重叠的广告系列彼此竞争、预算陷阱、优化事件错误。
3. 目标定位——受众重叠、饱和、范围过窄 / 过宽、意图错误。
4. 创意——共鸣度衰减；具体差异分析由 mbfinotti/advertising-skills@ad-creative-fatigue 执行。
5. 出价 / 预算——策略与流量量级不匹配、学习状态、因预算不足或排名过低而损失的展示份额。
6. 优惠与后续环节——价格、促销、页面、结账；标记后交由 mbfinotti/advertising-skills@paid-landing-page-audit 处理。
7. 外部——竞价膨胀、季节性、竞争对手入场；通过整体普遍上升和市场证据加以确认。

各层的确认性证据、排除性证据，以及用于定论的检查：references/layer-evidence.md。

证据门槛

如果数据不足以支撑结论，就拒绝下结论。任何层级的 FAIL 要成为结论前，以下四项检查都必须通过：

• 转化量。 两个时间窗口内都要有足够的转化量，确保观察到的差异超出噪声（相关转化率的波动范围约为 p ± 2 × sqrt(p × (1-p) / n)）。以下为参考数据点，而非硬性规定：Google 建议评估自动出价时，Target CPA 至少有 30 次转化，Target ROAS 至少有 50 次转化（Google Ads 帮助中心）；OnlyDeb 指出，每月转化次数低于约 15-30 次的广告活动，对算法而言根本缺乏足够信号——低转化量账户（大多数 B2B 账户）应改为以先行指标作为门槛，并在置信度说明中明确指出。
• 学习阶段状态。 不得根据投放系统仍在重新校准时收集的数据下结论。参考数据点：Meta 广告组通常在 7 天内达到约 50 次优化事件后退出学习阶段（Meta Business 帮助中心，据 AdStellar 转述）；Google Smart Bidding 可能需要最多三周或 1-2 个转化周期（Google Ads 帮助中心）。Niblin 指出，学习阶段期间，ROAS 每日波动 20-50% 属于正常现象——只在退出学习阶段后，或至少经过 7 天后再评估。
• 时间窗口可比性。 基线窗口和对比窗口必须时长相同、归因延迟成熟度相同（近期数据总是会少报；滚动窗口看起来总像是在下滑）、星期构成匹配，且不存在已知故障。Jyll Saskin Gales 会在 90 天窗口内一并审查所有正在投放的广告活动，因为广告活动“会相互影响”——绝不要只挑一周的数据，孤立地评估单个广告活动。
• 归因一致性。 绝不要汇总或对比归因窗口、计数方法或模型不同的转化——7 天点击数据加上 30 天点击数据不是总数，而是类别错误。定义统一前应并列报告；窗口中途更改设置会使整个比较失效。

未通过门槛时：结论为 insufficient evidence，并说明如何通过计算消除不确定性——按当前流量，n 需要缩小到噪声区间低于观察到的差异时，还需要增加多少天或支出；或者指出缺少的具体访问权限（CRM 导出数据、广告级细分数据）。

根因结论

每项诊断交付一个结论块：

ROOT-CAUSE VERDICT - <account>, <date>
platform(s)    : <...> | model: B2B | B2C
window         : <comparison window> vs baseline <baseline window> (lag maturity matched: yes/no)
volume         : <spend>, <conversions> conversions in window | reconciliation gap: <x% vs backend | unverified>

decomposition  : <which link moved: CPM / CTR / CVR / AOV - direction and size vs own history>
localisation   : <uniform across account | concentrated in: campaign/ad set/ad>

layer screen
  measurement/tracking : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  structure            : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  targeting            : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  creative             : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  bidding/budget       : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  offer & downstream   : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]
  external             : pass | FAIL | unknown | n/a - <evidence>   [severity, confidence]

confidence     : high | medium | low - <basis: gate math, reconciliation state, unknowns count>
verdict        : <root cause layer(s), or insufficient evidence - with the one-sentence causal story>
evidence       : <the two or three observations that carry the verdict>
findings       : <ranked by efficiency - each with severity, confidence, outcome bought, effort, owner>
prediction     : <metric expected to move, direction, rough size, by when>
handoff        : <sibling skill or owner per finding, in sequence>
re-check       : <date - one full window after fix, lag-mature>

优先级排序

移交前先为发现的问题排序——平铺直叙地列出 20 条观察结果是提案文档，不是诊断。按效率排序：每单位工作量所能带来的结果。绝不能按成本最低排序，也不能按各层级筛查的行顺序排序——筛查顺序是诊断流程，排序结果才是工作队列。

默认修复类别顺序，按价值与工作量之比从高到低排列：

1. 追踪修复 - 让账户中其他所有数字重新具备可读性，并让投放再次依据真实信号运行；需要一名开发人员投入 1 小时到半天，大部分时间用于端到端测试。始终优先执行：衡量后续每项修复时都要以它为基准。
2. 优化事件 / 离线结果修复 - 让平台追逐符合条件的结果，而非廉价的流量（Koda：离线反馈循环“持续提升潜在客户质量，效果胜过任何定向调整”）；需要几天时间进行营销运营和 CRM 接线，大部分用于字段映射和测试，之后无需进一步投入就能持续发挥作用。
3. 结构整合 - 为数据不足的单元提供所需的转化量，使其退出学习阶段；需要几天时间重建，加上一个学习周期的波动，之后再拆分的代价很高。
4. 定向重设计 - 让尚未饱和的受众触达率有所提升；需要约一天时间，而且可以轻松撤销。
5. 优惠与下游修复 - 其成效可能胜过以上所有项目，但工作在账户之外：需要协调负责页面、价格或结账流程的人员，因此进度由对方的日程安排决定，而不是审计人员。
6. 创意替换 - 在确认创意效果衰退后，重新赢回点击；需要一个制作周期，而且永无止境——这是持续性工作，不是一次性修复。
7. 预算和出价调整 - 只有在以上所有层级都通过后才有意义，而且每次重大编辑都会消耗一个学习周期（参见“为什么‘提高预算’不是正确的默认做法”）。

这些维度彼此矛盾，这正是本能式修复总能赢得争论的原因：

• 效率：追踪 > 事件修复 > 结构整合 > 定向 > 优惠与下游 > 创意 > 预算调整
• 价值：优惠与下游 == 追踪 > 事件修复 > 结构整合 > 创意 > 定向 > 预算调整
• 工作量：优惠与下游 > 创意 > 事件修复 == 结构整合 > 定向 > 追踪 > 预算调整
• 合规成本：事件修复 > 追踪 > 其他所有层级（无）——将 CRM 结果推送到广告平台会触发数据处理和同意依据审查，而且无法撤回；重新触发转化事件会影响同意横幅和平台的数据使用条款。

预算调整在工作量和效率上同时排在最后：几乎不费力，却几乎没有结果，这并非低成本的胜利，而是附带学习重置的舍入误差。

这种排序最容易忽略的是：优惠与下游。 它与追踪并列为页面上价值最高的项目，且工作量最大，因此按比率只能排到第 5 层级——默认层级规则也意味着，只有在其他四个层级都通过或已完成后，才会触及它。账户可以运行这项诊断一年，却一次也不检查价格、优惠或页面。符合以下任一条件时，应将它提升到首位：分解结果将故障定位在点击之后（CVR 大幅下滑，但 CPM、CTR 和展示份额保持稳定）；或者页面、价格和结账流程的负责人都在用户自己的团队中——原本的工作量来自协调成本，而非实际工作，由内部团队负责即可消除此成本。

默认层级：从屏幕标记为 FAIL 的最高层级开始；只要追踪状态为 FAIL 或 unknown，就绝不能低于第 1 层级。只有在上一层级为 pass 或已完成后，才向下移动一个层级。

此排序是默认方案，不是铁律——它会因账户情况和执行人员而变化。根据你在此处已知的信息重新排序：

• 内部开发人员可以让第 1 层级成为当天即可完成的工作。
• 已签约的创意工作室会使第 6 层级高于其默认位置。
• 无法接受学习周期波动的企业会将第 3 和第 7 层级下调。

访谈中关于截止时间、一次性与复利效应以及工作量上限的回答，也会以同样方式改变各层级的排序。 用户实际提出的一项约束，会带来与重新排序不同的处理方式：直接从排名结果中删除被排除的修复类别，而不是把它放到底部；并在交接说明中注明已删除、导致删除的约束，以及什么条件出现后可以恢复该项修复——“线下结果闭环：已删除，范围内任何地方都无法访问 CRM；有了导出文件后恢复”。

一项修复如果只是排在没人会看到的列表末尾，就和根本没人考虑过它没什么区别，而且下个季度它又会作为新想法出现。只有一种例外：结论认定为根因的修复绝不删除。它应升级给有权解除约束的人处理——在没有开发人员时间、且有工作量上限的情况下，追踪结果为 FAIL，应升级处理，而不是降级或删除。

为每项发现标注：

• 严重程度：不修复会造成什么损失。
• 置信度：证据有多可靠，与严重程度分开标注。
• 可挽回的结果：修复能挽回的价值（Conner Crowe 要求为每项修复标注这一点）；数据无法说明时标记为“未量化”。
• 工作量，按数量级估算：接近零、一小时、一周、一季度、一项长期工作。
• 负责人：根据访谈中关于实施者的回答确定。

默认使用 ICE（影响、置信度、易行度）评分。只有在排名必须经得起未参与诊断者的质疑时，才使用 RICE（覆盖范围 × 影响 × 置信度 / 工作量 - Sean McBride at Intercom）：效率：ICE > RICE，价值：只有计划必须经得起质疑时，RICE > ICE，因为 ICE 只需几分钟，而且能复现 RICE 的大部分排序；而 RICE 需要额外估算覆盖范围，带来的是可辩护性，而不是准确性。按阶梯顺序交接计划，并为每项发现注明负责人。

为什么“增加预算”不是默认的正确选择

这是最常见的建议，也是这项技能存在的原因：拒绝这种建议。以下是四种机制，各有来源：

• 学习阶段会重置。 在 Meta 上，一次编辑中的预算增幅超过约 20%，通常会被视为重大编辑并重启学习阶段（这是从业者的解读，由 Modern Marketing Institute 和 Grow With Sakib 转述）；Grow With Sakib 估计，每次重置都会导致下一周的 ROAS 损失 5-15%，学习阶段的 CPA 则会高出 20-50%。给出问题的账户投入更多资金，只会买到同一问题的更糟版本。
• 预算与排名。 展示份额损失可分为预算不足导致的损失和排名不足导致的损失（Adalysis；Workshop Digital）——而且，“如果广告排名不足，单纯增加预算并不能保证搜索展示份额达到 100%”（Workshop Digital）。先诊断两者的占比；如果损失源于排名，预算就毫无作用。
• 收益递减。 Trustworthy Digital 指出，当展示份额超过约 60-80% 时会出现收益递减：后续增量的成本会超过其带来的合格营收。展示份额接近上限时，增加预算买到的将是拍卖中最差的展示机会。
• 相关性不等于增量。 平台报告的转化是平台声称的结果，并非平台带来的结果：“平台 ROAS、Google Analytics 和末次点击模型报告的都是声称的营收。它们都无法证明哪怕一美元营收是增量营收”（Stella）。Lifesight 报告称，一家连锁超市对非品牌付费搜索进行地理区域留出实验后，发现销售额提升为 0%。仅仅因为渠道的仪表板看起来不错就扩大该渠道，扩大的是平台的声称，而不是营收。Ben Heath 一语道破：“预算高并不保证效果。更值得投入精力的是出色的创意和有吸引力的优惠。”

只有在诊断确认投放确实受预算限制，且所有上游环节都通过后，预算建议才会作为这项技能的_交接_结果，交给 mbfinotti/advertising-skills@ad-spend-allocation 或 mbfinotti/advertising-skills@paid-media-scaling。

B2B 与 B2C

两者的方法完全相同：层级顺序相同、拆解方式相同、门槛相同、结论形式相同。不同之处在于数据状况，以及哪些数字能反映真实情况。

维度	B2B	B2C/电商
评估周期	转化量较低，销售周期较长（GrowthSpree 指出，平均周期超过 84 天；SQL/销售管道结果会在被跟踪的转化后 30-90 天才显现）；至少需要 4-6 周的评估周期，数据才可靠（Koda），且证据门槛主要依据领先指标。	流量足以支持完整的统计门槛和每日读取数据。
主要根本原因	针对错误的转化事件进行优化：平台能大量获取的低成本表单提交，但“仪表板上的潜在客户看起来很棒，销售团队却说一塌糊涂”（Happy Cog）。	平台 ROAS“在 iOS14 后系统性地虚高”（Eightx）。
修复类型	离线反馈闭环：将 CRM 结果（MQL/SQL/已成交）反馈给平台；Koda 报告称，这“持续比任何定向调整都更能提升潜在客户质量”。	读取综合指标，而非原始平台 ROAS：将 MER（总收入 / 总营销支出；Superscale）与基于利润率推导出的盈亏平衡点进行比较（按 Meerkats 的说法，大约为 1 / 贡献利润率 %）。
反映真实情况的 KPI	SQL 成本和每个已成交客户的成本——“B2B 中唯一能反映真实情况的 KPI”（Swydo）——绝不能用 CPL。	按产品划分的贡献利润，因为综合 ROAS“掩盖了那些正在侵蚀利润率的产品”（Jordan Glickman）。
数据真相来源	CRM。	订单表。

在这两种模式中，工作流里的核对步骤都是同一项操作，只有数据真相来源不同。

审计员的失效模式与偏见

接受诊断的不只是账户，审计员也在其中。作出结论前，请先对照此表审查审计员自己的读数。

陷阱	为什么会造成损失	修正方法
锚定前任所有者的说法	听到的第一个说法会成为一切数据都被套入的假设（inStreamly）	暂时忽略继承下来的说法，直到数据独立地证实它
近因偏差	过度看重最近几天的数据；日常噪声看起来像是业务崩溃	在查看任何盘中波动前，先切换到周线／月线视图（Go4Trades；Niblin）
确认偏差	对数据的解读倾向于支持现有策略（inStreamly）	在下结论前，写下与主要假设相悖的证据
古德哈特定律／指标执念	优化的是得分，而非目标——Google 的 Optimization Score 只需忽略建议就能达到 100%（Store Growers）	将平台评分视为手段，绝不把它当作健康状况的判定标准（Goodhart，1984）
过度信任平台报告的数字	“Meta 声称是一个数字，Google 声称是另一个数字，而实际后端收入完全是第三个数字”（HYROS）；每个平台都会自我归因，仿佛自己是唯一渠道（Enalitica）	首先与后端实际数据核对；绝不汇总平台声称的数据
推销审计服务的动机	在提交方案前先提供免费审计，从结构上就会偏向于得出“一切都有问题”的结论（Conner Crowe）	每项发现都需要有证据，并估算投入与结果，而不是只统计红色警示的数量
在症状出现的层级进行修复	可见指标位于原因链条的下游；CVR 下滑很少真的是 CVR 本身出了问题	沿链条向上追溯；在源头层级修复
只提出一个假设，却通过修复来验证	多个未经验证的修复叠加，会破坏基线，也无法判断恢复的归因	一次只验证一个可证伪的假设；发布修复前，先预测指标会如何变化
挑选基准	行业平均值的构成、地域和定义各不相同	以账户自身的历史数据为基线；基准仅作方向性参考
盲目照搬最佳实践	不考虑账户背景就套用清单——“成功账户有许多不同的结构方式”（Foxwell）	每项发现都必须引用该账户的证据，而非通用规则

衡量是否奏效

此技能的 KPI 是诊断准确率，通过滚动日志追踪每项判定及其第 9 步预测：

• 预测命中率：推荐的修复上线后（且仅该修复上线后），在滞后期已成熟的复查中，预测指标按预测方向变动（且幅度有意义）的判定所占比例。
• 推翻率：后来被推翻的判定所占比例——无论是二次诊断、增量测试，还是修复失败表明所指认的根因有误。

初始基准——这是此技能自身的工作目标，并非经研究得出的定值：持续迭代方法，直到高置信度判定的预测命中率至少达到 70%，且所有判定的推翻率低于 15%，然后根据账户自身的日志进一步提高标准。

• 如果通过了门槛检查，但命中率仍然偏低，通常意味着对各层证据的解读过于宽松。
• 如果推翻率集中在某一层，且整体偏高，说明该层的排除检查力度不足。

unverified 对账行未验证时仍给出的判定应单独追踪——如果这类判定更常被推翻，就说明下次应坚持要求访问后端。

参考资料

• 检查各层时阅读 references/layer-evidence.md——逐层列出确认性证据、排除性证据，以及能得出定论的检查。
• 定位故障环节时阅读 references/metric-decomposition.md——CPM × CTR × CVR × AOV 恒等式、漏斗链路、各项指标方向的含义、流失的展示份额、频次，以及学习阶段机制。
• 编写判定内容时阅读 references/examples.md——一个根因是追踪问题的 B2C 案例、一个根因是错误转化事件的 B2B 案例、一个被证据门槛识别出的迷惑性假阳性案例，以及正确做法旁边的错误做法。