用网页抓取获取销售线索：搭建 B2B 线索管道

在选择解析器之前，先写一句话来定义什么是有用的客户。例如：“在我们支持的地区开展业务、并明确提供设备检测服务的独立工业维保服务商。”这只是一条用于说明的定位规则，并不是对某个具体市场的论断。

句中的每个部分都应对应可观察的证据。服务页面可以支撑“提供检测”这一条件，网点页面可以支撑地区覆盖范围，而首页上一句含糊的宣传语两者都无法证明。如果你的业务需要某个属性，而现有数据源并未披露，请将其标记为“未知”，不要凭空编造估计值。

把三个经常被压缩进同一个线索评分的问题拆开：

这些输出不应相互覆盖。匹配度再高，也不等于可以外联。获批的联系渠道，也不会让一家不相关的公司变得相关。

在制定纳入规则的同时定义排除规则：现有客户、竞争对手、不支持的地区、此前已被拒绝的客户，以及在抑制名单上的组织。在进行成本较高的数据补全之前先应用一次，导出之前再应用一次。第二次检查可以防范抓取运行期间发生的状态变化。

你的验收契约还应写明必填字段和责任归属。确定由谁处理不确定的匹配、由谁批准新的数据源、由谁有权修改资格规则。当“可供审核”有了书面定义，而不是取决于最后运行的是哪个脚本时，面向线索获取的网页抓取会更容易运维。

先建立一份小型数据源清单。为每个数据源记录访问方式、许可用途、预期字段、更新规律和负责人。如果一个有文档的 API 或获得授权的导出文件能满足同样的需求，它往往比 HTML 更容易维护。

用发现类数据源来找到候选公司，再用组织自有的页面来核实相关属性。名录分类只是发现阶段的一条线索，公司自己的服务页面才是其当前对外宣传内容的更有力证据。但这两类来源都不能证明购买意向。

采集前，请查看网站适用的条款和访问条件。遵守其公布的抓取规则和你配置的限制。Robots Exclusion Protocol（机器人排除协议）描述了面向爬虫的指令，但明确指出这些指令并不是访问授权机制。宽松的 robots 文件并不构成采集或再利用数据的一般许可。RFC 9309

对于面向线索获取的网页抓取，覆盖质量比队列中的域名数量更重要。在确定使用某个数据源之前，先从不同的分类、地区和页面模板中抽样检查。一个以付费条目为主的名录，即使每个提取出的字段在技术上都正确，也可能扭曲你的客户全集。

让发现环节和核实环节可以各自独立替换。如果某个名录无法再使用，你应当能够直接弃用它，而不必重建企业身份模型。关于抓取边界和队列设计，请参阅我们的用 Python 进行网页爬取指南。

先把事实存为观察记录，再将其合并为客户。一条观察记录说明的是某个特定来源在某个特定时间显示了什么，而客户是你对这些观察记录的当前解读。

这种分离可以避免一种常见错误：仅仅因为名录是后抓取的，就用可靠性较低的名录标签覆盖了已核实的服务类别。它还能让审核人员追溯资格判定为何发生变化。

如果页面确实提供了有意义的更新日期，请单独保留 source_updated_at 字段。今天抓取到某个页面，并不意味着其中的信息是今天写的。同样，版权年份也不是判断某项服务说法的可靠时间戳。

有些网站会以结构化数据的形式发布组织信息。Schema.org 的 Organization 词汇表定义了名称、URL、地址和标识符等属性。把这些字段当作提取候选，然后核实该标记描述的确实是目标组织，而不是发布方、母公司或页面上其他不相关的条目。

对缺失的信息使用 null。不要把缺失的服务类别变成“不提供该服务”，也不要把缺失的地点变成“不在我们的市场范围内”。“未知”和“否定”是两种不同的状态。保留这一区别，能让面向线索获取的网页抓取比一张悄悄把提取失败变成业务决策的电子表格更有用。

为每个数据源配一个小型适配器，让它以同一模式返回观察记录。将抓取、解析和业务资格判定分开。页面布局变化时，应该只需要修复解析器，而不是重写 CRM 集成。

对于服务端渲染的页面，HTTP 客户端加 HTML 解析器通常就是合理的起点。只有当所需内容确实依赖页面执行或交互时，才使用浏览器。Scrapy 与 Beautiful Soup 的对比有助于区分爬取框架和解析库，Python HTTP 客户端指南则涵盖了请求层。

为每个采集任务设定限制：获准访问的主机、最大页面数、请求超时、响应大小、每个主机的并发数以及有上限的重试次数。一个对发现的每条链接都照单全收的爬虫，会逐渐偏离到无关页面，让成本和审核工作量成倍增加。

