地図から企業データベースを収集するリードジェネレーションエージェンシーやマーケティング担当者は、早かれ遅かれ同じ質問に直面します：10,000件の連絡先を収集するのに実際に「どれくらいの重さ」があるのか、なぜアカウントやIPアドレスが3,000件目でバンされ始めるのか。トラフィックの計算をステップバイステップで解説し、Googleマップ、2GIS、Yandex.Mapsを比較し、どのプロキシがそのようなボリュームをブロックなしで耐えられるかを示します。
地図からのリードジェネレーションとは何か、そしてなぜトラフィックを計算するのか
地図からのリードジェネレーションとは、Googleマップ、2GIS、またはYandex.Mapsを通じて企業の連絡先データ（名称、電話、ウェブサイト、住所、評価、業種）を収集し、その後のコールドコール、メールマーケティング、またはターゲット広告に利用することです。この方法は、B2Bサービスを販売するエージェンシーに特に人気があります：ウェブスタジオ、CRMプロバイダー、マーケティング請負業者などが、ニッチや都市に基づいたデータベースを必要としています：「カザンの歯科医院」、「ノボシビルスクの自動車修理」、「エカテリンブルクの美容院」などです。
トラフィックの計算は、3つの理由から重要です。第一に、送信されるデータの量によって、どれだけのプロキシトラフィックを消費し、複数の都市にスケールアップする際にそれがどれくらいのコストになるかが決まります。第二に、地図はIPだけでなくリクエストの異常な活動を記録します — 10,000件のカードを収集するのにどれだけのリクエストが生成されるかを理解しないと、バンのリスクを過小評価しやすくなります。第三に、データの正確な量を知ることで、HTMLページのパース、地図の内部APIの使用、または既存のサービスの利用の間で簡単に選択できます — 各オプションはトラフィックにおいて大きく異なります。
実際には、10,000社は抽象的な数字ではありません。このボリュームは、例えば、ロシアの15-20の大都市における「技術修理」ニッチの現行法人の完全なデータベース、またはモスクワやサンクトペテルブルクのような大都市の飲食店のすべてを含みます。これは、リードをパッケージで販売するエージェンシーにとって現実的な課題です。
1つの企業カードの重さはどれくらいか
1つの企業カードの重さは、何を収集するか、どのように収集するかによって異なります。検索結果のリスト（名称、簡略住所、評価）のみをパースする場合、データはコンパクトに送信されます — 通常、これは1社あたり3-8KBの重さのJSONレスポンスで、全体のリストの一部です。しかし、詳細なカードが必要な場合 — 電話、ウェブサイト、営業時間、写真、レビュー — 別のページを開くか、追加のリクエストを行う必要があり、その重さは画像や拡張JSONによって80-250KBに増加します。
以下は、CISのリードジェネレーションエージェンシーが使用する3つの主要な地図の比較です：
| 地図 | リスト内のカードの重さ | 詳細カードの重さ | 保護の特徴 |
|---|---|---|---|
| Googleマップ | 5-8KB | 150-250KB | 厳しいレート制限と頻繁なリクエストによるキャプチャ |
| 2GIS | 3-6KB | 80-150KB | カタログAPIへのリクエスト頻度によるブロック |
| Yandex.Maps | 4-7KB | 100-200KB | 行動分析とプロキシブラックリストを使用したアンチボットシステム |
重要なポイント：リストの重さは、カード全体の重さではありません。企業の電話番号やウェブサイトを取得するには、ほとんどの場合、詳細ページへの別のリクエストが必要です。これは、単に名称を収集するのではなく、販売用の完全な連絡先を収集する場合、リードあたりの実際のトラフィックを倍増させるか、場合によっては3倍にします。
10,000社のトラフィック計算をステップバイステップで
現実的なシナリオを考えましょう：エージェンシーは、Googleマップから10,000社の完全なカード（名称、電話、ウェブサイト、住所、評価、カテゴリ）を収集します。
ステップ1. 検索とリスティング。 Googleマップは、1ページあたり約20件の結果を返します。10,000件のポジションを取得するには、約500ページの結果を処理する必要があります。各ページは、サービスリクエスト、地図の読み込み、スクリプトを考慮して600-900KBの重さがあります。合計：500 × 750KB ≈ 375MBが検索段階でのトラフィックです。
ステップ2. 詳細カード。 10,000社それぞれに電話、ウェブサイト、写真を含む別のリクエストが必要です。カードあたりの平均重さが180KBの場合：10,000 × 180KB ≈ 1.8GBです。
ステップ3. 再リクエストとリトライ。 実際の条件下でのパースでは、10-20%のリクエストがレート制限、キャプチャ、またはレイアウトの変更により最初の試行で通過しないため、再試行が必要です。ボリュームに15%を追加します：（375MB + 1.8GB）× 1.15 ≈ 2.5GBです。
最終的な数字は、Googleマップから10,000社を収集するための2.5GBのトラフィックです。電話番号やウェブサイトなしでリストのみを収集する場合、トラフィックは450-500MBに減少しますが、そのようなデータベースは販売にはあまり適していません — 電話なしではリードはコールに変換されません。
2GISとYandex.Mapsの計算も同様ですが、APIのよりコンパクトな形式のおかげで、ボリュームは通常20-30%低くなります — 同じ10,000件のカードに対して1.7-2.2GBを見込んでください。
なぜ地図はデータの大量収集を禁止するのか
地図はプラットフォーム自体の商業資産であり、大量の自動データ収集は彼らのビジネスモデル（カード内の広告販売、パートナーへのAPIアクセス）に直接反します。したがって、Googleマップ、2GIS、Yandex.Mapsは、異常な行動に対して同様に攻撃的に反応します。
主なブロックのトリガーは、1つのIPからのリクエストの頻度が高すぎること（2-3秒あたり1リクエスト以上）、同一のUser-Agentとヘッダーの変動がないこと、クッキーやセッションデータの欠如、通常のブラウザが常に読み込むリソース（画像、スクリプト）なしのリクエストです。制限に達すると、サービスはキャプチャを表示するか、IPを15-60分間一時的にブロックするか、再度違反があった場合にはIPを永久にバンします。
計算されたボリュームが2.5GBで、10,000件以上のリクエストが1つの「クリーン」IPから行われる場合、バンの可能性は最初の1,000件で100%に近づきます。したがって、地図からのリードジェネレーションのいかなる真剣なプロジェクトもIPアドレスのローテーションを中心に構築されます — これなしではトラフィックの計算は意味を失います。なぜなら、計画されたボリュームを物理的に収集することができないからです。
地図パース用のレジデンシャル、モバイル、データセンタープロキシ
プロキシの種類の選択は、ブロックされるまでにどれだけのリクエストを行えるか、再試行のためにどれだけのトラフィックを「燃やす」必要があるかに直接影響します。地図からデータを収集する際には、IPの評判が重要です — 地図はデータセンターの範囲を厳しくバンします。なぜなら、そこから自動パースの大部分が発生するからです。
| プロキシの種類 | 地図の信頼レベル | いつ使用するか |
|---|---|---|
| レジデンシャルプロキシ | 高い — 実際のユーザーのIP | 都市ごとのローテーションで5,000-50,000件のカードを収集するための主要なツール |
| モバイルプロキシ | 非常に高い — 事業者の一般的なIP | 厳しいアンチボット保護のあるニッチごとの収集 |
| データセンタープロキシ | 低-中程度 — ブラックリストに載ることが多い | テストスクリプトの小規模な実行、実際のデータのエクスポートなし |
実際には、計算された10,000社に対して最適な組み合わせは、レジデンシャルプロキシを都市のサブネットごとにローテーションすることです：ターゲットオーディエンスと同じ地域からIPを取得し、キャプチャや再リクエストの割合を減らします。データセンタープロキシは、50-100件のカードでスクリプトをテストする段階でのみ使用することができます。レジデントトラフィックの予算をデバッグに消費しないようにするためです。
データ収集の設定：ツールとステップバイステップのスキーム
地図から企業データベースを収集するために、エージェンシーは通常、ノーコードやローコードのツールを使用し、ゼロからパーサーを書くことはありません。人気のあるソリューションには、A-Parser（Googleマップ、2GIS、Yandex.Maps用のテンプレートの柔軟な設定）、Octoparse（収集シナリオのビジュアルコンストラクター）、ZennoPoster（プロキシとアンチデテクトプロファイルをサポートする自動化テンプレート）があります。小規模なボリュームには、カードの収集に対して課金されるクラウドサービスが適しています。
10,000社の収集を開始するためのステップバイステップのスキームは次のようになります：
- リードが必要な都市とニッチのリストを決定します — これが検索リクエストの数を設定し、上記のセクションの式に基づいてトラフィックをより正確に予測できます。
- パーサーに、5-10リクエストごとにIPをローテーションするレジデンシャルプロキシのリストを設定します — ほとんどのツールは、ログイン:パスワード@ホスト:ポート形式のプロキシリストをサポートしています。
- リクエスト間に3-7秒のランダムな遅延を設定し、User-Agentのローテーションを有効にします — これにより、固定間隔と比較してキャプチャの割合が30-40%減少します。
- 100-200件のカードでテスト実行を開始し、実際のトラフィック消費を記録します — 計算されたものと比較して、全体のボリュームに対する予測を調整します。
- 収集を10,000件のカードにスケールアップし、1,000-1,500件のバッチに分けてタスクを分割します — これにより、エラーの管理と失敗時の再実行が簡素化されます。
- 結果をCSVにエクスポートするか、重複を電話番号とウェブサイトで削除してCRMに直接エクスポートします — 地図上では、ネットワーク組織や支店のために重複が頻繁に発生します。
収集タスクが定期的に繰り返される場合（例えば、ニッチの月次データベースの更新）、常にレジデンシャルIPのプールで自動実行をスケジュールすることを設定する意味があります — これにより、手動での再起動の時間を節約し、時間を通じて負荷を均等に分配することでバンのリスクを減らします。
リードを失うことなくトラフィック消費を減らす方法
計算された2.5GBの10,000社のトラフィックは、データの質を損なうことなく30-40%削減できます。いくつかの実用的なテクニックを適用すれば可能です。
第一に、リクエストレベルで画像の読み込みをオフにします — 店舗の写真は詳細カードの重さの半分を占めることがありますが、販売には必要ありません。第二に、ブラウザでページを完全にレンダリングするのではなく、地図の内部APIへの直接リクエストを使用します — これにより、役に立たないデータを持つ余分なスクリプト、スタイル、フォントを排除できます。第三に、詳細カードのパース前に重複をフィルタリングします：同じ都市の別の地区で企業がすでに見つかっている場合、そのページへの再リクエストは行わないでください — リスト段階で名称と住所を照合します。第四に、最初にすべての都市の軽量リストを収集し、評価やカテゴリでフィルタを通過した企業の詳細カードのみをリクエストします — これは、10,000件すべてではなく、関連性の高い上位30%のみが必要な場合に特に有用です。
これらのテクニックは、トラフィックのボリュームだけでなく、地図のサーバーへのリクエスト数も減少させ、したがってブロックのリスクも減少させます。エージェンシーにとって、これは同じ料金でプロキシトラフィックの消費を低下させ、同じ予算でより多くの都市を収集する可能性を意味します。
地図からリードを収集する際の一般的な間違い
最初の間違いは、ローテーションなしで1つの静的IPから収集を開始することです。リクエストの速度がわずかであっても、地図は200-300件の連続リクエスト後に異常な活動を記録し、IPを変更しない限り、さらなる収集が不可能になります。
第二の間違いは、プロキシとターゲット都市の地域的一致を無視することです。カザンの企業を他の国のIPを通じて収集する場合、地図は関連性のない結果を表示するか、疑わしいリクエストとして即座にブロックすることが多くなります。
第三の間違いは、実行前にトラフィックの計算を行わないことです。チームはしばしば「目分量」で収集を開始し、タスクの途中でプロキシトラフィックの制限に達し、セッションの中断により既に収集されたデータを失います。
第四の間違いは、リアルタイムでの重複排除なしで収集することです。複数の重複するリクエスト（例えば、同じ地区で「カフェ」と「レストラン」）に対して10,000件のポジションをパースする場合、重複はデータベースの15-25%を占めることがあり、これが計算されたトラフィックと実際のコストを人工的に引き上げます。
第五の間違いは、セッションのすべてのリクエストに対して同じUser-Agentとヘッダーを使用することです。地図のアンチボットシステムはIPだけでなく、ブラウザのデジタルフィンガープリンティングの一貫性も分析します。したがって、大量のデータを扱う場合は、プロキシのローテーションをアンチデテクトブラウザと組み合わせ、IPと共にフィンガープリントを変更することが推奨されます。
結論
地図から10,000社を収集することは、トラフィックに関して予測可能なタスクです：Googleマップからの詳細カードのパースでは、再リクエストを考慮して約2.5GBの消費があり、2GISとYandex.Mapsでは20-30%低い数値です。この数字を事前に知っておくことで、プロキシトラフィックの予算を正確に計画し、収集が途中で制限に達して中断される状況を避けることができます。
成功する収集の主な要因は、トラフィックの節約ではなく、プロキシの正しい選択です。数千件のカードを日々収集するボリュームには、都市ごとのローテーションを伴うレジデンシャルプロキシを推奨します — これにより、キャプチャや再リクエストの割合が減少し、15-20%のトラフィックを消費します。特に厳しいアンチボット保護のあるニッチで収集を行う場合は、主要なプールにモバイルIPを追加することを検討すると、コストの最小限の増加でセッションの安定性が向上します。