Google Play Store Listing Experiments：スクリーンショットをA/Bテストする（2026年）
Google Play では、新しい最初のスクリーンショットが旧バージョンより効果があるかどうかを推測する必要はありません — 実際のPlay Storeトラフィックでテストできます。Store Listing Experiments は Play Console の Test and release → Store listing experiments 配下に組み込まれています（Googleはメニューの場所を何度か変更しており、古いガイドでは「Grow → Store listing experiments」と呼ばれています）。無料で、実際の掲載情報上で稼働し、トラフィックの振り分けと統計処理をすべて代行してくれます。
両方のストアにリリースしているなら、これはAppleの仕組みに対応するものです。iOS側についてはProduct Page ExperimentsでスクリーンショットをA/Bテストするで取り上げました — 考え方は同じですが、仕組みは異なります。本記事はPlay側を補完する内容です。
Store Listing Experimentsの仕組み
実験を作成し、テストするアセット（アプリアイコン、スクリーンショット、フィーチャーグラフィック、プレビュー動画、簡単な説明、詳細な説明のいずれか）を選び、現在の実際の掲載情報をコントロールとして、最大3つのバリアントをアップロードします。Googleはストアページに訪れたユーザーの一部にバリアントを配信し、どれがより多くのインストールにつながるかを計測します。
結果で重要な指標は2つあります：
- 獲得（ストア掲載のコンバージョン）。あるバリアントを見た訪問者のうち、インストールした割合。スクリーンショットテストにおける最重要指標です。
- 継続した初回インストールユーザー（1日後の継続率）。そのバリアントに惹かれてインストールしたユーザーが、1日後も実際に使い続けているかどうか。インストール数は多いのに継続率が悪いバリアントは、訴求内容を誇張しすぎていた可能性があります。
Googleはバリアントごとに信頼区間を算出し、あるバリアントが設定した信頼水準の閾値をクリアすると、それを勝者として判定します。メールアラートを設定できるため、ダッシュボードに張り付いている必要はありません。勝者の適用はワンクリックですが、掲載情報全体の一貫性を保つため、勝った側のアセットも通常のリリース・審査フローを通しておくのがおすすめです。
デフォルトグラフィックとローカライズされた実験の違い
ここでつまずく人が多く、また同時に実行できるテストの数にも関わってくる部分です。
- デフォルトグラフィック実験。デフォルトのストア掲載情報上のアセットをテストします — ローカライズ版が表示されない全ユーザーに表示される掲載情報です。ローカライズされたアセットを配信されているユーザーは、この実験の対象から除外されます。デフォルトグラフィック実験は同時に1つしか実行できません。
- ローカライズされたストア掲載情報の実験。特定言語向けのアセット（および／またはテキスト）をテストします。最大5つのローカライズ実験を同時に実行できます — 例えばドイツ語向け、日本語向け、ブラジルポルトガル語向けなどを、すべて並行して走らせることができます。
実務上のポイント：インストールが特定の市場に集中しているなら、ローカライズ実験を使えば、1つのグローバルテストの順番待ちをせずに、それらの市場を並行してテストできます。また、言語＝国だとは思わないでください — 「英語（アメリカ）」を選んでも対象がアメリカに限定されるわけではなく、そのローカライズ版掲載情報が配信される全ユーザーが対象になります（どこにいるかにかかわらず）。
スクリーンショットのA/Bテストを設定する
- Store listing experiments を開いて作成する。デフォルトの掲載情報か特定のローカライズ版掲載情報かを選び、3週間後に見返してもわかる名前を付けましょう（「ヒーロースクリーンショット — ベネフィット訴求キャプションv2」など）。
- アセットを選ぶ。スクリーンショットを選択します。実験ごとに変更する要素は1つに絞りましょう — 同じテストでアイコンとスクリーンショットの両方を変えると、どちらが効いたのかわからなくなります。
- 最大3つのバリアントをアップロードする。実際の掲載情報がコントロールになります。各バリアントは正しいPlayの寸法に合わせたスクリーンショットのフルセットにしてください — 正確な仕様はGoogle Play スクリーンショットサイズの完全ガイドを参照してください。
- 対象、信頼水準、MDEを設定する。バリアント間でトラフィックを配分します（よくある配分は均等 — 1バリアント対コントロールなら50/50、3バリアントならそれぞれおおよそ3分の1）。信頼水準（90%、95%、98%、99%のいずれか）と検出可能な最小効果（検出する価値がある最小の改善幅で、おおよそ0.5%〜6%で設定可能）を選びます。Play Consoleには完了条件が表示されるため、開始前に何にコミットするのかを確認できます。
- 開始したら手を出さない。あるバリアントが先行しているように見えた瞬間に覗き見して早期終了したくなる衝動を我慢しましょう。設定した条件を満たすまで走らせてください。
サンプルサイズ、期間、有意差への到達
「どれくらいの期間走らせるべきか」への誠実な答えは、固定の日数ではなく「設定した有意差の条件に達するまで」です。ただし、現実的な下限と上限は存在します。
- 最低7日間は走らせる。インストール行動は平日と週末で変動します。1週間に満たない期間では、曜日バイアスが結果に混入します。2週間（14日間）はよくある安全なデフォルトで、トラフィックの少ないアプリはしばしば28日間必要になります。
- 意味のある結果を得るには十分なインストール数がバリアントごとに必要。有意差の到達は、インストール数、バリアント数、信頼水準、MDEの関数です。おおまかな目安として、その判定を信頼する前にバリアントあたり1,000件以上のインストールを目指してください — 信頼水準を高く設定したり、MDEを小さく設定した場合はさらに多く必要です。
- 厳しい設定はトラフィックというコストを伴う。99%の信頼水準や0.5%のMDEは、90%／3%よりもはるかに多くのインストーラーを必要とします。アプリのトラフィックが少ない場合、厳しすぎる設定では有意差に永遠に到達しないこともあります — MDEを緩めるか、90%を受け入れましょう。
「判定不能」で終わるテストは失敗ではなく、れっきとした一つの結果です。多くの場合、そのトラフィック量ではバリアント同士の差を切り分けるには似すぎていたか、実施期間が足りなかったことを意味します。どちらも修正可能です — バリアントの違いをもっと明確にするか、時間をかけましょう。
バリアント数の上限とその意味するところ
コントロールに対して3バリアントというのが、実験ごとの絶対的な上限です。これは戦って乗り越えるべき制約ではなく、一つの特徴です：バリアントを増やすたびにトラフィックはさらに薄く分割され、有意差への到達がさらに遠のきます。3つの挑戦者がいる時点で、すでにストアトラフィックを4方向（コントロール＋3）に分割していることになります。ほとんどのアプリにとって、大胆で明確に異なる挑戦者を1つだけコントロールにぶつける方が、あいまいなバリエーションを4つ用意するよりも早く結論に到達します。
枠は本当に異なる仮説のために使いましょう — 異なるベネフィット訴求、異なるビジュアルスタイル、縦向き対幅広のマルチパネルレイアウトなど — 同じアイデアの色違いには使わないでください。
避けるべき落とし穴
- 複数の変数を同時に変えること。1つのテストで新しいスクリーンショットと新しい簡単な説明の両方を変えると、結果を解釈できなくなります。変数を切り分けましょう。
- 「勝者」が出た時点で早期に停止すること。初期のリードは後で縮まりがちです。3日目にあるバリアントが8%リードしているからといって判定を下すのは、自信満々に劣った掲載情報をリリースする典型的なパターンです。
- 7日未満で実施すること。週次サイクルの一部しか捉えられず、残りを見逃します。
- トラフィックの少ないアプリで統計設定を厳しくしすぎること。控えめなインストール数で99%／0.5%のMDEを要求すれば、判定不能かつ時間的コストの高いテストになることが確約されます。
- 1日後の継続率を無視すること。訴求を誇張しすぎたスクリーンショットは、インストール数を伸ばしつつ継続率を悪化させることがあります。両方の数値を見ましょう。
- デフォルト／ローカライズの区分を忘れること。デフォルトグラフィック実験は、ローカライズされた掲載情報を見ているユーザーには影響しません — ユーザーの多くがローカライズ版を見ているなら、そちらでテストしましょう。
- いつも最後のスクリーンショットばかりテストすること。Play Storeでは最初の2〜3枚のパネルが説得力の大部分を担います。まずそこからテストしましょう（PlayとAppleの違いについてはPlay Store と App Store のスクリーンショット、何が違うのかで詳しく解説しています）。
Mokbi の役割
Mokbi はA/Bテスト自体を実行しません — それはPlay Consoleの仕事であり、無料です。ほとんどのチームで手が止まるのは、そもそもバリアントを作る工程です：説得力のある挑戦者を用意するには、正しいPlayの寸法に合わせたスクリーンショットのフルセットが必要で、キャプションとレイアウトを実際に変える必要があります。Mokbiではブラウザ上で1セットをデザインし、それを複製してリードキャプション、レイアウト、背景を差し替えることでバリアントBを作れます — 複数の市場でローカライズ実験を行っている場合は、ワンクリックでキャプションを翻訳することもできます。デザインは透かし付きプレビューまで無料で、透かしなしの無制限のエクスポートとストアへの公開はサブスクリプションに含まれます — Solo（€29.99/mo、1アプリ）または Studio（€49.99/mo、最大5アプリ）で、買い切りはありません。挑戦者を素早く作るのはMokbiの役目、どちらが勝つかを決めるのはPlay Consoleの役目です。