把错误当作经过分类的结果来处理。遇到速率限制时，应放慢或暂停采集。收到 forbidden（禁止访问）响应时，应触发对该数据源的复查，而不是没完没了地尝试绕过限制。响应成功但缺少预期字段时，应进入解析器排查队列，而不是变成一条空的企业记录。

Scrapy 的 AutoThrottle 扩展会根据响应延迟调整下载间隔，同时遵守已配置的并发和延迟设置。它是一个有用的调度组件，但你仍然需要针对各个数据源的访问决策和运行限制。

分别跟踪页面抓取量、解析成功数、必填字段覆盖率和审核通过数。HTTP 成功率看起来可能很健康，而改版后的页面模板却在悄无声息地删掉每一个有用字段。对线索数据采集器来说，“任务已完成”远不如“预期的客户证据通过了校验”有信息量。

在匹配记录之前，先规范化空白字符和明显的 URL 变体。保留原始值，方便审核人员查看发生了哪些变化。不要过度删减公司名称中的词语，以免不同的企业变得无法区分。

下面的 Python 示例只处理合成的观察数据。它会规范化主机名并将记录分组以便审核，但不会抓取网站、不会解析法律实体，也不会批准 CRM 中的合并。

from collections import defaultdict
from urllib.parse import urlsplit


def domain_key(value):
    value = value.strip()
    candidate = value if "://" in value else "https://" + value
    parts = urlsplit(candidate)
    if parts.scheme not in {"http", "https"} or not parts.hostname:
        raise ValueError("Expected a company HTTP(S) website")
    if parts.username or parts.password or any(c.isspace() for c in value):
        raise ValueError("Credentials and whitespace are not accepted")
    _ = parts.port  # Reject malformed or out-of-range ports.
    host = parts.hostname.rstrip(".").encode("idna").decode("ascii").lower()
    return host.removeprefix("www.")


observations = [
    {"name": "Example Tools", "website": "https://www.example.com/about",
     "source_url": "https://directory.example/companies/one"},
    {"name": "Example Tools Ltd", "website": "example.com/",
     "source_url": "https://example.com/services"},
    {"name": "Example Regional", "website": "regional.example.com",
     "source_url": "https://regional.example.com/about"},
]

groups = defaultdict(list)
for observation in observations:
    groups[domain_key(observation["website"])].append(dict(observation))

assert len(groups["example.com"]) == 2
assert len(groups["regional.example.com"]) == 1
assert domain_key("https://EXAMPLE.com:443/") == "example.com"
print({key: len(rows) for key, rows in sorted(groups.items())})

输出包含两个候选分组：example.com 有两条观察记录，regional.example.com 有一条。保留子域名是有意为之。永远不要假定只保留主机名的最后两段标签就能识别一家公司：公共后缀和共享主机会让这条捷径变得不可靠。

Python 的 URL 解析文档提醒，解析函数并不会校验 URL。这里的检查只服务于一个有限的匹配演示，并不是网络安全控制。生产环境中的抓取程序在发起请求前，必须另行校验目标地址和重定向。

域名匹配是有用的证据，但并不等于完美的身份识别。不同的子公司可能共用一个域名，一个组织也可能拥有多个品牌和多个国家/地区域名。把有歧义的情况连同候选客户 ID 和匹配理由一起送入审核队列。只有被接受的匹配才应更新你的别名表。

这一区别是让面向线索获取的网页抓取保持可靠的关键：去重应当减少重复客户，同时不删除那些揭示冲突的证据。

先从可解释的资格规则开始。一个客户可能满足服务条件、未通过地域要求，或因缺少证据而悬而未决。在计算任何总体优先级之前，先把这些单项结果存下来。

在最初的试点中，可以使用“可进行客户审核”“需要补充证据”和“已排除”之类的类别。与把未知项和负面信号混成一个不透明数字的分数相比，这些标签更容易审计。如果之后要加入权重，请为规则集做版本管理，并保留促成每个结果的理由。

为 CRM 划定清晰的边界。获批的记录可以成为客户调研条目，但不应仅仅因为导入成功就自动触发外联。把“是否可以联系”的决策留在抓取任务之外。

HubSpot 的 companies API 文档建议附上公司域名以帮助避免重复，并说明了如何按 ID 更新公司记录。无论你使用哪种 CRM，都要保存它返回的标识符，并在发送第二批数据之前定义明确的匹配行为。

