モバイルアプリのデータは一見単純に見える。あるアプリには順位、評価、価格、説明文がある。ところが同じアプリを別の国からチェックすると、これらの数値はすべて異なる。モバイルストアは単一のカタログではないからだ。それらは一連の国別ストアフロントの集合であり、それぞれが独自のランキング、独自の価格、独自の提供状況、そして独自の言語による独自のレビューを持っている。自分のオフィスから見えるものは100以上あるストアフロントのうちの一つに過ぎず、それを世界全体の姿として扱うことが、モバイル市場インテリジェンスにおける最もよくある間違いだ。
これにより、アプリストアのデータ収集はスクレイピングの問題である前に、地理の問題となる。以下では、チームが何を収集するのか、どのストアフロントにたどり着くかがリクエストの発信元に見える場所によってどう決まるのか、そしてレジデンシャルプロキシがどのようにして各市場をローカルユーザーとして読むことを可能にするのかを説明する。
モバイルチームが収集するもの
有用なデータはいくつかのグループに分けられる。まず順位だ。カテゴリ別および総合チャートにおけるアプリの位置、そして特定のキーワードでのストア内検索での順位で、どちらもストアフロントごとに計算され、日々変動する。次にメタデータ、すなわちタイトル、サブタイトル、説明文、スクリーンショット、リリースノートで、これらは市場ごとにローカライズされており、競合他社が各地域でどのように自社を位置付けているかを理解するための生の材料となる。そして価格、有料アプリの価格やアプリ内課金の階層を含み、これらは単一の数値をその時点の為替レートで換算したものではなく、市場と通貨によって異なる。
提供状況は、想像以上に重要だ。あるアプリが特定の国では単純に掲載されていないということがあり得る。パブリッシャーの選択によるものであれ、規制上の要件によるものであれだ。競合がどこに存在し、どこに存在しないかを知ることは、それ自体が戦略的シグナルとなる。評価とレビューがこれを補完する。スコアもレビュー本文もストアフロントごとに固有であり、ある市場での不満は別の市場での不満とはまったく異なることが多い。これらすべての周辺には、リリースの頻度や編集による特集掲載、つまり誰がアップデートを出荷し誰が特集されているかの記録があり、これもまた国ごとに異なる。
なぜ表示されるストアフロントはIPによって決まるのか
両方のストアはユーザーを国別ストアフロントへとルーティングする。このルーティングは主に接続の発信元がどこに見えるかによって決まり、デバイスのロケールによって強化され、ウェブエンドポイントでは明示的な国パラメータによっても補強されるが、これらのパラメータが実際のローカルユーザーが目にするすべてをカバーするとは限らない。実際上の効果として、ある国からのリクエストは、あなたが尋ねたすべての問いに対してその国の答えを返す。順位も、価格も、提供状況も、レビューもだ。
したがって、単一の場所から収集する限り、いくら多くのアプリをカバーしても得られるのは一つのストアフロントの姿にすぎない。ドイツのランキングから日本のランキングを推測することはできないし、あるアプリが利用可能な市場を見て、別の市場でそのアプリが利用できないことを知ることもできない。あるストアフロントを読み取るには、リクエストがその内部から発せられる必要がある。
国ターゲティングを備えたレジデンシャルプロキシはまさにこれを行い、読み取りたいストアフロントを持つ市場に各リクエストを配置する。これは、地域によって異なる公開データにアクセスするために使われるのと同じ正当なジオターゲティングだ。ここで注意すべきは、小売や旅行の事例とは異なる点で、アプリストアフロントは国単位なので、ここでは国ターゲティングが適切な粒度であり、市区町村レベルのターゲティングは通常何も付加しない。提示する言語やロケールを、実際に出口となる国に一致させることで、ストアフロントはローカルユーザーが実際に読むローカライズされたメタデータを返すようになる。
規模: アプリ数 × 国数 × 日次
この作業における量は、単一の重いクエリからではなく、掛け算から生じる。数百のアプリを30から40のストアフロントにわたって追跡し、毎日更新し、その上にキーワード順位チェックを重ねると、リクエスト数は積み上がり、あまりに少ないアドレスから発信すればIPごとのレート制限にすぐに達してしまう。ストアのエンドポイントは積極的にスロットリングを行い、スロットリングされたレスポンスは単なる遅延ではなく、後から埋め合わせることのできない日次時系列データの穴となる。
答えは分散だ。チェックをプール全体に分散させることで、各アドレスは制限内に収まりながら合計スループットは拡大する。これはあらゆる高ボリュームの収集システムの背後にあるロードバランシングのロジックであり、無制限の同時接続数が存在する理由でもある。実際にどの程度の分散が必要になるか気になる場合は、その理屈が実際に必要なプロキシIPの数で解説されており、要約すると、それはプールの見出し上の数字ではなく、ストアフロントごとのリクエストレートに依存するということだ。
本物のストアフロントを取得する
ストアのウェブエンドポイントは防御されており、データセンターのアドレス範囲は、それらに対する自動収集が絶えず行われているために厳しく扱われる。フラグの立ったアドレスから返ってくるものは、多くの場合、明確なブロックではなく、データ品質にとってさらに悪いもの、すなわちスロットリングされたレスポンス、汎用ページ、あるいはデータのように見えて実はそうでない部分的な結果だ。これが対策すべき失敗モードである。なぜならそれは静かにデータセットを損なうからだ。
レジデンシャルプロキシは各リクエストを実際の家庭用回線を通じてルーティングするため、チェックは通常のユーザーが自国からストアページを開いているように見える。良好なレピュテーションを持つクリーンなアドレスは本物のストアフロントを返す一方、フラグの立ったアドレスはチャレンジを受けたり、はぐらかされたりする。IPは必要条件だが十分条件ではないため、リクエストの速度を適切に調整し、単にエンドポイントがたまたま応答するからといって叩き続けるのではなく、ブロックを引き起こすシグナルに対処すべきだ。
ページ送りの読み取りにはスティッキーセッションを
ほとんどのストアフロントチェックは単発のリクエストであり、ローテーションすべきだ。例外はページ送りを伴うものであり、この作業ではそれは主にレビューを意味する。ある国のある一つのアプリについて複数ページのレビューをたどることは一連の処理であり、その途中で出口アドレスが変わると、順序の不整合、エントリの重複、あるいは最初のページへのリセットが発生しかねない。スティッキーセッションはその一連の処理のために一つのアドレスを保持し、ページネーションの整合性を保つ。次のアプリや国に移る際には新しいセッションを開始する。日次の広範な巡回はローテーションし、ページ送りの読み取り内ではスティッキーを維持する。
時系列データの信頼性を保つ
順位は時系列データであり、時系列データの質はその欠損の少なさで決まる。ある国で1日分のデータが欠けるということは、その日について推論できなくなるということであり、したがって収集の信頼性は運用上の衛生管理ではなく、データ品質問題の一部として扱うべきだ。パイプラインを監視することをストアフロントごとに行うべきだ。ある市場で成功率が静かに低下することは、何よりもまず歪んだトレンドラインを意味するからであり、返ってきたものが実際にストアフロントであって、汎用ページやスロットリングされたページではないことを検証する価値がある。これは、継続的な価格モニタリングや在庫追跡が必要とするのと同じ規律であり、収集された結果は同種のオルタナティブデータ分析に活用される。
責任を持って収集する
正直な線引きが、ここでは重要になる。両プラットフォームとも、自社アプリ向けの公式なレポーティングAPIを公開しており、それらは自社のパフォーマンスデータのための適切なソースだ。構造化されており、正確で、利用規約の範囲内にある。公開ストアフロントの収集は、競合分析や市場インテリジェンスのためのものであり、他社のアプリについてどのAPIも提供してくれない情報だ。それは、その国の訪問者なら誰でも見られる公開データにとどめ、各プラットフォームの利用規約とrobotsディレクティブの範囲内で、丁寧なリクエストレートで行うべきだ。
はっきりと述べておくべき2点がある。レビューデータは個人情報を含みうるユーザー生成コンテンツであり、該当するプライバシー規則の下で扱い、個々のレビュアーのプロファイルを構築してはならない。そして、これはあくまで計測にとどまるべきだ。順位データの収集は市場調査だが、順位やインストール数、レビューに影響を与えようとする試みは操作であり、すべてのプラットフォームの規則に違反し、プロキシを使うべき用途ではない。ストアフロントを読むことが仕事であり、それに手を加えることは仕事ではない。
国ごとの最小限の読み取り
ターゲティングはゲートウェイ上のユーザー名に含まれるため、ストアフロントを固定するのは1つのフィールドだけで済む。読み取る市場に合わせて言語ヘッダーを一致させる:
import requests
MARKETS = ["us", "gb", "de", "jp", "br"]
def storefront(country, lang):
proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
r = requests.get(
"https://apps.example-store.com/app/id123456789",
proxies={"http": proxy, "https": proxy},
timeout=20,
headers={"Accept-Language": lang},
)
r.raise_for_status()
return r.text # 順位、価格、提供状況、メタデータを解析する
for country in MARKETS:
html = storefront(country, "en-US" if country in ("us", "gb") else None)
record(country, html) # ストアフロントごと、日ごとに1行追跡しているすべての市場で同じ読み取りを実行し、ストアフロントごとの全体像を構築する。ページ送りのレビュー読み取りは専用のスティッキーセッションに保持し、国をまたいで時系列を比較できるよう、固定された日次スケジュールでサンプリングする。一般的なクライアントのパターンは、Pythonでレジデンシャルプロキシを使う方法のガイドから引き継がれ、レビュー特有の観点は顧客レビューの監視で扱われている。
結論
アプリには単一の順位や価格、評価というものは存在しない。国別ストアフロントごとに異なる値を持ち、それぞれはその国の内部からしか読み取れない。これにより、国のカバレッジがモバイル市場インテリジェンスの中核的な要件となり、単一の場所からの収集は必然的に部分的で誤解を招く姿になる。レジデンシャルプロキシはまさにこれを解決する。各ストアフロントをローカルユーザーとして読むための国ターゲティング、レート制限に引っかかることなく多数のアプリと市場にわたって日次の巡回を分散させるための大規模なプール、返ってくるものがスロットリングされたプレースホルダーではなく本物のストアフロントであるようにするクリーンな家庭用グレードのアドレス、そしてページ送りの読み取りのためのスティッキーセッションだ。自社アプリには公式APIを使用し、競合分析の収集は公開データにとどめて各プラットフォームの規約内で行い、チャートを計測することから、それを動かそうとする行為へと決して踏み越えてはならない。
その収集レイヤーを提供するのがレジデンシャルプロキシであり、国ターゲティングと、一連の処理が必要とする箇所でのスティッキーセッションを備えた、実際の家庭用グレードIPの大規模なプールだ。GB単位の料金設定はこの作業によく適している。ストアフロントのチェックは小さく頻繁であり、コストは監視する市場の数ではなく、実際に取得するデータ量に応じて決まるからだ。