经销商门店位置很少会规规矩矩地集中在一个数据库里。一个厂商给你的是干净的名录，另一个用的是交互式地图，第三个要求你输入邮编搜索，第四个则把经销商详情藏在单独的个人页面里。
当业务规模扩展到几百个网站时，工作就不再只是“抓几个地址”这么简单了。真正要交付的，是一份可信赖的经销商主数据，它能够回答这些业务问题：
- 分销是在扩张还是收缩？
- 哪些区域存在覆盖空缺？
- 哪些经销商被新增、搬迁或移除？
- 哪些门店提供某条产品线或某项服务？
- 新发现的经销商应该分配给哪位 CRM 负责人？
- 竞争对手的渠道版图是如何随时间变化的？
实际可行的架构其实很清楚：先发现数据源，再对门店定位页进行分类，抓取到统一的规范 schema 中，保留来源证据，处理重复项，识别有意义的变化，并把这些变化路由给合适的团队。
目标系统
一套生产级的经销商追踪工作流通常包含六层：
- 来源注册表： 记录网站、定位页 URL、国家、负责人、模式、调度频率和上次运行状态。
- 发现： 用可重复的方法找到目录页、站点地图、API、搜索表单和详情页 URL。
- 提取： 通过浏览器或 API 任务，从不同版式中采集相同语义字段。
- 标准化： 在不丢失原始值的前提下，统一地址、电话号码、国家、类别和状态标签。
- 实体与变更层： 形成经销商的统一身份、品牌归属、首次发现和最近发现时间，以及确认的新增或移除记录。
- 激活： 提醒通知、CRM 路由、覆盖分析、仪表盘和人工复核队列。
如果试图直接从网站一步跳到 CRM 导入，通常只会堆出一团脆弱的临时脚本和重复记录。真正能让几百个站点可管理的，是来源注册表和统一的规范模型。
第 1 步：定义统一的经销商 schema
先从最终输出倒推，而不是从第一个网站开始。一个实用的最小 schema 如下：
| 分组 | 字段 |
|---|---|
| 来源证据 | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| 身份 | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| 地址 | street_address, address_locality, address_region, postal_code, address_country |
| 联系方式 | phone_raw, phone_normalized, website |
| 位置 | latitude, longitude |
| 商业属性 | services, products, categories, authorized_status_raw |
| 观测信息 | observed_at, first_seen, last_seen, record_status |
| 变更控制 | source_hash, change_hash, parser_version |
Schema.org 的 PostalAddress 为街道地址、城市、州/省、邮编和国家提供了很好的命名基线。标准化数据建议使用 ISO 两位国家代码，同时保留来源页面原样写法。
原始字段和标准化字段要并排保留。如果某个网站写的是 St. John's, NL，而标准化层产出了统一的省份和电话区号，这两种版本都应该保留，方便复核。
第 2 步：搭建来源注册表
来源注册表是整个系统的控制中枢。给每个网站一行记录，包含：
- 域名和品牌
- 国家或市场
- 推测的定位页 URL
- 定位页模式家族
- 推荐抓取模式
- 解析器或模板版本
- 运行频率
- 业务负责人
- 最近一次尝试、成功、空结果和失败运行
- 关于搜索输入或交互要求的备注
不要等到每个定位页都完全搞懂才开始。先把注册表建起来，再随着试点推进不断完善分类。
如何发现定位页来源
重点检查：
- 主导航和页脚中的链接，例如“查找经销商”“门店查询”或“门店定位器”
/sitemap.xml和站点地图索引- 站内搜索
- 搜索引擎查询，例如
site:brand.example dealer locator - 页面源码和内嵌结构化数据
- 定位搜索触发的网络请求
- PDF 或分销商文档，作为备用来源
Sitemaps 协议 要求每个站点地图条目都包含 <loc> URL，并支持站点地图索引。站点地图能加快发现速度，但并不能保证每个动态定位结果都被收录；而 <lastmod> 也不能被当作经销商信息一定更新了的证据。
第 3 步：在扩规模前先给每个定位页分类
大多数经销商网站都可以归进少数几种模式家族：
- 静态 HTML 列表或表格 — 最简单，记录直接出现在页面源码中。
- 分页目录或无限滚动 — 记录会重复出现，但需要翻页或滚动加载。
- 地图卡片加详情链接 — 先拿到摘要卡片，再去子页面补全信息。
- 搜索表单 — 用户需要输入国家、州、省、市或邮编。
- 内嵌 JSON 或网络响应 — 页面只是结构化数据的视觉外壳。
- 精简列表加经销商详情页 — 列表负责身份信息，地址和服务信息放在子页面。
- PDF 或文档目录 — 抽取和变更复核需要走专门的文档路径。
不可能用一个通用爬虫优雅地覆盖几百个网站。更可扩展的做法，是为每个模式家族搭建一套可复用工作流，再按来源做配置。
第 4 步：用 Thunderbit 先验证浏览器工作流
Thunderbit 很适合先在代表性站点上验证 schema，再决定是否投入批量自动化。
试点流程
- 在 Chrome 中打开一个具有代表性的经销商目录页。
- 启动 Thunderbit，使用 AI Suggest Fields。
- 将建议字段重命名为统一 schema 中的字段。
- 为规范化或分类添加 Field AI Prompts，例如把页面可见的国家名映射为 ISO 代码，或者把服务类型归类到预设分类集合中。
- 如果是列表页，开启分页或无限滚动处理。
- 如果单个经销商页面里包含电话、网站、服务或来源 ID，就使用子页面抓取。
- 导出少量样本到 Sheets 或 Excel，并逐条核对来源 URL。
当定位页需要交互、登录态，或者渲染结果无法通过简单请求复现时，浏览器模式尤其有用。请只使用组织有权访问的数据源和账号。
选代表性网站，不要只选最简单的网站
第一轮试点最好覆盖 20 个站点，包含主要模式、地区和页面技术。如果所有试点站点都只是简单静态表格，那么在第一个地图型定位页出现时，流程就会暴露问题。
对每个模式家族，至少验证：
- 一个干净样本
- 一个大型样本
- 一个动态或不规则样本
- 一个带经销商详情页的网站
- 一个字段稀疏或可选项较多的网站
第 5 步：用 Batch Extract API 扩展稳定来源
对于可重复抓取的公开页面，把稳定任务从手动浏览器操作迁移到 Thunderbit Web Scraper API。
Batch Extract 端点 支持一次请求最多 50 个 URL，并使用同一个 JSON Schema。它会返回 job ID，支持并行处理 URL，可对单个 URL 进行错误处理，还能发送 webhook 通知，并提供 renderMode 选项，例如 none、basic 和 full。
批处理设计
- 将语义输出 schema 相同的 URL 归为一组。
- 每批控制在 50 个 URL 以内。
- 选择最轻量、但仍能稳定暴露数据的渲染模式。
- 把 job ID 和解析器版本一并保存到运行记录中。
- 逐个 URL 记录成功、空结果和错误状态，而不是只记录整批状态。
- 只重试失败的 URL。
- 在标准化前保留原始提取值和来源链接。
只要字段的业务含义一致，一个 schema 就可以覆盖不同设计的网站。这正是静态目录页和地图卡片定位页能够写入同一份经销商主数据的原因。
第 6 步：标准化，但不要抹掉证据
标准化是为了让记录可比较，而不是让它们不可审计。
推荐的处理包括：
- 去除多余空格并统一标点
- 统一大小写，同时保留
dealer_name_raw - 在明确国家上下文的前提下解析电话号码
- 将国家和地区名称映射到批准代码
- 一致地拆分或合并地址组件
- 规范 URL，并在适当情况下移除跟踪参数
- 将自由文本服务映射到受控类别，同时保留来源原词
不要覆盖来源的授权标签。如果某个厂商写的是“Authorized Dealer”，另一个写的是“Certified Reseller”，就应原样保存这句话，同时可以在单独字段里再加一个标准化类别。
第 7 步：跨品牌和跨来源解析经销商实体
只靠经销商名称匹配远远不够。Smith Auto、Smith Automotive 和 Smith Auto LLC 可能是同一家，也可能是相邻城市里的三家不同公司。
可使用这样的复合候选键：
标准化名称 + 邮编 + 电话
或者在有坐标的情况下：
标准化名称 + 地理距离 + 门牌号
然后对证据进行评分：
- 名称完全或高度相似
- 电话号码一致
- 邮编一致
- 街道地址相似
- 坐标在较小半径内
- 网站域名匹配
最好建立一张“来源到规范实体”的映射表，而不是立刻把记录硬合并。多个厂商可以指向同一个物理经销商，但仍然保留各自的品牌归属、服务和状态标签。
第 8 步：识别有意义的变化
每一次运行都应该被视为一次观测，而不是一次破坏性的覆盖写入。
建议保存：
- 当前运行的
observed_at - 来源记录首次出现时的
first_seen - 最近一次成功观测时的
last_seen - 原始记录的 source hash
- 标准化业务字段的 change hash
常见且有价值的变更类型包括：
- 新增经销商
- 经销商缺失
- 名称、地址、电话或网站变更
- 授权状态变更
- 服务或产品类别变更
- 门店搬迁
- 来源页面失败或版式漂移
缺失记录一开始应标记为 missing_pending_review。只有在多次缺失后，或经过人工复核，才能确认移除。抓取失败、返回空结果、或选择器失效，都不能作为门店关闭的证据。
第 9 步：把 Google Places 作为可选验证
Google Places Place Details 可以为经销商记录补充或验证稳定的 place ID、显示名称、格式化地址、坐标、电话、网站、营业状态和迁移地点信息，具体取决于所请求的字段掩码和 SKU。
应把它作为辅助信号，而不是判断某个位置是否属于厂商经销商计划的最终依据。厂商来源仍然是该成员关系的权威来源。要保存验证提供方和时间戳，不要悄悄覆盖厂商的状态。
第 10 步：按模式和来源衡量提取质量
质量监控要按运行、模式和域名三个层级来做。
单次运行指标
- 已注册的来源 URL
- 已尝试的 URL
- 成功、空结果和失败的 URL
- 提取到的记录数
- 新增、变更、缺失和未变更的记录数
- 核心字段完整率
- 重复候选数
- 待复核的疑似移除项
- Schema 漂移事件
样本验证
对于每个模式家族和每次主要运行：
- 抽取 20–50 条记录，与来源页面逐条比对。
- 核对预期 URL 数量与实际尝试数、成功数是否一致。
- 按域名检查缺失的核心字段。
- 审查重复聚类和低置信度实体匹配。
- 检查坐标异常值以及国家/邮编不一致的情况。
- 回看一部分看似被移除的记录。
- 记录所使用的 extractor 或模板版本。
目标不是得出一个笼统的全局“准确率”数字，而是知道哪些模式和来源可靠、哪些字段薄弱，以及复核工作应该放在哪里。
第 11 步：把变化路由到业务流程中
不同的变化应该进入不同的处理路径：
- 新增经销商： 路由给销售运营，用于 CRM 创建、负责人分配和区域划分。
- 移除或关闭的门店： 在修改账号状态前，先进入复核队列。
- 地址或电话变更： 更新富化信息，并核查未成交机会或服务覆盖范围。
- 授权状态变更： 通知渠道管理和面向客户的团队。
- 覆盖空缺： 进入区域规划和合作伙伴拓展流程。
- 竞争对手扩张： 更新渠道情报和区域策略。
- 来源反复失败： 进入数据运营队列，而不是销售团队。
每条通知都应包含规范经销商、品牌归属、变更类型、变更前后值、来源 URL、观测时间，以及置信度或复核状态。
30/60/90 天上线计划
第 1–30 天：设计并验证
- 完成统一 schema 和受控分类。
- 搭建来源注册表。
- 分类 20 个代表性网站。
- 验证 3–5 种定位页模式家族。
- 建立样本验证规则和运行指标。
- 交付一版带来源证据的经销商主数据。
第 31–60 天：扩展并自动化
- 将分类扩展到整个站点组合。
- 把稳定的公开 URL 组迁移到批量提取。
- 增加调度、任务跟踪、重试逻辑和错误仪表盘。
- 引入“来源到规范实体”的映射。
- 将已复核的新增和更新接入 CRM 工作流。
第 61–90 天：把变更智能化落地
- 增加面向变化类型的告警和复核队列。
- 引入首次发现、最近发现和移除确认机制。
- 在有助于提升地址置信度时，增加可选的 Places 验证。
- 定义运行级服务目标。
- 每月复盘模式和模板表现。
- 为每个来源家族和业务动作指定负责人。
常见失败模式
每个网站都单独写一个爬虫。 这会带来几百条维护路径。应先给模式家族分类，把可复用逻辑和来源配置分离。
只按经销商名称去重。 名称并不稳定，而且经常重复使用。应结合地址、邮编、电话、坐标和网站证据进行匹配。
覆盖原始值。 一旦丢失来源表达，标准化错误就无法审计。
把空输出当成零经销商。 空输出可能是交互失败、渲染变化或请求被拦截。抓取健康状态应与业务状态分开。
一次漏抓就认定移除。 必须要求重复缺失或人工核实。
把地图服务商当作经销商权威。 地图数据可以验证某个地点，但不能确认其与厂商经销商计划之间的授权关系。
还没测清模式质量就急着扩规模。 当一个小提取错误被放大到几百个站点时，就会变成严重的运营问题。
常见问题
一套 schema 能否覆盖几百个不同的经销商网站？
可以。页面版式会不同，但语义字段——经销商名称、地址、电话、网站、品牌、服务、来源 URL 和状态——大体是一致的。只需要使用不同的提取模式来填充同一套统一 schema。
需要输入邮编才能搜索的定位页，应该怎样自动化？
把搜索表单当作独立的模式家族。定义一个覆盖网格，批量输入不同地点，抓取结果 ID 或 URL，去重重叠的搜索半径，并保留每条结果对应的输入值，方便调试。
经销商位置应该多久刷新一次？
刷新频率要结合业务用途和来源行为来定。价值较高的竞争情报或服务覆盖来源可以按周运行；更新较慢的厂商目录可以按月运行。抓取失败的处理应独立于经销商变更频率。
系统如何区分“经销商被移除”与“抓取失败”？
要把来源健康状态和记录是否存在分开跟踪。失败或空结果的抓取不能更新经销商的 last-seen 状态。只有成功运行才能提供“缺失”证据，而移除必须经过重复确认或人工复核。
Google Places 能否替代网站里的地址和营业状态？
不能。Places 只能用于富化或验证，需保存其时间戳和提供方，并且厂商定位页仍应作为经销商计划成员关系的权威来源。
自动化经销商追踪之所以成功，是因为它被当作一项数据产品来运营：有治理的来源注册表、可复用的模式家族、保留证据、谨慎的实体解析，以及由业务方负责的变更流程。这样的架构可以从 20 个试点站点扩展到数百个站点，而不会让每次页面改版都变成紧急重建。
了解更多