维护一份导出台账，记录你的客户 ID、目标记录 ID、载荷（payload）版本和最近一次确认的结果。重试时，先核对上一次尝试的结果，再决定是否创建新记录。不要以为有了域名字段，每次 API 写入就会自动具备幂等性。

只更新采集器负责的字段。已核实的客户负责人、协商确定的合作关系状态，或手动更正过的法定名称，不应因为爬虫给出了新的猜测就消失。采用可审核的字段优先级策略，并将已成功的导出与待处理的重试分开。

在这个边界上衡量面向线索获取的网页抓取：被接受的唯一客户数、被拒绝的匹配、缺失的证据，以及每个被接受客户的成本。每分钟原始行数只会奖励重复数据。有用的管道奖励的是团队真正可以信任的记录。

只采集为既定客户调研目的所需的业务属性。面向企业层面的定位通常不需要个人手机号码、个人行为记录或敏感的个人特征。不要仅仅因为页面上展示了这些信息就把它们加进来。

商业场景并不会自动免除隐私义务。英国信息专员办公室（ICO）解释说，UK GDPR 可能适用于 B2B 营销中使用的个人数据，包括公开可获取的信息。其指南还在电子营销规则下区分了法人订户与个体经营者及某些合伙企业。由于立法变化，该页面正在修订中，因此在批准面向英国的工作流程时，请核对其当前措辞。ICO 关于 B2B 营销的指南

在美国，FTC 指出 CAN-SPAM 法案适用于商业电子邮件，且不豁免 B2B 邮件。其指南涉及发件人标识、邮件主题、邮寄地址和退订处理。这些要求针对的是发送消息，既不授予抓取网站的许可，也不能证明在其他司法辖区合规。FTC 合规指南

把适用的政策转化为可操作的字段：获批用途、保留规则、访问限制、抑制状态和审核负责人。由负责的隐私团队或法务团队来判断，对于实际涉及的司法辖区和渠道，什么做法是恰当的。

让抑制状态在多次运行之间持久保留。如果某个客户或联系人必须被排除，那么在另一个网站上再次发现它时，不能悄悄地重新启用它。对下游导出和恢复的备份也要适用同样的规则。面向线索获取的网页抓取是一个采集过程，不能替代“由此得到的数据可以如何使用”这一决策。

• 在构建爬虫之前，先定义客户标准和所需证据。
• 将来源观察记录与规范化后的客户及资格判定分开。
• 把域名匹配视为候选，对共用域名和多品牌的情况进行审核。
• 核对 CRM 重试，并保护人工维护的字段不被自动覆盖。
• 将采集许可、客户匹配度和外联资格作为相互独立的决策来跟踪。

不应该。先创建一条客户调研记录，再由你的销售流程判断是否存在销售机会。一个网站可能展示了相关的服务或地点，却并不表明对方有正在进行的采购项目。将调研客户与销售机会分开，还能让管道报表更有意义，并防止 CRM 把每一家被发现的公司都当作潜在收入。

可以，但应作为一个经过审核的分类步骤，并配合固定的分类体系和来源证据。要求输出指明支撑结论的文本，并允许返回“未知”。把网页内容当作不可信的数据，而不是给模型的指令。在用模型输出来为客户排定优先级之前，先用人工标注的样本评估分类器，并将模型生成的推断与观察到的事实分开。

把它们送入实体审核流程，而不是自动合并记录。一次收购可能改变所有权，但不会立即改变品牌、网站、运营实体或 CRM 中的关系。把公告记录为一条带日期的观察记录，再由负责人决定哪些客户关系和别名需要更新。保留历史标识符，使以往的导出和决策仍可追溯。

面向线索获取的网页抓取，最有价值的产出是一条站得住脚的客户记录。它拥有已解析的身份、有用的业务属性、清晰的来源轨迹，以及他人可以检查的资格判定。抓取的页面数量只是辅助指标。

从一个获批的数据源、一个范围明确的客户定义，以及一小批审核人员能够完整检查的数据开始。在扩大抓取量之前，先修正错误的匹配和缺失的证据。然后再加入定期刷新、经审核的别名和 CRM 核对，同时不改变核心字段的含义。

在采集器旁边放一份简短的运维检查清单：数据源已获批、观察记录有效、客户已匹配、排除项已检查、导出已确认。一旦某个环节失败，就在相应的环节将其拦下，而不是让不确定性一路流入 CRM。

如果维护抓取层占用了你本该用于提升客户数据质量的时间，可以评估 WebScrapingAPI 的 Scraper API，在你已批准的采集范围内抓取页面。无论 HTML 以何种方式到达解析器，你的数据模式、证据检查和资格规则都应始终由你掌控。