data-research

数据研究

将原始名单整理成标准化的潜在客户名单。为每一行回答三个问题： 这是我们的目标客户吗、为什么现在联系，以及首行写什么。

大多数时候，这不是在建立名单。客户会交来一份 CRM 导出文件、抓取的表格或旧营销活动文件，任务是评估现有数据。如果完全没有名单，就先获取一份（Apollo、Sales Navigator、目录抓取），然后再执行此流程。

一切工作的基础：两者之分

• 信号 = 有日期的事件。在任何时点，冷名单中约有 3–5% 存在此类事件。它告诉你何时联系。
• 数据点 = 永久性事实，例如技术栈、行业、员工人数，以及是否在内部具备相关能力。它告诉你说什么。

用一个信号作为联系理由，再用一个数据点来调整消息内容。没有信号 → 消息读起来就像群发邮件，因为它本来就是群发邮件。

认为名单中的大多数对象都会有信号，是最常见的规划错误。3–5% 是市场的实际情况，不是需要调整的问题。

硬性规则

1. 没有 URL 和日期，就没有信号。 宁可什么都不写，也不要猜。无法证实的信号比空白单元格更糟：它看起来像是做过研究，然后有人会据此写信。
2. 信号来源必须解析到公司的 DOMAIN，而不是公司名称。 一次真实运行的结果：公司自有网站产生了 21 条信号，全部有效；按公司名称搜索 Google 产生了 187 条，准确率约为 40%（它不断返回名称相似的其他公司）；Reddit 和 Upwork 产生了 906 条记录，与名单完全没有匹配项。按名称匹配和开放论坛能找到新潜在客户——它们无法验证你已有的名单。
3. signal_date 是事件发生日期。 执行检查的日期应另设一列。
4. 绝不编造员工人数、交易金额、技术栈或职位名称。 缺失 → 记 0 分，并添加数据补全标记。猜测的数字会成为别人据以行动的预测。
5. 未通过筛选的行不要删除。 保留在文件中，并注明原因。删除的行三个月后会再次被购买和研究。
6. 按个人而非公司去重。 每家公司有 2–3 位联系人很正常，也是我们希望看到的。
7. 只采用最高的一项信号，绝不累加。 多个信号只会让账户在所属等级内排得更靠前，不会增加分数。
8. 反向信号存放在单独文件中，并对所有账户进行检查，包括已取消资格的账户。否则本次运行只会读取未取消资格的行，被过滤掉的竞争对手不会再次接受检查，拦截筛选机制就会失效，竞争对手也会重新进入名单。

执行顺序——先做成本最低的筛选

执行顺序并非表面功夫。每项筛选都按行计价，因此任何能减少行数的操作，都必须先于按行收费的操作。

第 0 步——审查现有数据。 先别花一分钱。在一个实际客户数据集中，客户列的 131 个电子邮箱中，只有 27 个使用了客户自己的公司域名，76 个使用了其他域名，另有 19 个根本不是电子邮箱。还要检查被标记为“CRM 中没有公司规模”的行——这是数据缺失，不是拒绝条件，这些行应该放回数据集中。

第 1 步——停止筛选。 反 ICP 条件和硬性门槛。只要有一项回答“否”，就停止；之后才检查完整性。不要把检测时间浪费在未通过此步骤的行上。

第 2 步——建立公司画像。 筛除最多、成本最低。每家公司执行一次 SERP 查询（名称 + 国家，单页），即可获取服务描述、域名和社交主页。在一个包含 596 家公司的数据集中，这项操作总计花费约 $1.5，让可用细分市场扩大了 1.7 倍，因为仅凭名称和职位无法对半数数据进行分类。相比之下，这比客户通常手动进行的网页核验更便宜。

第 3 步——仅对通过画像门槛的行核实员工人数。 公司自己的社交主页是首要信息来源；通过数据补充将人数细化到具体范围。每家公司约 $0.004–0.006。只有在人数经过核实后才设置分层——在一个包含 188 家公司的数据集中，来源里有一半的规模分档都不正确，其中 83 家公司的实际人数低于所标注的下限。

第 4 步和第 5 步——信号和数据点。交由 signal-research 处理。

这是独立的一步，而不是构建名单的一个阶段，并且要按自身的经济逻辑执行：信号只会在数据集的 3–5% 中触发，而几乎所有数据都能获得一个数据点，因此必须在一次抓取中同时收集两者，否则计算下来就不划算。signal-research 负责信号库、检测阶梯（优先使用成本最低的批量数据源，其次是逐个账户调研，最后才使用付费平台）、证据规则、时效窗口和重新扫描队列。

在此处执行，也就是核实员工人数之后、电子邮箱之前，并取回两项内容：信号块（signal_type · signal_evidence_url · signal_date · signal_route …）和数据点块（datapoint_type · datapoint_detail）。下游的一切——账户进入哪个队列、开场白以什么为依据——都来自这两个数据块。

不要在此技能中重新实现检测逻辑。这里值得重申的唯一一条规则，因为它决定了整个流程的成本：来源必须指向公司的域名，而不是公司名称。

第 6 步——电子邮箱。 仅处理通过筛选的行。参见 waterfall-enrichment 技能。

第 7 步——为每个账户添加第二位联系人（决策者之外的内部倡导者）。

每完成一步，都要记录：覆盖的行数、产生的结果、花费的金额和时间。如果某一步的产出率低于 5%，就如实报告，不要扩大规模重复执行。

成本模型——记录实际数字，而不是“点数”

