Google Maps 給你商家記錄，而非可寄送的郵件名單。
Google Maps 匯出包含商家名稱、地址、電話號碼、評分和網站 URL，但不包含郵件地址。從地圖匯出到執行中的冷郵件行銷活動的路徑涉及幾個不同的步驟，每個步驟都會改變資料的形狀和風險狀況。
跳過或壓縮任何這些步驟是可達性問題開始的地方。來自 Google Maps 的抓取商業資料看起來乾淨，但通常並非如此。了解每個階段發生的事情，以及壞資料在哪裡進入流程，是行銷活動運行良好與損害你的寄信網域之間的差距。
Google Maps 郵件抓取與驗證
當您需要完整流程——包括資料抓取、郵件驗證、路由分配和外發觸達——時，請使用完整框架。
此工作流程需要的輸入欄位。
在工作流程開始之前，確認你的地圖匯出有這些欄位。每個欄位都在後續步驟中使用。
| 欄位 | 為什麼需要 | 缺少時怎麼做 |
|---|---|---|
| 商家名稱 | 個人化和去重 | 必填；如缺少請重新抓取或豐富化 |
| 網站 URL | 郵件探索起點 | 沒有 URL 的記錄無法產生郵件；單獨路由 |
| 地址 | 去重和地理定向 | 用於識別共用地址的重複記錄 |
| 電話號碼 | 次要去重訊號 | 當網域或郵件去重未能找到所有重複時使用 |
| 評分和評論數 | 商家規模和活動的資格訊號 | 可選；對優先排序有用 |
| 商業類別 | 寄送前的分類 | 幫助將記錄路由到正確的序列 |
| 來源 URL 或名單 ID | 可追溯性和去重 | 幫助識別相同商家出現在兩條記錄下的情況 |
沒有網站 URL 的記錄無法通過標準探索產生郵件。將它們保留在獨立的無郵件佇列中，用於電話推廣或手動研究。
驗證前先清洗。
在上傳到 BillionVerify 之前執行清洗步驟。驗證對乾淨的輸入更有用且更準確。
- 從活躍郵件工作流程中移除沒有網站 URL 的記錄。將它們路由到電話或研究佇列。
- 識別特許經銷商和多地點記錄，其中所有網站 URL 都指向相同的企業網域。這些將產生重複或企業層級的郵件。在探索執行之前在品牌層級去重。
- 通過爬取每個網站的 mailto 連結、聯絡頁面和頁尾文字，對剩餘記錄執行郵件探索。
- 標準化郵件欄位：所有地址小寫，移除空白，修正格式中的明顯錯誤。
- 移除已知非推廣網域的郵件：預訂平台地址、預訂服務網域，以及顯示為商業聯絡郵件的支援平台地址。
- 首先按精確郵件地址去重，然後按網域。如果超過三條記錄共用相同的網域，調查它們是否代表不同的聯絡人，或者是相同信箱出現多次。
- 標記郵件網域與商業網站網域不匹配的記錄。這些可能通過母公司或舊設置路由。
清洗後，你的名單比原始匯出更小，這是正確的。向清洗後的名單寄送比向完整的原始數量寄送產生更好的結果。
驗證郵件欄位。
這是 BillionVerify 進入工作流程的地方。上傳清洗後的郵件名單並執行完整驗證。
- 將清洗後的郵件欄位上傳到 BillionVerify。
- BillionVerify 檢查網域層級的 MX 記錄以確認郵件伺服器已配置且在線。
- BillionVerify 執行 SMTP 握手檢查以確認具體信箱是否接受郵件。
- BillionVerify 標記全收型網域，其中伺服器無論具體信箱是否存在都接受所有郵件。
- BillionVerify 識別角色型前綴（info@、office@、service@、contact@、appointments@、booking@、intake@）並將其與具名地址分開標記。
- BillionVerify 為每條記錄返回結果：有效、無效、全收型、角色型、有風險或未知。
- 使用郵件地址作為連接鍵，將驗證結果欄位合併回原始記錄。
不要跳過合併步驟。驗證結果只有在附加到完整記錄時才有用，這樣路由決策可以在記錄層級而非郵件層級做出。
路由每個驗證結果。
BillionVerify 的每個結果都應導致一個明確的行動。不改變流程下一步動作的驗證是不值得執行的驗證。
| BillionVerify 訊號 | 流程動作 | 原因 |
|---|---|---|
| 有效的具名商業郵件 | 加入主要寄送序列 | 可達；地址屬於特定的人或具名帳號 |
| 有效的角色型（info@、office@、booking@、intake@） | 加入共用信箱分類 | 有效但不是具名聯絡人；需要不同的文案和路由 |
| 全收型網域 | 加入有量限制的謹慎分類 | 網域接受所有郵件；具體信箱不確定 |
| 無效（語法錯誤、失效網域、缺少 MX） | 抑制 | 從所有寄送佇列中永久移除 |
| 被拒絕的信箱 | 抑制 | 即使網域活躍，具體地址也不存在 |
| 未知或有風險 | 在寄送前審核或豐富化 | 在沒有額外確認的情況下不要大量寄送 |
此路由表應建立在你的匯入步驟或行銷活動工具配置中。每次新的 Google Maps 匯出通過工作流程時，它不應該依賴有人記得要做什麼。
建立寄送序列。
路由後，每個分類進入為其風險和聯絡類型配置的寄送序列。這些分類不應共用一個序列。
| 分類 | 序列方法 | 關鍵設定 |
|---|---|---|
| 有效的具名郵件 | 主要序列；按姓名和商業詳情完整個人化 | 從這裡開始；最高信心 |
| 有效的角色型郵件 | 共用信箱序列；文案承認團隊或商家而非個人 | 不同的主旨和開頭 |
| 全收型郵件 | 降低量的序列；第一次寄送後監控退信行為 | 每個網域限制寄送量；不要執行完整量 |
| 無郵件記錄（有效網站） | 電話或豐富化佇列；不是郵件序列 | 在寄信工具之外路由 |
網域預熱適用於所有分類。如果你從新網域寄送，不要同時開始所有分類。先通過具名郵件分類預熱網域，然後添加角色型，然後是謹慎的全收型。
分別處理角色型和全收型。
角色型和全收型是兩個不同的問題，需要不同的決策。
| 類型 | 意義 | 操作 |
|---|---|---|
角色型：booking@、catering@ | 信箱被監控，但由共用或前台工作人員監控 | 保留；使用提示轉發給決策者的文案 |
角色型：intake@、office@ | 共用信箱；監控因商家規模而異 | 保留；優先考慮信箱能到達老闆的較小商家 |
角色型：info@、contact@ | 大量通用信箱；在較大商家中被大量過濾 | 保留在分類中；調低回覆預期 |
| 全收型：看起來有效的地址 | 伺服器接受所有郵件；具體信箱存在未確認 | 低量寄送；如有任何退信立即抑制 |
| 全收型：企業或特許經銷商網域 | 所有地點郵件路由到相同的全收型 | 每個品牌最多寄送一條記錄；而非每個地點 |
來自 Google Maps 商業清單的角色型地址並非自動無效。餐廳的 booking@ 或牙科診所的 appointments@ 是由真實工作人員監控的真實信箱。問題是你的文案是否給了收件人一個向決策者升級的理由。
抑制並豐富化其餘記錄。
在已驗證的記錄進入其序列後，剩餘的記錄需要明確的處置。不要讓它們處於未決定的狀態。
| 記錄類型 | 下一步 |
|---|---|
| 無效郵件 | 加入永久抑制名單 |
| 被拒絕的信箱 | 加入永久抑制名單 |
| 第一次寄送後退信的全收型 | 加入抑制名單；不要重試 |
| 無郵件，有活躍網站 | 路由到豐富化佇列：LinkedIn 查找、目錄研究或電話 |
| 無郵件，無網站 | 如果商家是高價值，路由到電話推廣佇列 |
| 現有 CRM 聯絡人 | 在寄送前與 CRM 比對；如果已在序列中或已關閉為客戶，則抑制 |
| 沒有本地老闆聯絡人的特許或連鎖 | 路由到研究佇列：特許目錄、州商業登記、LinkedIn |
硬退信和被拒絕信箱的抑制是永久性的。永遠不要將抑制的地址重新添加到活躍行銷活動中。
根據本地類別調整工作流程。
抓取、驗證和寄送的路徑保持不變。路由規則因類別而變化，因為郵件模式隨之改變。
餐廳郵件驗證
處理預訂收件匣、餐飲郵件、連鎖店和高流轉率清單。
牙科診所郵件驗證
分離前台、預約、診所和企業牙科集團記錄。
律所郵件驗證
路由諮詢收件匣、律所級地址、泛網域和命名律師。
屋頂承包商郵件驗證
清理包含個人郵件、服務收件匣和過時網站的承包商清單。
水管工郵件驗證
路由辦公室、調度、個人、無郵件和加盟管道記錄。
房產郵件驗證
在發送前清理仲介、團隊、仲介公司、流失和共用辦公室記錄。
多門市業務驗證
對分支機構記錄、重複網域、共用電話和企業收件匣進行去重複。
常見工作流程問題。
Google Maps 是否在其匯出資料中包含郵件地址？
不包含。Google Maps 匯出包含商家名稱、地址、電話號碼、評分和網站 URL。郵件地址不是清單資料的一部分。郵件探索通過爬取連結網站上的聯絡地址單獨執行。
BillionVerify 在此工作流程中的位置是什麼？
BillionVerify 位於郵件探索和冷郵件寄信工具之間。你在將探索到的郵件匯入任何寄送工具之前先進行驗證，這可以防止原始抓取地址在沒有品質檢查的情況下進入寄信工具。
Google Maps 匯出的驗證通過率預期是多少？
典型的 Google Maps 本地商家抓取根據垂直市場產生大約 40 到 70% 的郵件覆蓋率（來自探索）。在這些探索到的郵件中，大約 50 到 70% 驗證為可投遞且有確認的信箱。另外 15 到 30% 返回全收型風險。其餘是無效的。最終可寄名單通常是原始記錄數的 25 到 50%。計劃名單會比原始匯出建議的更小。
我應該向 Google Maps 匯出的全收型地址寄送嗎？
應該寄送，但要分開且量較小。許多小型商家預設從其託管設置執行全收型配置，而不是因為它們通過死路由路由聯絡。將全收型地址包含在獨立的分類中，每個網域限制寄送量，在第一次寄送後監控退信行為，並抑制任何退信的地址。
像 info@ 或 booking@ 這樣的角色型地址值得包含嗎？
值得，但需要適當處理。這些是真實商家的真實信箱。它們與具名聯絡人不同，但不是無效的。將它們保留在獨立的分類中，使用承認共用信箱背景並給出轉發或回覆理由的文案。不要將它們混入為具名聯絡人設計的序列中。
如何防止從多地點抓取中向相同商家寄送兩次？
在驗證執行之前在三個層級去重：精確郵件地址、郵件網域和品牌名稱。對於許多地點共用企業網域的特許和連鎖記錄，應用品牌層級去重，使一次寄送對應一個品牌，而不是每個地點一次寄送。
完整工作流程需要多長時間？
使用每個步驟的工具，200 到 500 條記錄的名單大約需要兩到四個小時。抓取需要 15 到 30 分鐘。郵件探索需要 30 到 60 分鐘。清洗和去重需要 30 到 60 分鐘。BillionVerify 驗證對大多數批次大小在幾分鐘內完成。行銷活動配置需要另外 30 到 60 分鐘。超出此範圍的高價值記錄的手動研究會增加時間。
向已驗證的 Google Maps 名單寄送後，預期退信率是多少？
一個良好驗證的 Google Maps 名單應該產生低於 2% 的硬退信率。如果你在已驗證的寄送中看到超過 3 到 5% 的硬退信，請審查上游步驟：郵件探索可能在網站的當前版本上找到不存在的地址，你的全收型分類可能比預期更大，或者名單可能比看起來更舊。超過 5% 的硬退信會影響網域聲譽並需要立即採取行動。