How to A/B Test App Store and Google Play Screenshots
スクリーンショットは、App Storeの資産の中で最も変更しやすいものの1つですが、主観だけで判断するのが最も難しいものの1つでもあります。A/Bテストを利用すれば、デザインファイル上でどちらのバージョンが見栄えが良いかを議論する代わりに、実際のストアトラフィックを対象にスクリーンショットのアイデアを比較できます。
AppleとGoogleはどちらもストア情報の実験をサポートしています。Appleはそのシステムを プロダクトページの最適化 と呼んでいます。Googleはそのシステムを ストア情報の実験 と呼んでいます。仕組みは異なりますが、スクリーンショットの戦略は同じです。「一度にテストする明確な仮説は1つだけ」ということです。
テストできる項目
App Storeでは、プロダクトページの最適化により、元のバージョンに対して最大3つの代替プロダクトページバージョンをテストできます。Appleによると、アプリのアイコン、スクリーンショット、Appプレビュービデオをテストし、App Analyticsで結果を確認して、最もパフォーマンスの高いバージョンを適用できます。
Google Playでは、ストア情報の実験で、アイコン、フィーチャーグラフィック、スクリーンショット、プロモーションビデオなどのグラフィックアセットをテストできます。ローカライズされた実験では、簡易説明や詳細説明などのテキストフィールドもテストできます。Googleによると、各アプリは1つのデフォルトグラフィック実験、または最大5つのローカライズされた実験を同時に実行できます。
スクリーンショットテストの優れたアイデア
- 成果優先 vs 機能優先： ユーザーのメリットを前面に出すか、製品のUIを前面に出すか。
- 最初のスクリーンショットのバリエーション： 第一印象に最も大きな影響を与えるため、最初のスクリーンショットをテストします。
- プレーンUI vs フレーム付きUI： 未加工のインターフェース画面と、デバイスフレームに収められたマーケティング用スクリーンショットをテストします。
- 短い見出し vs 具体的な見出し： 感情的なわかりやすさと、具体的な機能の詳細を比較します。
- ローカライズされたコンセプト： 特定の市場向けの機能や表現が、その地域でより高い効果を発揮するかどうかをテストします。
最初にテストすべきではないこと
どのセット全体が勝つかだけを気にするのでない限り、すべてのスクリーンショット、見出し、背景、機能の順序を一度に変更しないでください。バリアントのパフォーマンスが向上したとしても、その理由が分からなくなってしまいます。トラフィックが限られている個人開発アプリにとって、それは有用なシグナルを無駄にすることになります。
まずは影響の大きい変更を1つだけ行います。最初のスクリーンショット、最初の見出し、メインの視覚的スタイル、または機能の順序などです。勝者が決まったら、それを新しい基準（ベースライン）として使用します。
App Storeでのテスト実行方法
- 現在の情報と同じストアサイズで、すっきりとしたスクリーンショットのバリアントを作成します。
- App Store Connectを開き、プロダクトページの最適化テストを作成します。
- 最大3つのパターンを選択し、テストに割り当てるトラフィックの割合を決定します。
- 後でApp Analyticsで確認したときにわかりやすいよう、説明的なテスト名を付けます。
- 勝者を適用する前に、十分なデータが蓄積されるまで待ちます。
Appleは、テストパターンに選ばれたユーザーは、テスト期間中ずっと同じパターンを目にすることになると説明しています。代替のスクリーンショットやAppプレビューは、オリジナルのアセットと同様に、検索結果やApp Storeの他の場所に表示される場合があります。
Google Playでのテスト実行方法
- Play Consoleを開き、「ストアでの存在感」から「ストア情報の実験」に移動します。
- デフォルトのグラフィック実験またはローカライズされた実験を作成します。
- ターゲットとする指標、ターゲット層、バリアント、および検出可能な最小効果を選択します。
- 可能な限り、一度にテストする属性は1つだけにします。
- 結果を確認し、勝者となったバリアントを適用するか、現在の情報を維持します。
Googleは、ターゲットとする指標として「維持された新規インストールユーザー」を推奨しています。また、Google Playにログインしていないユーザーには実験的なバリアントが表示されないことも警告しています。
どれくらいのトラフィックが必要か？
万能な数字はありません。トラフィックの少ないアプリはより長い時間が必要であり、微細な視覚的差異を検出するにはより多くのトラフィックが必要です。アプリへのストア訪問数が限られている場合は、より明確な最初のスクリーンショット、新しいバリュープロポジション、ローカライズされた視点など、より大きな違いをテストしてください。
決着がつかなかった結果も情報として捉えましょう。それは変更が小さすぎたか、ターゲット層が少なすぎたか、あるいは両方のバージョンがほぼ同等であったことを意味している可能性があります。
実践的なスクリーンショットテストのチェックリスト
- バリアントをデザインする前に、仮説を1つ書き出します。
- テスト1回につき、変更する主要なアイデアは1つだけにします。
- App StoreとGoogle Playの有効なスクリーンショットの寸法を使用します。
- コントロール（統制群）とバリアントの間で、ローカライズの整合性を保ちます。
- 初期の数値が良いからといって、すぐにテストを中止しないでください。
- 次のテストが実際の学習から始められるよう、変更内容を記録に残します。
Screenshot Broがお役に立てる理由
A/Bテストではスクリーンショットのバリアントを作成します。ここで手動のワークフローは非常に煩雑になります。Figmaファイルの複製、PNGのファイル名変更、ロケールごとのフォルダ分け、繰り返される書き出しなどです。 Screenshot Bro は、スクリーンショットのセットを構造化された状態に保つのに役立ち、ベースラインを見失うことなくバリアントの作成、ローカライズ、正しいファイルの書き出しを行えるようにします。
今でも手作業でバリアントをデザインしている場合は、 FigmaでApp Storeのスクリーンショットをデザインする方法 を読み、そのワークフローを専用の アプリストアスクリーンショットツール と比較してみてください。