Google Maps 给你的是商家记录，不是可直接发送的邮件名单。
Google Maps 导出包含商家名称、地址、电话、评分和网站 URL，不包含邮箱地址。从 Maps 导出到正式冷邮件活动之间，需要经历几个不同的步骤，每个步骤都会改变数据的形态和风险状况。
跳过或压缩任何步骤，就是投递问题的开始。从 Google Maps 抓取的商家数据看起来干净，但通常并非如此。理解每个阶段发生了什么，以及坏数据在哪里进入管道，是让活动顺利运转与损害发件域名之间的差别所在。
此工作流需要的输入字段
在工作流开始前，确认你的 Maps 导出包含以下字段。每个字段都在后续步骤中使用。
| 字段 | 为什么需要 | 缺失时的处理 |
|---|---|---|
| 商家名称 | 个性化和去重 | 必填；若缺失则重新抓取或丰富 |
| 网站 URL | 邮件发现的起点 | 无 URL 的记录无法生成邮箱；单独路由 |
| 地址 | 去重和位置定向 | 用于识别共享地址的重复项 |
| 电话号码 | 辅助去重信号 | 当域名或邮箱去重无法捕获所有重复时使用 |
| 评分和评价数 | 商家规模和活跃度的资质信号 | 可选；用于优先级排序 |
| 商家类别 | 发送前的分段 | 帮助将记录路由到合适的序列 |
| 来源 URL 或列表 ID | 可追溯性和去重 | 帮助识别两条记录下的同一商家 |
没有网站 URL 的记录无法通过标准发现产生邮箱。将它们保留在单独的无邮箱队列中，用于电话推广或手动研究。
验证前先清洗
在上传至 BillionVerify 之前运行清洗步骤，验证在干净的输入上更有效、更准确。
- 从主动邮件工作流中删除无网站 URL 的记录，将其路由到电话或研究队列。
- 识别所有网站 URL 都指向同一企业域名的连锁和多地点记录。这些会产生重复或企业级邮箱，在发现运行前在品牌层面去重。
- 对剩余记录运行邮件发现，通过爬取每个网站寻找 mailto 链接、联系页面和页脚文本。
- 规范化邮箱列：所有地址转为小写，去除空格，修复明显的格式错别字。
- 删除已知非推广域名的邮箱：预订平台地址、预约服务域名，以及以商业联系邮箱形式出现的支持平台地址。
- 先按精确邮箱地址去重，然后按域名去重。如果三条以上记录共享同一域名，调查它们是不是不同联系人还是同一收件箱多次出现。
- 标记邮箱域名与商家网站域名不匹配的记录。这些可能通过母公司或遗留设置路由。
清洗后，你的名单比原始导出更小。这是正确的。向清洗后的名单发送，比向完整的原始数量发送产生更好的效果。
验证邮箱列
这是 BillionVerify 进入工作流的地方。上传清洗后的邮件名单并运行完整验证。
- 将清洗后的邮箱列上传至 BillionVerify。
- BillionVerify 检查域名级 MX 记录，确认邮件服务器已配置并在线。
- BillionVerify 运行 SMTP 握手检查，确认具体邮箱是否接受邮件。
- BillionVerify 标记 Catch-all 域名——服务器无论具体邮箱是否存在都接受所有邮件。
- BillionVerify 识别角色邮箱前缀（info@、office@、service@、contact@、appointments@、booking@、intake@）并与具名地址分开标记。
- BillionVerify 为每条记录返回结果：有效、无效、Catch-all、角色邮箱、有风险或未知。
- 以邮箱地址为连接键，将验证结果列合并回原始记录。
不要跳过合并步骤。验证结果只有附加到完整记录上才有用，这样才能在记录层面而非仅邮箱层面做出路由决策。
对每个验证结果进行路由
BillionVerify 的每个结果都应产生明确的操作。不改变管道下一步行为的验证，就是白做的验证。
| BillionVerify 信号 | 管道操作 | 原因 |
|---|---|---|
| 有效的具名商业邮箱 | 加入主发送序列 | 可达；地址属于特定个人或具名账户 |
| 有效的角色邮箱（info@、office@、booking@、intake@） | 加入共享收件箱分段 | 有效但不是具名联系人；需要不同的文案和路由 |
| Catch-all 域名 | 加入有数量限制的谨慎分段 | 域名接受所有邮件；具体收件箱不确定 |
| 无效（语法错误、域名失效、无 MX 记录） | 抑制 | 从所有发送队列中永久删除 |
| 被拒绝的邮箱 | 抑制 | 即使域名活跃，该具体地址也不存在 |