Google Maps 给你的是商家记录，不是可直接发送的邮件名单。
Google Maps 导出包含商家名称、地址、电话、评分和网站 URL，不包含邮箱地址。从 Maps 导出到正式冷邮件活动之间，需要经历几个不同的步骤，每个步骤都会改变数据的形态和风险状况。
跳过或压缩任何步骤，就是投递问题的开始。从 Google 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 记录） | 抑制 | 从所有发送队列中永久删除 |
| 被拒绝的邮箱 | 抑制 | 即使域名活跃，该具体地址也不存在 |
| 未知或有风险 | 发送前先审查或丰富 | 没有额外确认时不要大批量发送 |
此路由表应内置到你的导入步骤或活动工具配置中，不要依赖每次新的 Google Maps 导出通过工作流时人工记忆操作。
构建发送序列
路由之后，每个分段进入为其风险和联系类型配置的发送序列。各分段不应共享同一序列。
| 分段 | 序列方式 | 关键设置 |
|---|---|---|
| 有效的具名邮箱 | 主序列；按姓名和商家详情完全个性化 | 从这里开始；置信度最高 |
| 有效的角色邮箱 | 共享收件箱序列；文案针对团队或商家而非个人 | 不同的主题行和开场白 |
| Catch-all 邮箱 | 降量序列；首次发送后监控退信行为 | 按域名限制发送量；不要全量发送 |
| 无邮箱记录（有效网站） | 电话或丰富队列；不是邮件序列 | 路由到邮件工具之外 |
域名预热适用于所有分段。如果你从新域名发送，不要同时启动所有分段。先通过具名邮箱分段预热域名，然后加入角色邮箱，最后加入谨慎的 Catch-all。
分别处理角色邮箱和 Catch-all
角色邮箱和 Catch-all 是两个不同的问题，需要分别决策。
| 类型 | 含义 | 操作 |
|---|---|---|
角色邮箱：booking@、catering@ | 由共享或前厅员工监看的收件箱 | 保留；使用提示转发给决策者的文案 |
角色邮箱：intake@、office@ | 共享收件箱；监看情况因企业规模而异 | 保留；优先考虑收件箱直达老板的小型企业 |
角色邮箱：info@、contact@ | 大量通用入站收件箱；较大企业会重度过滤 | 保留在分段中；调低回复预期 |
| Catch-all：看似有效的地址 | 服务器接受所有邮件；具体收件箱存在性未经确认 | 低量发送；如有退信立即抑制 |
| Catch-all：企业或连锁域名 | 所有门店邮箱都路由到同一 Catch-all | 每个品牌最多一条记录；不要每个地点一条 |
来自 Google Maps 商家列表的角色邮箱不是自动无效的。餐厅的 booking@ 或牙科诊所的 appointments@ 是由真实员工监看的真实收件箱。关键问题是，你的文案是否让收件人有理由将其升级给决策者。
抑制和丰富其余记录
验证后的记录进入各自的序列后，剩余记录需要明确的处置方式，不要让它们处于未决状态。
| 记录类型 | 后续步骤 |
|---|---|
| 无效邮箱 | 加入永久抑制名单 |
| 被拒绝的邮箱 | 加入永久抑制名单 |
| 首次发送后退信的 Catch-all | 加入抑制名单；不要重试 |
| 无邮箱但网站活跃 | 路由到丰富队列：LinkedIn 查找、目录研究或电话 |
| 无邮箱且无网站 | 若商家高价值则路由到电话推广队列 |
| 现有 CRM 联系人 | 发送前与 CRM 匹配；若已在序列中或已成为客户则抑制 |
| 无本地所有者联系方式的连锁或加盟商 | 路由到研究队列：加盟商目录、州商业注册、LinkedIn |
对硬退信和被拒绝邮箱，抑制是永久性的。永远不要将已抑制的地址重新加入活跃活动。
按本地类别调整工作流
抓取、验证和发送的路径保持不变，但路由规则会因类别不同而改变，因为邮件模式会变化。
餐厅邮件验证
处理预订收件箱、餐饮邮件、连锁店和高流转率列表。
牙科诊所邮件验证
分离前台、预约、诊所和企业牙科集团记录。
律所邮件验证
路由咨询收件箱、律所级地址、泛域名和命名律师。
屋顶承包商邮件验证
清理包含个人邮件、服务收件箱和过时网站的承包商列表。
水管工邮件验证
路由办公室、调度、个人、无邮件和加盟管道记录。
房产邮件验证
在发送前清理经纪人、团队、中介机构、流失和共享办公室记录。
多门店业务验证
对分支机构记录、重复域名、共享电话和企业收件箱进行去重。
常见工作流问题
Google Maps 的导出数据中包含邮箱地址吗？
不包含。Google Maps 导出包含商家名称、地址、电话、评分和网站 URL，邮箱地址不是列表数据的一部分。邮件发现通过爬取关联网站寻找联系地址单独运行。
BillionVerify 在这个工作流中处于哪个位置？
BillionVerify 位于邮件发现和冷邮件发送工具之间。你在将发现的邮箱导入任何发件工具之前进行验证，防止原始抓取地址未经质量检查就直接进入发件工具。
从 Google Maps 导出应该预期什么样的验证通过率？
典型的 Google Maps 本地商家抓取，根据行业不同，邮件发现阶段约能覆盖 40 到 70% 的记录。在这些发现的邮箱中，约 50 到 70% 能验证为具有已确认邮箱的可投递地址，另外 15 到 30% 返回为 Catch-all 风险，其余为无效。最终可发送名单通常是原始记录数的 25 到 50%。计划好比原始导出所显示的更小的名单。
应该向 Google Maps 导出中的 Catch-all 地址发送吗？
可以，但要单独处理且降低发送量。许多小商家默认从托管设置中运行 Catch-all 配置，并不是在将联系方式路由到死胡同。将 Catch-all 地址放在单独的分段中，按域名限制发送量，首次发送后监控退信行为，并抑制任何退信的地址。
像 info@ 或 booking@ 这样的角色邮箱值得纳入吗？
值得，但要适当处理。这些是真实商家的真实收件箱，不等同于具名联系人，但也不是无效的。将它们放在单独的分段中，使用承认共享收件箱背景并给出回复或转发理由的文案。不要将它们混入为具名联系人设计的序列。
如何防止向来自多地点抓取的同一商家发送两次？
在验证运行前从三个层面去重：精确邮箱地址、邮箱域名和品牌名称。对于许多地点共享企业域名的连锁和加盟品牌，在品牌层面去重，这样每个品牌只发送一次，而不是每个地点发送一次。
完整工作流需要多长时间？
使用每个步骤的工具，对于 200 到 500 条记录的名单，大约需要两到四小时。抓取需要 15 到 30 分钟，邮件发现需要 30 到 60 分钟，清洗和去重需要 30 到 60 分钟，BillionVerify 验证对大多数批次只需几分钟，活动配置需要另外 30 到 60 分钟。对无邮箱或高价值记录的手动研究还需要额外时间。
向经验证的 Google Maps 名单发送后，应该预期什么样的退信率？
经过充分验证的 Google Maps 名单，硬退信率应低于 2%。如果在验证发送中看到超过 3 到 5% 的硬退信，请检查上游步骤：邮件发现可能找到了当前网站版本上并不存在的地址，你的 Catch-all 分段可能比预期更大，或者名单可能比看起来更老。超过 5% 的硬退信会影响域名声誉，需要立即采取行动。