レビューのエクスポートはたいてい一度きりのスナップショットです。これが役に立つのは、来月もう一度実行したときに分かります。
各行はreview_idを持ちます。当社の842行には559種類があり、しかも自分自身の重複を含む実行は1つもありませんでした。重複はすべて実行と実行のあいだにあり、同じアプリを2回取得すればまさにそうなります。これで綺麗なキーが手に入ります。エクスポートを結合し、すでに持っているreview_idの行を落とせば、残るのは本当に新しいものだけです。
リファレンスにはさらに、最も古いタイムスタンプを受け取るcutoffパラメータが記載されています。すべてを取得して大半を捨てるのではなく、前回の取得より古いものは要らないと指定できます。IDとあわせれば、レビュー履歴がどれだけ大きくなっても月次の取得は安いままです。そして履歴は大きくなります。当社のサンプルは2016年8月までさかのぼります。
このサイトの他のスクレイパーとの構造上の違いを1つ挙げておきます。ここにはqueryカラムがありません。送信したアプリは代わりにapp_idとして返るので、1回の実行で複数のアプリをまとめる場合は、このカラムでグループ化します。
設定は4つ。そのうち2つが、繰り返しの取得を小さく保ちます。
特定の星評価だけに絞り込めるのは、並び順を評価に設定したときだけです。
これはエクスポートのヘッダーをシートの順序どおりに並べたもので、11回の実行すべてで同一です。以下の充足率は、それらの実行が返した842行にわたって数えたもので、3つのアプリの559件の異なるレビューを含みます。
com.facebook.katana。842行すべてに存在。これが入力を識別します。このサービスにqueryカラムはありません。https://で、常にGoogleのユーザーコンテンツ用ホスト上にあります。2025-03-08。842行すべてに存在し、そのすべてがYYYY-MM-DDに一致しました。当社のものは10年近くにわたります。8.116.0.213。842行中702行に存在 - ただし下の注記をご覧ください。カバー率はアプリによって大きく異なります。10カラムのうち8つは1行残らず存在しました。変動するのはapp_versionとreplyだけで、どちらも構築前に理解しておくべき変わり方をします。下の注記が両方を扱います。順序についても知っておく価値があります。表計算ではreview_idが最後に、JSONエクスポートでは2番目に置かれます。どちらも同じ10カラムなので、位置ではなく名前で読んでください。
4つともリファレンスではなく842行を読んで分かったことで、それぞれがジョブの書き方を変えます。
当社の842行には559種類のreview_idがあり、単一の実行が自分自身の重複を含むことは一度もありませんでした。重複はすべて実行間のもので、同じアプリを複数回取得したことによります。つまりIDは取得のあいだで安定し、1回の実行の中では一意です。これでエクスポートを結合すれば、ほぼ同じファイルの山ではなく、育っていくレビュー履歴が手に入ります。
replyが入っていたのは842行中15行 - 2パーセント未満です。その15件はいずれも星1のレビューに付いており、15件すべてが1つのアプリのものでした。サンプルの他の2アプリには1件もありません。開発者の振る舞いについての法則と呼ぶにはあまりに小さなサンプルですが、返信を前提にした機能がほとんどの時間ほぼ空のカラムを見ることになる、と言うには十分すぎます。
全体では842行中702行に存在し、一見じゅうぶんに思えますが、アプリごとに分けると1つは90%、別の1つは84%、3つ目は14%でした。つまりバージョンごとの品質分析は、あるアプリでは現実的で別のアプリではそうではなく、全体の数字はどちらなのかを教えてくれません。グラフを作る前に、ご自身のアプリでカバー率を確認してください。
当社の行では、星1が35%、星2が11%、星3が12%、星4が7%、星5が35%という内訳でした。真ん中が最も少ないU字型です。そこから計算したどんな平均も、ほとんど誰のことも表しません。有用なのは形そのものと、その両端の背後にある本文です。ストアの表示スコアではなくレビューを取得する理由が、まさにこれです。
ストアページの要約より、完全なレビュー履歴のほうが効く場面です。
app_versionがレビューと一緒に付いてくるので、感情の傾向を月単位ではなくビルド単位で切れます。評価の落ち込みは謎ではなくなり、特定のリリースになります。次のバージョンのレビューが回復していれば、何も計測を仕込まずに答えが得られます。
競合のレビューは公開されていて、しかも異例なほど率直です。競合アプリの星1の本文を取得すれば、人々がそれのどこに耐えられないかの、ろ過されていない一覧が手に入ります。ロードマップであり、同時に自社のポジショニングに使える言い回しの供給源でもあります。
アプリの一覧を固定し、一定の間隔で再実行し、review_idで重複を排除します。毎回届くのは新しいものだけなので、星1の急増は、四半期末に誰かがようやくストアを見るときではなく、起きているその時に見えます。
サブスクリプションも最低額もシート課金もありません。最初の500行は当社負担で、その後は従量課金です。
新規アカウントごとに一度きり。クレジットカードは不要です。すべてのスクレイパーが利用可能。アプリごとの上限を適切に設定すれば500行は複数アプリぶんにあたり、評価の形を見て、ご自身のアプリのバージョンのカバー率を確認するのに十分です。
1,000レビューあたりおよそ2ドル。安くなるのは繰り返しの取得です。レビューIDで重複を排除しcutoffを使えば、履歴がどれだけ長くても月次の更新は初回のごく一部で済みます。
複数アプリのポートフォリオを一定の間隔で見守るチーム向けに、ボリューム価格、SLA、専用ワーカー、個別のオンボーディングをご用意します。数量をお知らせいただければお見積もりします。
LIVESCRAPER10をご利用ください。たいていの製品は両方のプラットフォームで配信され、苦情の内容はめったに一致しません。次の2つが反対側をカバーします。
短く答えると、はい。ただし1点だけ気に留めてください。レビューには表示名が付くので、価格表よりは少し丁寧に扱ってください。
Playストアのレビューは公開されています。アカウントなしで誰でも読めますし、公開されている情報を調査目的で収集することは長く確立された慣行です。データが公に入手可能で、その過程がサイトを妨害しないかぎり、それを禁じる連邦法はありません。
意識して扱うべきなのは、authorとauthor_imageが人を表している点です。本人が公開を選んだ表示名にすぎないとしてもです。GDPRのもとではこれは個人データなので、通常の義務が適用されます。保持する理由を持つこと、必要以上に長く保管しないこと、そしてそれを実在の身元へと結びつけようとしないこと。分析の対象がレビュー投稿者ではなくアプリであるなら - ほとんどの場合そうです - インポート時にこの2カラムを落としても失うものはありません。
Googleの利用規約は自動アクセスを制限しているので、これは引き続き規約上の論点です。当社はログインの内側には一切触れず、データ層でサードパーティのトラッカーを動かすこともなく、エクスポートは30日後に自動削除されます。
最もよくいただく質問です。ほかにもあれば ご連絡ください - 回答を書くのはボットではなく人間です。
app_id、author、author_image、rating、date、review、likes、app_version、reply、review_id。これはエクスポートのヘッダーで、11回の実行で同一でした。当社の842行すべてに存在したのは8つで、変動したのはapp_versionとreplyだけです。表計算ではreview_idが最後、JSONでは2番目に置かれるので、位置ではなく名前で読んでください。com.facebook.katanaのようなアプリIDでも、同じアプリのPlayストアの完全なリンクでも解決され、1回の実行(最大1,000件)の中で混在させられます。アプリは各行にapp_idとして返るので、複数をまとめて送る場合はそれでグループ化します。review_idを持ち、当社の842行を通じて、どの実行も内部で同じものを繰り返しませんでした。重複はすべて実行間のものです。これで重複を排除すれば、残るのは新しいものだけです。最も古いタイムスタンプを受け取るcutoffの設定もあるので、古い履歴をそもそも取得しないようにもできます。2016-08-16から2026-07-10にわたっていました。取得したアプリについては10年近い履歴です。個々の実行がどこまで深く行くかは、アプリごとの上限と選んだ並び順で決まります。replyが入っていたのは当社の842行中15行 - 2パーセント未満 - で、その15件はいずれも1つのアプリの星1レビューに付いたものでした。このカラムはほとんどの場合空だと考えて計画してください。Playストアが見せるのは星の平均と、ストアが最も関連性が高いと判断したレビューです。仕事にはどちらもあまり使えません。平均は、たいてい平坦とはほど遠い分布を平らにならしてしまいますし、表示されるレビューは誰か他人が選んだ入れ替わりの数件です。Google Playレビュースクレイパーは代わりに、その下にあるレビューを表として返します。1レビューにつき1行、書かれたままの本文、星評価、日付、役に立った票の数、投稿者が使っていたアプリのバージョン、存在する場合は開発者の返信、そしてレビュー自体の安定したIDを備えています。アプリIDまたはPlayストアのリンクを1回の実行で最大1,000件送信し、アプリごとの件数と並び順を選び、CSV・JSON・Excelで書き出せます。
このページの10カラムは推測ではなく実測です。エクスポートのヘッダーであり、11回の実行で同一で、記載したすべての数値は、それらの実行が返した842行 - 3つのアプリの559件の異なるレビュー - に由来します。10のうち8つは全行に存在しました。2つはそうではなく、構築前にどちらも知っておく価値があります。app_versionは全体では842行中702行に現れましたが、カバー率はあるアプリの90%から別のアプリの14%まで開きがあり、replyは合計15行にしか現れませんでした。証拠の限界も明確に述べておくべきです。それらの実行が対象としたのは3つのアプリで、出力の形とカラムの振る舞いを示すには十分ですが、あなたの特定のアプリが何を返すかを予測するには足りません。そのために無料枠があります。
このサービスを恒久的な仕組みに組み込む価値を生んでいるのは、レビューIDです。842行全体で559種類のIDがあり、自分自身の重複を含む実行は1つもありませんでした。重複はすべて実行間のもので、同じアプリを2回取得すればまさにそうなります。これによりIDは信頼できる重複排除キーになります。エクスポートを結合し、すでに持っているIDを捨てれば、重なり合うスナップショットのフォルダではなく、育っていくレビュー履歴が得られます。リファレンスには最も古いタイムスタンプを受け取るcutoffパラメータも記載されているので、繰り返しの取得で毎回アーカイブを取りにいく必要はありません。これは聞こえる以上に重要です。アーカイブは深く、当社のサンプルは2016年8月までさかのぼりました。
データの読み方を左右するものがもう2つあります。1つは二極化です。当社のサンプルの評価は星1がおよそ35%、星5が35%で、星4はわずか7%。尺度の中央はほぼ空で、そこから計算したどんな平均もほとんど誰のことも表しません。興味深い中身は両端にあり、これがスコアではなく本文を読むべき理由です。もう1つは、これがここでquery カラムを持たない唯一のスクレイパーだという点です。送信したアプリはapp_idとして返るので、複数をまとめて送るときはその項目でグループ化します。もう1点、エクスポートのカラム名はエクスポート独自のものです。APIリファレンスは同じデータを、生のレスポンス用の別の名前で説明しています。ですから実際に受け取るヘッダーに対して構築してください。無料で始めてください。最初の500行は費用がかからず、クレジットカードも不要です。