ローカルビジネスデータ、つまりGoogle Mapsやディレクトリに掲載されるすべてのビジネスの背後にある名前、住所、電話番号、営業時間、カテゴリ、評価、ランキングは、驚くほど多くの業務を支えている。ローカルSEOのランキング追跡、B2Bリードリスト、市場調査、掲載情報の検証、レピュテーションモニタリングなどだ。しかし、その収集のほとんどを静かに破綻させる落とし穴がある。ローカルデータは場所によって配信されるという点だ。Google Mapsがシカゴの検索者に表示する内容は、ベルリンの検索者に表示する内容とは異なり、あるビジネスがローカルパックで保持するランキングも都市ごとに異なる。
この一点が、ローカルデータの収集をアクセスの問題に変えてしまう。データセンターIPや単一のオフィスの場所からMapsやディレクトリをスクレイピングしようとすると、ブロックされたり、CAPTCHAを求められたり、さらに悪い場合には他の誰かのローカル結果を渡され、それが真実だと告げられたりする。ここで登場するのがレジデンシャルプロキシだ。これを使えば、実際にその都市にいるユーザーが目にするとおりのローカルビジネスデータを収集できる。データを正しく取得できる方法はこれしかない。以下では、その仕組みと重要性を説明する。
「ローカルビジネスデータ」が実際に指すもの
本質的には、人々がローカルビジネスを見つける各種のプラットフォーム全体で、ビジネス掲載情報とそのシグナルを体系的に収集することを指す。
- 地図・掲載プラットフォーム：Google Mapsやビジネスプロフィール、さらに広範なディレクトリのエコシステム。名前・住所・電話番号（NAP）、営業時間、カテゴリの主要な情報源となる。
- ローカル検索結果：「近くの」検索や都市を指定したクエリで表示されるローカルパックや地図結果。ここでローカルランクが決まる。
- 評価とレビュー：レピュテーションとランキングを左右する星評価、レビュー数、レビュー本文。
- 属性とリッチデータ：写真、混雑時間帯、サービスオプション、カテゴリタグ。
チームはこれを、ローカルSEOとランク追跡（あるビジネスは都市ごとのパック内でどの順位にあるか）、リードジェネレーション（カテゴリとエリアを絞ったビジネスのリスト作成）、競合・市場調査（各市場における競争の密度）、NAP検証とデータエンリッチメント、複数拠点のレピュテーションモニタリングなどに利用する。これらすべては実際のローカル検索者が本当に目にするものを捉えることにかかっている。そして、その検索者が何を目にするかは、どこから検索しているかに完全に依存する。
なぜこれがプロキシの問題なのか
ローカルデータには3つの特性があり、それによってその収集はまさにプロキシ層の問題になる。
ローカル結果は都市単位で地理的に配信される。 これが最大の要因だ。地図のランキング、ローカルパック、「近くの」検索結果は、検索者の物理的な位置に基づいて計算される。ある地域で1位のレストランが、数都市離れた場所ではまったく表示されないこともある。収集をすべて一つの場所から行うと、ある一都市のローカル結果だけを測定し、それを普遍的なものとして扱ってしまうことになる。これは他のすべての市場にとって単純に誤ったデータだ。ある都市におけるビジネスの真のローカルランクを見るには、その都市から問い合わせる必要があり、これこそ都市レベルのターゲティングが存在する理由だ。ディレクトリはさらにその上に独自の地域パーソナライゼーションを重ねている。
これらの情報源は厳重に防御されている。 Mapsや主要なディレクトリは積極的なボット対策システムを運用している。データセンターIPは一目でフラグを立てられ、CAPTCHA、ブロック、あるいは簡略化された結果を返される。その結果、記録されるのは掲載情報のボット版であり、本物ではない（その仕組みについてはスクレイパーがブロックされる理由で解説している）。レジデンシャルIPは実際のユーザーとしての信頼性を備えているため、実際の人が得るのと同じ完全で本物のローカル結果を目にすることができる。
カバレッジは広範かつ繰り返しが必要になる。 多数のビジネス、カテゴリ、クエリを多数の都市にわたって時間をかけて追跡するには、大量のリクエストが必要になる。少数のIPだけを使うとレート制限に引っかかり、部分的で偏ったサンプルしか得られず、しかも情報源が最も厳重に守っている高価値なクエリほど取得できなくなる。大規模なローテーティングプールこそが、カバレッジを完全に保つ鍵となる。
この3つすべてに対する解決策は同じだ。各対象都市に実際に物理的に存在する実ユーザーのように見えるIPから収集することだ。
レジデンシャルプロキシが果たす役割
レジデンシャルプロキシは、リクエストを実際の消費者IPを経由させることで、Mapsやディレクトリがあなたに対して本物のローカルユーザーへ応答するのと同じように応答するようにする。ローカルビジネスデータに特化して言えば、これによって次のことが可能になる。
遠隔からの近似ではなく、本物のローカル結果。 都市単位までのジオターゲティングを使えば、その都市にいるユーザーとしてローカルパックや地図結果を問い合わせることができ、取得するランキング、掲載情報、「近くの」結果は実際の地元の人々が目にするものと同じになる。これが、クライアントに請求できるローカルランクレポートと単なる推測との違いだ。
ボット版ではなく、本物の掲載情報。 レジデンシャルIPは実ユーザーとしての信頼性を持つため、不審なトラフィックに対して提供される劣化版やブロックされたページではなく、完全なビジネスプロフィール、評価、営業時間、属性、レビュー数を取得できる。
すべての市場を網羅する完全なカバレッジ。 大規模なローテーティングプールがリクエストを分散させるため、ブロックされることなく多数の都市にわたって多数のビジネスを継続的に追跡でき、ローカルデータセットをまばらではなく完全な状態に保てる。（これはデータ収集のためのレジデンシャルプロキシと同じ収集品質の原則であり、密接に関連するローカライズされたGoogle検索結果とも組み合わせられる。）
簡単に言えば、レジデンシャルプロキシは「たまたま自社のオフィスから見えたローカル結果」を「関心のあるすべての都市で実際の顧客が目にするローカル結果」へと変えてくれる。
仕組み
Shifterのゲートウェイでは、プロキシのユーザー名に都市名をエンコードするだけで都市を選択できる。エンドポイントは一つだけで、管理すべきIPリストは存在しない。
# シカゴにいる検索者としてローカル結果を収集するcurl -x customer-USERNAME-country-us-city-chicago:PASSWORD@p.shifter.io:443 https://maps-or-directory.example
# 同じビジネスカテゴリで、別の市場の場合curl -x customer-USERNAME-country-de-city-munich:PASSWORD@p.shifter.io:443 https://maps-or-directory.example不良データを避けるための原則は次のとおりだ。クエリの対象地域とプロキシの地域を一致させる。 シカゴの結果をリクエストするなら、シカゴのレジデンシャルIPを経由させる。ある都市の結果を別の都市のIPから要求してはならない。そうしないと、プラットフォーム自体の位置情報がクエリと矛盾し、ランキングが意味をなさなくなる。複数ステップの結果をページ送りする際はスティッキーセッションを維持し、一連の操作が一人のユーザーに見えるようにする。次の都市やビジネスに移る際はプール全体でローテーションする。ゲートウェイは同じでも、リクエストごとにターゲティングを変え、構築済みの収集パイプラインへ供給する。（時々ではなく一貫してブロックされる場合は、地理ではなくIPの品質やリクエストの挙動が原因なので、スクレイピングでブロックを避ける方法を参照してほしい。）
責任を持って利用する
ローカルビジネスデータの多くは公開情報であり、検索者なら誰でも見られる掲載情報、営業時間、評価だ。これは確かな基盤ではあるが、責任を持って収集する必要がある。公開されているビジネス情報を収集し、各プラットフォームの利用規約とレート制限を守り、問い合わせ先のサービスを劣化させないようにし、個人データからは距離を置くこと。レビュアーの身元やレビューに付随する個人情報は対象外だ。プロキシが変えるのはリクエストがどのIPから発信されるかであり、そのリクエストを行うべきかどうかではない。Shifterで許可されている内容については、利用規約が正式な基準となる。
FAQ
Google Mapsやローカルディレクトリをスクレイピングするのに、なぜプロキシが必要なのか？ ローカル結果は物理的な位置に基づいて配信され、これらのプラットフォームは厳重に防御されているためだ。一つの場所やデータセンターIPからでは、一つの都市の結果（あるいはブロック/CAPTCHAされたバージョン）しか見えない。レジデンシャルプロキシを使えば、各対象都市の実ユーザーとして問い合わせることができ、収集するランキングや掲載情報が本物のローカルデータになる。
ローカルランキングは都市によってそれほど変わるものなのか？ その通りだ。ローカルパックと地図のランキングは検索者の位置に基づいて計算され、あるビジネスは自分の都市では1位でも、数都市離れると表示されないこともある。一つの場所だけから測定すると、その都市の答えしか得られず、他のすべての場所については誤った実態を示してしまう。
この方法でどのようなローカルデータを収集できるのか？ ビジネス名、住所、電話番号、営業時間、カテゴリ、評価とレビュー数、属性、ローカルパック/地図のランクなど、場所によって変化する公開の掲載情報シグナルであれば、都市レベルでのレジデンシャル収集の恩恵を受けられる。
ローカルデータには、レジデンシャルプロキシとデータセンタープロキシのどちらを使うべきか？ レジデンシャルだ。MapsやディレクトリはデータセンターIPを検出し、異なる扱いをするため、データセンタープロキシを使うとブロックされたり簡略化された結果しか得られない。レジデンシャルIPなら、本物のローカル検索者が目にするのと同じ、地理的に正確な掲載情報とランキングを見ることができる。
ローカルビジネスデータのスクレイピングは合法なのか？ ローカルの掲載情報は公開されており、収集は一般的に公開データを対象とするため、責任を持って行う（利用規約とレート制限を守り、レビュアーの身元などの個人データを避ける）限り、おおむね問題ない。プロキシは根底にある行為の合法性を変えるものではない。不確かな点については法的助言を求めてほしい。
結論
ローカルビジネスデータは、実際のローカル検索者が本当に目にするデータでなければ意味がない。そしてMapsやディレクトリは物理的な位置に基づいて結果を配信し、ボットに対して厳重に防御しているため、一つのオフィスのIPから収集すると、一つの都市の答えを真実のように装って手に入れることになる。正しく行うには、各対象都市の実ユーザーとして問い合わせる必要があり、これこそレジデンシャルプロキシが提供するものだ。本物のローカルランキングと掲載情報、ボット版ではない完全な本物のプロフィール、そしてブロックされることなくすべての市場をカバーする完全なカバレッジである。
チームがローカルSEO、リードジェネレーション、複数拠点のモニタリングを行っているなら、都市レベルのターゲティングを備えた高品質なレジデンシャルプロキシネットワークこそが、ローカルの実態を近似ではなく正確なものにする鍵となる。プールの品質がそのカバレッジの完全さを左右するため、評価の際にはIPレピュテーションについて理解しておく価値がある。価格ページには、あなたにとって重要な都市やカテゴリを対象に試すためのGB単位のプランが掲載されている。