步骤	单位典型成本	备注
通过 SERP 建立画像	~$0.0025 / 公司	一次查询，单页
抓取公司主页	$0.004–0.006 / 公司	员工人数、描述、专长
抓取网站内容	按批次计价	深度为 1，使用 glob 匹配 URL，每批约 35 个
招聘职位	~$0.005 / 职位	按 slug + 职位名称筛选
电子邮箱瀑布补充	~1.4 credits / 人	参见 waterfall-enrichment

开始前先报出执行费用。对 2,000 家公司的数据集执行所有步骤，成本是已知的，不应令人意外。

评分说明

评分标准本身使用 prospect-scoring——此阶段处于联系之前，因此，只有通过对话才能得知的内容不应计入分数（那属于 lead-scoring，从此档案开始评分）。 此阶段有三项要求：

• 只有核实过的数字才能用于划分等级。 员工人数未经确认时，等级单元格填写“verify manually”——不能留空，也不能猜测。
• 整个类别都没有数据时进行归一化。 原始数据集几乎从不包含交易规模。如果某个 15 分的类别在结构上对所有人都是 0，分数上限就会降低，没人能进入最高档。保留两个数字：简单总分，以及实际有数据的类别所占百分比。按后者划档——但只有数据可信度达到中等或更高时才这样做，否则只有两个已填写字段的行看起来也会完美。
• 安全兜底。 除非关键类别（技术栈匹配度、地理位置、决策者可触达性）都达到各自的门槛，否则账户不能进入最高档。否则就降一档。

已开放 45 天以上的职位，比刚发布的职位是更强的信号——他们一直没能招到人。只要职位仍开放，就不要降低空缺职位信号的权重。

细分

campaign = 队列 × 角色画像 × 等级。一个 campaign 对应一段文本及其自身统计数据。

• 队列 A —— 有明确日期的事件。事件持续多久，队列就持续多久。优先处理。
• 队列 B —— 较弱的信号。
• 队列 D —— 没有信号；开场白基于其网站上的一个数据点。

将 A 和 D 混在同一个 campaign 中，会让平均值掩盖强弱两个细分群体。决策者和内部倡导者应属于不同的 campaign——他们的痛点不同，问题也不同。角色画像矩阵以外的职位名称应单独创建 campaign，并标记为待审核。

输出

扁平 CSV，包含一行表头，值而非公式，列上方不能有分组行。两个文件的列完全相同：一个包含完整数据集，包括所有被筛掉的条目及其原因；另一个包含工作筛选结果。

列块按固定顺序排列：

1. 公司 — row_id · company_name_raw · company_name_clean · domain · country · geo_bucket · city · industry
2. 停止筛选 — filter_geo · filter_size · filter_anti_icp · filter_result
3. 员工人数 — emp_enriched · emp_final · tier
4. 匹配度 — fit_icp · fit_services · fit_score · fit_gate
5. 信号 — signal_type · signal_score · signal_route · signal_evidence_url · signal_date · signal_age_days · signal_summary · signal_2_type · signal_2_url
6. 数据点 — datapoint_type · datapoint_detail
7. 当前业务证据 — client-specific（许可证、招标、职位空缺）
8. 来源控制 — match_method · channel_route · exclusion_reason · source_track
9. 网站 — site_status · site_sectors，然后是客户特定字段（设备、软件、业务量、内部团队）
10. 联系人 — person_first_name · person_last_name · person_title · person_linkedin · person_email · email_status
11. 文本 — angle · observation · guess · question · opener_style · text_gate · text_gate_reason · hook_source · hook_date
12. 细分 — persona_role · campaign · contacts_at_company · persona_gap

第 7 和第 9 块因客户而异。其余部分保持不变。

撰写 signal_summary 时，应确保内容可以原样用作第一句话：具体对象、地点、日期。“截至 8 月 5 日，两个都会区共有 5 个协调员职位仍在招聘”——而不是“快速增长”。

只有第一句话有真实证据支撑时，text_gate = ok；否则填写 review，并说明原因。必须填写 hook_source——没有该字段的行不会发送。

数量门槛

• 以信号为主导的 campaign 至少需要 300+ 行，才能得出清晰易读的统计数据。
• 以数据点为主导的 campaign 至少需要 500+ 行。

低于此数量时，应如实报告。数据集无法满足 campaign 的数量要求，这本身就是关于数据集的发现，不应藏在排版精美的文件背后。

已经踩过的坑

检测陷阱（招聘页面、聚合站、过时的职位信息，以及含义恰恰相反的 /partners 页面）由 signal-research 负责处理。本技能容易出问题的是数据处理：

• 文本格式的日期列有两种格式，导致 max() 和降序排序返回几年前的日期。应改为筛选字面值较新的记录。
• 以文本形式存储的成本列——比较前先转换类型，否则查询会静默返回空结果。
• “due”／“end”／“final”列中出现占位日期（9999、3030）。
• 针对抓取 API 并行启动的线程会产生 DNS 错误；应采用退避策略重试，并通过运行 ID 接续已在运行的任务，而不是重新启动。
• 未设置每个网站的页面数量上限时，爬虫会把全部预算耗在一个大型网站上——应分批处理域名，而不是完全不设上限。
• 同一数值的两个来源（页面数量与标注的范围）必须保留在两个列中。合并后，就无法再区分已验证的数字和推断出的数字。

此技能不做什么

编写序列 · 发送任何内容 · 为人员打分（它以账户为单位）· 因账户看起来重要就编造信号 · 删除失败的行