ローカルビジネスリストにはB2Bデータベースエクスポートとは異なる問題があります。クリーニングワークフローはそれを反映しています。
Yellow Pages、Yelp、BBB、Angi、または類似のディレクトリから取得したローカルビジネスメールリストには特定の品質特性があります：
- 共有受信箱の高い割合（
info@、contact@、service@） - 特に小規模ビジネスでの頻繁なキャッチオールドメイン
- 何年も更新されていないリストからの古いアドレス
- 複数のディレクトリに掲載されているビジネスからの重複エントリ
- 多くのリストに欠落しているメール。認証前に発見が必要
ローカルビジネスリストのクリーニングは、無効なアドレスを削除するだけではありません。各アドレスのシグナルタイプを理解し、どのアドレスもキャンペーンに入力される前にそれに応じてルーティングすることです。
ローカルビジネスメール認証フレームワーク
このページでは、1つのディレクトリソースまたはワークフローを説明します。完全なフレームワークでは、ローカルディレクトリのリストからメール発見、認証、配信停止管理までの完全な経路を解説しています。
4段階のローカルビジネスリストクリーニングワークフロー。
ステージ1：収集と統合。
クリーニング前にすべてのソースを1つのファイルに統合します。Yellow Pages、Yelp、BBBを同時にソースとして使用している場合は、重複排除前にリストをマージします。ソースごとにクリーニングすると重複した認証作業が発生し、クロスソースの重複が見逃されます。
メールアドレスのないリストの場合：クリーニング前にメール発見（会社ドメインに対する検索ツール）を実行するか、それらを除外するかを決定します。発見には時間がかかりますが、ディレクトリに掲載されていないアドレスをキャプチャします。
ステージ2：正規化と重複排除。
| 正規化ステップ | 重要な理由 |
|---|---|
| すべてのメールアドレスを小文字に | 大文字・小文字の区別による重複を防ぐ |
| 先頭と末尾のスペースを削除 | 検索ツールの出力と手動入力にはしばしば空白が含まれる |
| ドメイン形式を標準化 | www.example.com と example.com は同じドメイン |
| 不正な形式のエントリを削除 | @ 記号のないアドレス、不完全なドメイン、フォーマットエラー |
| メールアドレスで重複排除 | 複数のソースからの同じアドレスは1回だけ認証すべき |
| ビジネス名とドメインで重複排除 | 同じビジネスの別々のリストはマージすべき |
ステージ3：以前に抑制したアドレスを削除。
認証前に、リストを既存の抑制ファイルと比較します。ディレクトリからソースされたローカルビジネスリストには、以前に連絡したビジネス — バウンスしたビジネス、配信停止したビジネス、またはスパムとしてメッセージをマークしたビジネス — が含まれている場合があります。
抑制されたアドレスを新しいキャンペーンにインポートすることはコンプライアンスリスクと評判リスクです。抑制チェックは認証後ではなく、認証前に行う必要があります。
ステージ4：BillionVerifyで認証。
正規化された、重複排除された、抑制チェックされたリストをBillionVerifyで実行します。出力は各アドレスにシグナルを割り当てます。
ローカルビジネスリストのシグナルのルーティング方法。
| シグナル | ローカルビジネスリストに対する意味 | アクション |
|---|---|---|
| Valid | アドレスは配信可能で役割ベースではない | メインキャンペーンにインポート |
| Invalid | アドレスはバウンスする | 抑制に追加、インポートしない |
| Catch-all | ドメインはすべてのメールを受け入れる。メールボックスの状態は不確実 | 別の低ボリュームキャンペーン |
| Role-based | 汎用共有受信箱 | 別のキャンペーン、調整されたメッセージング |
| Unknown | サーバーの応答が判断不能 | レビューキュー — メインキャンペーンから除外 |
| Risky または Disposable | ビジネスアドレスではない | インポートしない |
クリーニングされたローカルビジネスリストのルーティング構造。
認証済みリスト
→ Valid（役割ベースでない）
→ メインキャンペーン、標準ボリューム
→ Valid 役割ベース
→ 別のキャンペーン、共有受信箱メッセージング
→ Catch-all
→ 低ボリュームセグメント、密接に監視
→ Invalid、Risky、Disposable
→ 抑制ファイル（永久）
→ Unknown
→ レビューキュー（送信前に決定）
シグナルタイプ別のメッセージング考慮事項。
クリーニングワークフローはルーティングで終わりません。ローカルビジネスのアウトリーチでは、シグナルタイプが異なる場合に異なるメッセージングが必要です。
メインキャンペーン（有効、非役割ベース）：標準的なアウトリーチ。ビジネスカテゴリまたは場所によるパーソナライゼーションが可能。連絡先名が利用可能な場合は挨拶にファーストネームを使用。
役割ベース / 汎用受信箱：ファーストネームのパーソナライゼーションなし。読者が不明であるかのように書いてください。件名は関連性を伝える必要があります — 「[名前]さん、こんにちは」のフックはなし。最初の文で誰であるかとどのようなオファーをしているかを説明してください。
キャッチオールセグメント：低ボリューム。可能であれば、全セグメントに送信する前に小さなバッチでテストしてください。最初の24時間の配信率を密接に監視してください。
キャンペーン後の再クリーニング。
キャンペーン後のクリーンアップはクリーニングワークフローの一部です。各送信後に：
- すべてのハードバウンスを抑制に追加
- すべての配信停止を抑制に追加
- 苦情を生成したアドレスを抑制に追加
- バウンスしたキャッチオールアドレスを将来のキャッチオール送信から削除するためにフラグ
Info@ メールフィルタリング
どのローカルビジネスの汎用受信ボックスに送信する価値があるか、またキャンペーンでの処理方法を判断します。
ウェブサイトから取得したローカルビジネスメール
ディレクトリ発見後にローカルビジネスのウェブサイトから見つかったメールを認証します——第2ステップのコンタクト経路。
ローカルビジネスメールリストのクリーニングによくある質問。
ローカルビジネスのメールリストをクリーニングするにはどのくらいの時間がかかりますか？
数千件のレコードのリストの正規化、重複排除、抑制チェックは、スプレッドシートまたは基本的なスクリプトで30〜60分かかります。BillionVerifyはこのサイズのリストの認証を数分で処理します。生のディレクトリデータから認証済みのルーティングされたセグメントまでの完全なクリーニングワークフロー全体で1〜2時間を計画してください。
ローカルビジネスリストの典型的な何パーセントが無効ですか？
無効率はソースとリストの年齢によって異なります。新しくソースされたローカルディレクトリデータの場合：不正な形式のアドレスを削除した後、10〜25%が無効であることを期待してください。古いリスト（ソースから6〜12ヶ月）：ビジネスの変化、閉業、古くなったリストにより無効率が高くなる場合があります。キャッチオールアドレスは通常、ディレクトリのソースに応じてリストのさらに15〜30%を占めます。
異なるローカルカテゴリでリストを異なる方法でクリーニングすべきですか？
はい、可能な場合は。プロフェッショナルサービス（弁護士、会計士、コンサルタント）はより構造化されたメールインフラとより低いキャッチオール率を持つ傾向があります。トレードと業者（配管工、電気技師、HVAC）は個人または汎用アドレスをよく使用し、キャッチオール率が高いです。リストに複数のカテゴリが含まれている場合は、カテゴリごとに適切なボリュームとメッセージングの決定を適用するためにルーティング前にセグメント化してください。
新しいリストの場合、抑制チェックをスキップできますか？
いいえ。新しくソースされたリストでさえ、異なるチャネル、異なるリスト、または以前のキャンペーンを通じて連絡済みのビジネスのアドレスが含まれている場合があります。抑制チェックは、すでにオプトアウトしたビジネスや、メールアドレスがすでにバウンスしているビジネスに再連絡することを防ぎます。リストがどれだけ新しいかにかかわらず、スキップするとコンプライアンスリスクと評判リスクが発生します。
ビジネスがまだ営業しているかどうかを判断できないアドレスの処理方法は？
期限切れのドメインまたはMXレコードのないビジネスは閉業として扱い、抑制に追加してください — 関係なくバウンスを生成します。アクティブなドメインを持つが状態が不確実なビジネスには、認証がシグナルを決定するようにしてください。潜在的に閉業したビジネスの無効なアドレスはキャッチされます。不確かに見えるアクティブなビジネスはvalidまたはcatch-allの結果を返します。