Google Maps 給你商家記錄，而非可寄送的郵件名單。
Google Maps 匯出包含商家名稱、地址、電話號碼、評分和網站 URL，但不包含郵件地址。從地圖匯出到執行中的冷郵件行銷活動的路徑涉及幾個不同的步驟，每個步驟都會改變資料的形狀和風險狀況。
跳過或壓縮任何這些步驟是可達性問題開始的地方。來自 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） | 抑制 | 從所有寄送佇列中永久移除 |
| 被拒絕的信箱 | 抑制 | 即使網域活躍，具體地址也不存在 |