Sensor Tower、Apptopia、data.ai、42matters、AppstoreSpy。5つのベンダーが提供する製品は1つ。国別に分類され、他者が維持費を支払うスケジュールで配信される最新のアプリストアデータだ。彼らが共有する市場は2025年に9億7500万ドルの価値があり、今年は12億1000万ドルに達する見込みだ(Global Growth Insights、2025年)。
関連するプロダクト(ASOツール、モバイルアドテクの競合ベンチマーク、モバイル特化型VCのポートフォリオスコアリングモデルなど)を構築する場合、最終的に同じ分岐点に到達する。ベンダーに料金を支払うか、自分でデータを収集するかだ。
課題
アプリストアのデータは外から見ると単純に思える。データは公開されている。Appleはその大部分を古いiTunes JSONルックアップ経由で提供している。Google Playはブラウザでそれをレンダリングする。難しい要素はなさそうに見える。
しかし、それを本番環境のスケールで実行しようとした途端、すべての前提が崩れ去る。
最初に破綻するのは地理的条件だ。米国トップチャートでのゲームのランキングはブラジルのランキングとは無関係であり、どちらも日本のランキングとは異なる。価格は国ごとに変わる。配信状況も国ごとに変わる。説明文はローカライズされ、全く異なるマーケティングの文脈に変わることもある。米国限定のパブリッシャー向けにアプリをベンチマークする場合、収集リージョンは1つで十分だ。しかしグローバル展開を想定したものをベンチマークする場合は、数十の収集リージョンが必要であり、それぞれが実際にその国からリクエストを解決できなければならない。ストアのCDNはそれをチェックしている。
2つ目に破綻するのは鮮度だ。カテゴリランキングは1時間ごとに変動する。パッチによって不具合が生じた場合、新しいリリースに対するレビューのセンチメントは1日の間に反転する可能性がある。データが1日遅れていれば、顧客はすでにTwitterでその変化に気づいている。あなたのプラットフォームはインテリジェンスではなく、遅行指標になってしまう。
3つ目は収集予算だ。Appleの公開エンドポイントは安定したトラフィックを許容する。しかしGoogle Playはそうではない。PlayのリストページはJavaScriptをレンダリングし、チャートページはローテーションする悪用防止トークンを使用したXHRコールでページネーションを行い、両方のストアはヘッダーを確認する前のTLSレイヤーでスクレイパーのフィンガープリントを取得する。収集規模が1つのIPで処理できる範囲を超えた瞬間、両方のストアは意味のあるレスポンスを返さなくなる。不完全なリストになったり、レビューページが欠落したり、最悪の場合は何も取得できなくなる。
4つ目はレビューパイプラインだ。Play上の1つの人気アプリは、リリースされているすべてのロケール全体で1日に数千件のレビューを生成する。信頼できるセンチメントシグナルが必要な場合、サンプリングは通用しない。抜け漏れなく、国ごとに、完全なストリームを継続的に取得し続ける必要がある。これは大規模な製品レビューの集約で取り上げたのと同じ性質の問題だ。
これらはどれもスクレイパーの問題ではない。インフラストラクチャの問題だ。
アプローチ
良い知らせがある。4つの問題を分離すれば、それぞれに明確な解決策が存在する。
地理的な要件については、リクエストごとに終了国を固定し、その出口が実際に宣言通りの場所で解決されているかを検証できるproxyレイヤーが必要です。安価なproxyプールは国に関して常に嘘をつきます。IPがオランダに解決される状態でドイツのPlayランキングを収集すると、ドイツのメタデータを持つオランダの結果が返され、それに気づくことはありません。FourAのようなプラットフォームは、これをProxy Finderレイヤーで解決します。国を選択し、実際にその国にある出口を取得し、その後のコールでも同じ出口を再利用してセッションの一貫性を保ちます。
鮮度に関して言えば、スクレイパーを増やすことではなくスケジュールを改善することが解決策です。ランキングページにはファーストレーン(重要なカテゴリを国ごとに数分おきに取得)を適用します。詳細ページにはミディアムレーン(ランキング変動フラグが立った時のみ毎時取得)を適用します。レビューには、スローレーンのベースライン(毎日完全スキャン)と、順位や評価が変動した際のファーストレーントリガーを組み合わせます。このスケジュールはデータプラットフォーム上で動作する数百行のコードであり、プラットフォームそのものではありません。
Playでの収集予算に関しては、重要な箇所にはJSレンダリングパスを、そうでない箇所にはダイレクトパスを使用する必要があります。適切なrequestを送信すればクリーンなJSONを返すPlayページもありますが、CAPTCHA以外を返すには実際のブラウザ、実際のcookie、そして実際のアンチボットの解決が必要なページもあります。 AutoはFourA上でその判断をオーケストレーションします。まず安価なパスを実行し、失敗した場合はBrowserにエスカレーションします。本番環境では、成功したパスをSingleまたはBrowserに対して直接再実行することで、すべてのコールでオーケストレーターのコストを支払う必要がなくなります。
レビューパイプラインでは、巧妙なコードよりもスループットと冪等性が重要です。クリーンで構造化されたresponse(「時々JSON、時々HTML、時々CAPTCHA」ではない)を返すrequestレイヤー、暗黙のうちにドロップしない再試行機能、そして顧客が古いデータを目にする前に特定の国のパフォーマンス低下を検出できるリクエストごとの結果追跡機能が必要です。
結果
これら4つを正しく実装する社内チームは、数分の一のコストでベンダーのサブスクリプションに匹敵する成果を上げることができます。損益分岐点を超えると計算は急激に変化します。ミドルクラスのASOシートは、対象国ごとに月額5桁のコストがかかりますが、FourAスタイルのインフラ上の小規模な収集スタックであれば、同じ国をカバーするのにごくわずかなコストで済みます(公開されているASOツールの価格に基づく説明用シナリオ)。
コスト以上に重要なのは、パイプラインを自社で所有できることです。顧客から「火曜日にランキングが急上昇したのはなぜか」と問われた際、ベンダーのダッシュボードを見てお手上げ状態になるのではなく、生のresponse履歴から回答を引き出すことができます。
ここで成功を収めているチームには3つの共通する習慣がある。彼らは国別の成功率を第一級の指標として監視している。ある国での98%から82%への低下は、単なる補足事項ではなく、早期警告として扱われる。また、パースされたフィールドだけでなく、生のresponseを保存している。パーサーは変更されるものであり、過去のバグは新しいコードに対して再実行する必要があるためだ。そして、単一の収集ウィンドウからのレビュー数を決して信用しない。どのストアにも不安定な時間帯があるため、移動平均こそが基盤となる。
重要なポイント
アプリストアのインテリジェンスはスクレイピングの問題ではない。それはスケジューリングの問題であり、地理的な問題であり、セッションの一貫性の問題である。両方のストアが意図的に信頼性を低下させようとする中で、信頼性を維持し続けるrequestレイヤーの上で稼働する。
アプリストアのデータを販売するベンダーも、あなたが支払うのと同じインフラストラクチャのコストを支払っている。問題は、それを自分自身の条件で一度だけ支払うか、彼らの条件で毎月支払うかである。