經銷商據點很少會整齊地集中在同一個資料庫裡。某家製造商提供的是乾淨的名錄，另一家使用互動地圖，第三家要求輸入郵遞區號搜尋，第四家則把經銷商資訊藏在各自的個人頁面裡。
當網站數量擴展到數百個時，工作就不再只是「抓幾個地址」而已。真正的成果，是建立一份值得信賴的經銷商主資料，能回答這些商業問題：
- 通路是在擴張還是收縮？
- 哪些區域存在覆蓋缺口？
- 哪些經銷商是新增、搬遷或移除的？
- 哪些據點提供特定產品線或服務？
- 新發現的經銷商應該分派給哪位 CRM 負責人？
- 競爭對手的通路版圖如何隨時間變化？
實務上的架構其實很直觀：先找出資料來源、分類據點搜尋器的模式、抽取到單一標準化 schema、保留來源證據、去除重複、偵測有意義的變動，最後把結果派送給正確的團隊。
目標系統
一套可正式上線的經銷商追蹤流程，會包含六個層次：
- 來源登錄表： 網站、據點搜尋頁 URL、國家、擁有者、模式、排程與最後執行狀態。
- 探索： 以可重複的方式找出目錄頁、sitemap、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
- 據點搜尋模式類型
- 偏好的爬取模式
- Parser 或模板版本
- 執行頻率
- 業務負責人
- 最後一次嘗試、成功、空結果與失敗的執行
- 關於搜尋輸入或互動需求的備註
不要等到每個據點搜尋器都完全理解後才開始。先把登錄表建起來，隨著試點推進，再逐步完善分類。
如何發現據點來源
請檢查：
- 主選單與頁尾連結，例如「Find a dealer」、「Where to buy」或「Store locator」
/sitemap.xml與 sitemap 索引- 站內搜尋
- 搜尋引擎查詢，例如
site:brand.example dealer locator - 頁面原始碼與內嵌結構化資料
- 觸發據點搜尋時的網路請求
- PDF 或經銷商文件，作為備援來源
Sitemaps 協定 要求每個 sitemap 條目都要有 <loc> URL，並支援 sitemap 索引。Sitemap 能加速探索，但不能保證所有動態搜尋結果都會被收錄；而且 <lastmod> 也不應被視為經銷商資訊一定最新的證據。
步驟 3：在擴大規模前先分類每一種搜尋器
大多數經銷商網站都可歸入少數幾種模式家族：
- 靜態 HTML 清單或表格 — 最簡單的情況；資料直接存在頁面原始碼中。
- 分頁目錄或無限捲動 — 資料會重複出現，但需要導覽操作。
- 地圖卡片加詳細頁連結 — 摘要卡片需要搭配子頁補足資訊。
- 搜尋表單 — 使用者必須輸入國家、州、省、城市或郵遞區號。
- 內嵌 JSON 或網路回應 — 頁面只是包住結構化資料的視覺外殼。
- 簡略清單加經銷商詳細頁 — 清單提供身份資訊，地址與服務則放在子頁。
- PDF 或文件型名錄 — 抽取與變動審查需要專門的文件處理路徑。
一個通用爬蟲無法有效處理數百個不同網站。可擴展的做法，是針對每個模式家族建立一個可重複使用的工作流程，再依來源做設定調整。
步驟 4：用 Thunderbit 先做瀏覽器工作流程試點
Thunderbit 很適合在投入大量自動化之前，先在代表性網站上驗證 schema。
試點流程
- 在 Chrome 中打開一個具代表性的經銷商目錄。
- 啟動 Thunderbit，使用 AI 建議欄位。
- 將建議欄位重新命名為標準 schema。
- 加入欄位 AI 提示，用於標準化或分類，例如把畫面上的國家名稱映射成 ISO 代碼，或把服務分類到核准的類別集合。
- 為列表頁啟用分頁或無限捲動處理。
- 若個別經銷商頁包含電話、網站、服務或來源 ID，則使用子頁爬取。
- 匯出少量樣本到 Sheets 或 Excel，並逐一驗證每個來源 URL。
當據點搜尋需要互動、登入狀態，或需要一般請求無法重現的渲染時，瀏覽器模式特別有幫助。請只使用組織有權限存取的來源與帳號。
要選代表性網站，不要只挑最簡單的網站
第一輪試點應包含 20 個網站，涵蓋主要模式、區域與頁面技術。如果試點來源全都是簡單的靜態表格，流程看起來會很完美，直到第一個地圖型據點搜尋器出現為止。
每個模式家族至少要驗證：
- 1 個乾淨範例
- 1 個大型範例
- 1 個動態或不規則範例
- 1 個有經銷商詳細頁的網站
- 1 個欄位稀疏或可選欄位很多的網站
步驟 5：用 Batch Extract API 擴展穩定來源
對於可重複的公開頁面，將穩定任務從手動瀏覽器操作，移到 Thunderbit Web Scraper API。
Batch Extract 端點 可在單一 JSON Schema 下，一次接受最多 50 個 URL。它會回傳 job ID、平行處理 URL、支援逐 URL 錯誤、可傳送 webhook 通知，並提供 renderMode 選項，例如 none、basic 與 full。
批次設計
- 將語意輸出 schema 相同的 URL 分組。
- 每個批次維持在 50 個 URL 限制內或以下。
- 選擇能穩定呈現資料的最輕量渲染模式。
- 在執行紀錄中同時儲存 job ID 與 parser 版本。
- 不只記錄整批狀態，也要逐 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。只有在重複缺失或人工審查後，才確認移除。爬取失敗、回應空白或 selector 壞掉，都不能證明經銷商已關閉。
步驟 9：加入 Google Places 作為可選驗證
Google Places Place Details 可依照所請求的欄位遮罩與 SKU，用穩定的 place ID、顯示名稱、格式化地址、座標、電話、網站、營業狀態與搬遷資訊，來補強或驗證經銷商紀錄。
請把它當作次要訊號，而不是判定某個據點是否屬於製造商經銷計畫的最終權威。對於是否為該品牌經銷商這件事，仍應以製造商來源為準。請保存驗證提供者與時間戳，不要在未通知的情況下覆寫製造商的狀態。
步驟 10：依模式與來源衡量抽取品質
品質應該在執行層、模式層與網域層同時追蹤。
每次執行的指標
- 已登錄來源 URL
- 已嘗試 URL
- 成功、空結果與失敗的 URL
- 抽取到的紀錄數
- 新增、變更、缺失與未變動的紀錄數
- 核心欄位完整度
- 重複候選數量
- 待審的疑似移除項目
- Schema 漂移事件
範例驗證
對每個模式家族與主要執行批次，請：
- 將 20–50 筆抽樣紀錄與來源頁面比對。
- 確認預期 URL 數量與實際嘗試、成功數量是否一致。
- 依網域檢查缺少的核心欄位。
- 檢視重複群組與低信心的實體配對。
- 檢查座標異常值與國家／郵遞區號不一致的情況。
- 回頭複查一部分看似已移除的紀錄。
- 記錄所使用的 extractor 或模板版本。
重點不是追求一個全域的「準確率」數字，而是要知道哪些模式與來源是可靠的、哪些欄位較弱，以及應該把審核工夫花在哪裡。
步驟 11：把變動導入商業流程
不同類型的變動，應該送往不同目的地：
- 新增經銷商： 轉給銷售營運，用於建立 CRM、分派負責人與區域規劃。
- 移除或關閉的據點： 在變更帳號狀態前，先送入審核佇列。
- 地址或電話變更： 更新 enrichment，並驗證現有商機或服務覆蓋。
- 授權狀態變更： 通知通路管理與面向客戶的團隊。
- 覆蓋缺口： 提供給區域規劃與合作夥伴招募。
- 競爭對手擴張： 更新通路情報與區域策略。
- 來源重複失敗： 送到資料營運佇列，而不是銷售團隊。
每則通知都應包含標準經銷商、品牌隸屬、變動類型、變更前後的值、來源 URL、觀測時間，以及信心或審核狀態。
30/60/90 天推進計畫
第 1–30 天：設計與驗證
- 定義好標準 schema 與受控類別。
- 建立來源登錄表。
- 分類 20 個代表性網站。
- 驗證 3–5 種據點搜尋模式家族。
- 建立樣本驗證規則與執行指標。
- 交付第一版帶來源證據的經銷商主資料。
第 31–60 天：擴充與自動化
- 將分類擴展到整個網站組合。
- 把穩定的公開 URL 群組移到批次抽取。
- 加入排程、任務追蹤、重試邏輯與錯誤儀表板。
- 建立來源到標準實體的映射。
- 把已審核的新增與更新串接到 CRM 流程。
第 61–90 天：讓變動情報正式運作
- 加入針對變動類型的告警與審核佇列。
- 導入 first-seen、last-seen 與移除確認機制。
- 在能提升地址可信度的地方，加入可選的 Places 驗證。
- 定義執行層服務目標。
- 每月檢視模式與模板的效能。
- 為每個來源家族與業務動作指定負責人。
常見失敗模式
每個網站都做一個獨立爬蟲。 這會產生數百條維護路徑。應先分類模式家族，把可重用邏輯與來源設定分開。
只用經銷商名稱去重。 名稱本來就不一致，而且常被重複使用。應結合地址、郵遞區號、電話、座標與網站證據進行比對。
覆寫原始值。 一旦來源表示被抹掉，標準化錯誤就無法稽核。
把空輸出當成零經銷商。 空輸出可能代表互動失敗、渲染變更或請求被阻擋。請把爬取健康狀態與商業狀態分開管理。
一次漏抓就宣告移除。 必須要求重複缺失或人工驗證。
把地圖供應商當成經銷商權威。 地圖資料可以驗證地點，但無法確認製造商的授權關係。
在衡量模式品質之前就先擴大規模。 小小的抽取錯誤，一旦乘上數百個網站，就會變成巨大的營運問題。
常見問題
一個 schema 能適用數百個不同的經銷商網站嗎？
可以。頁面版型不同，但語意欄位——經銷商名稱、地址、電話、網站、品牌、服務、來源 URL 與狀態——大致一致。用不同的抽取模式去填同一個標準 schema 即可。
需要輸入郵遞區號才能搜尋的據點頁面，應該怎麼自動化？
把搜尋表單視為獨立的模式家族。先定義一個輸入地點覆蓋網格，擷取結果 ID 或 URL，對重疊的搜尋半徑去重，並保留每筆結果對應的輸入值，以便除錯。
經銷商據點應該多久更新一次？
頻率要依業務用途與來源行為而定。高價值的競品或服務覆蓋來源可以每週跑一次；變化較慢的製造商名錄則可每月更新。執行失敗應獨立觸發營運審查，不應綁定在經銷商變更頻率上。
系統如何分辨經銷商是真的被移除，還是爬取失敗？
要分開追蹤來源健康與紀錄是否存在。失敗或空白的爬取，不應更新經銷商的 last-seen 狀態。只有成功執行才能提供缺失證據，而移除也應要求重複驗證或審查。
Google Places 應該取代網站上的地址與營業狀態嗎？
不應該。Places 應作為 enrich 或驗證用途，保存其時間戳與供應商資訊，並保留製造商據點搜尋器作為經銷商計畫成員資格的權威來源。
自動化經銷商追蹤能成功，是因為它被當成一個資料產品來經營：有治理的來源登錄表、可重用的模式家族、被保留下來的證據、謹慎的實體解析，以及由業務擁有的變動流程。這種架構可以從 20 個試點網站一路擴展到數百個，而不會讓每次版型重設都變成緊急重建。
延伸閱讀
