pre-launch-data-check

用途

Pre-launch Data Check 回答一个问题：这个确切的文件今天能否进入发送工具，而不会损害域名、品牌或测试？

它运行在最终文件上，位于 waterfall-enrichment 和 personalization-pipeline 之后、上传之前。更早的关卡决定公司是否匹配（prospect-scoring）以及邮箱能否发送（deliverability-audit）。这一关检查的是即将被发送的行。一个匹配的名单，如果 {{first_line}} 损坏、第 212 行有当前客户、30% 是 catch-all，仍然会烧掉整个活动。

位置

之前：waterfall-enrichment → personalization-pipeline
本检查：pre-launch-data-check：GO / GO WITH FIXES / STOP
之后：deliverability-audit（邮箱）→ 上传

每一轮都要运行，而不是每个客户只运行一次。每个新批次都有自己的重复项、自己的过期信号和自己的空字段。

所需材料

即将上传的最终 CSV（序列使用的每一列）
抑制文件，每个都是 CSV：CRM 导出中所有已在对话中的人、活跃活动中的联系人、当前客户（域名即可）、退订和禁止联系
序列使用的变量列表（first_name、company、first_line…）
可选：邮箱数量和每个邮箱每日新联系人上限

没有抑制文件 = 检查仍会运行，但会将抑制报告为 NOT CHECKED。要明确说出来；外发中最昂贵的错误就是给当前客户发冷邮件。

七个层面

每一层都是停止过滤器或修复项。从上到下执行；任何一层出现 STOP 都意味着文件今天不能发出。

来源：检查文件内重复；与 CRM、活跃活动、客户、退订的重叠；每家公司联系人数量。任何人在抑制名单上则 STOP；有重复或一家公司超过 3 个联系人则 FIX。
验证：检查每个地址的验证状态；格式错误；角色地址；免费邮箱；邮箱域名与公司域名。完全没有验证列，或任何无效/格式错误则 STOP；任何有风险、catch-all 超过批次 25%、角色地址则 FIX。
完整性：每个序列变量存在、已填充并已渲染（没有 {{…}}、N/A、null、[NAME]）。变量列缺失，或任何行中为空/未渲染则 STOP。
路由：每一行都有层级/队列（来自 prospect-scoring 的 A/B/D），如果按发送者拆分则有发送者。没有层级或发送者的行则 FIX。
卫生：名字大小写、公司名中的法律后缀、空标题。JOHN、maria、Stripe Inc.：读者会在第一行看到这些，则 FIX。
信号：信号年龄与新鲜度窗口对比；信号没有来源链接。信号超过窗口（默认 60 天）或没有证明链接则 FIX。
激活：移除后可发送行数与量门槛对比；按当前容量可发送天数。可发送低于量门槛（事件信号假设 300，数据点假设 500）则 FIX。

无效地址和命中抑制是 STOP 而非 FIX，原因很明确：一个会让域名退信，另一个会给已经在和你对话或付费的人发邮件。两者的代价都超过一天的延迟。

运行方式

python3 scripts/check_list.py final.csv \
  --suppress crm_export.csv active_campaigns.csv clients.csv optouts.csv \
  --vars first_name,company,first_line \
  --mailboxes 6 --daily-cap 30 \
  --out rows_to_fix.csv

列会自动检测（email、first_name、company、domain、title、linkedin_url、email_status、tier、signal_date、signal_source）。其他列用 --col email="Work Email" 映射。

只有 domain 列的抑制文件会抑制整个公司（客户、DNC 账户）。

按客户调整：--max-signal-age、--catch-all-max、--max-per-company、--min-volume。

退出码 0 = GO，1 = GO WITH FIXES，2 = STOP，因此可以放在流水线中。

--out 只写入有问题的行，并带一个 problems 列。把该文件交回给负责修复的人。

如果对方还没有 CSV（名单只存在于发送工具中），先导出。不要在样本上运行检查；问题存在于尾部。

流程

索要最终文件和抑制文件。如果缺少任何抑制来源，指出它。
询问序列使用哪些变量。如果序列在手边，从中读取。
运行 scripts/check_list.py。读取输出；不要手工重新推导计数。
对每个 STOP，说明忽略它的代价以及由谁修复。
对 FIX 项，按读者最先注意到的顺序排序：损坏的变量和名字，然后是过期信号，然后是路由。
给出结论和一个下一步。GO 时，如果本周未检查邮箱，则交给 deliverability-audit，否则交给上传。

输出格式

Pre-launch data check: [file], [rows] rows, [date]
Suppression checked against: [files, or NOT CHECKED]

1 Source        [ok / n duplicates / n suppressed]
2 Validation    valid [n%] · catch-all [n%] · risky [n] · invalid [n]
3 Completeness  [each variable: ok / n empty / n unrendered]
4 Routing       [tier split / n unrouted]
5 Hygiene       [n names to fix / n legal suffixes]
6 Signals       [n stale / n without proof / not checked]
7 Activation    sendable [n] vs gate [n] · [n] sending days

VERDICT: [GO / GO WITH FIXES / STOP]
STOP: [numbered, each with the cost of ignoring it]
FIX:  [numbered, most visible first]
Rows to fix: [file]
Next: [one step]

本检查不做什么

它不决定匹配度。一行干净但公司错误，仍然是错误公司。那是 prospect-scoring 和 signal-outbound 中 90% 抽查的职责。
它不验证地址。它读取你的验证器写入的验证状态；如果没有状态，它会阻止你并把你送回 waterfall-enrichment。
它不测试邮箱。那是 deliverability-audit 的职责，两者都必须在首次发送前通过。

按层检查基础数据、从来源到激活的思路，改编自面向收入团队的公开数据完整性框架；这里的阈值是该方法论使用的阈值。