Product Page ExperimentsでスクリーンショットをA/Bテストする
Product Page Experiments（PPE）はiOS 15でリリースされ、以来App Storeメタデータに対するA/Bテストの事実上の標準手段となっています。コントロールと最大3つのトリートメントバリアントを設定し、トラフィックを配分し、信頼水準を設定すると、Appleがどのバリアントが勝ったかを示してくれます。インフラは堅固ですが、その使い方に関する規律は必ずしも浸透していません。
PPEが実際に計測するもの
PPEはプロダクトページ上のインプレッションとコンバージョンを計測します。具体的には次のとおりです：
- インプレッション：プロダクトページに訪れたユーザー数。
- コンバージョン：ページに訪れた後に「入手」または「購入」をタップしたユーザー数。
PPEは検索リストでのタップスルー（ユーザーが検索結果からプロダクトページに遷移するかどうか）は計測しません。それを計測するには検索結果プレビューをテストする必要がありますが、そこではデフォルトロケールの最初の3パネルが使われます。PPEはカルーセル全体をテストできますが、計測するのはユーザーがすでにページに到達した後の動作だけです。
これが重要な理由は、4〜10番目のパネルへの変更はプロダクトページのコンバージョンにしか影響しないのに対し、1〜3番目のパネルへの変更は検索リストでのタップスルーとプロダクトページのコンバージョンの両方に影響するからです。PPEが計測するのは後者だけです。
「1度に1変数」のルール
バリアント間でカルーセル全体を変えてしまいたくなることがあります。それはやめましょう。バリアントAのキャプションを新しくし、デバイスの傾きを変え、カラーパレットを変えて、バリアントAが勝ったとしても、どの変更が効果をもたらしたかはわかりません。次のテストに学びを活かすための推論もできなくなります。
大切なのは、1テストにつき1箇所だけ変えることです。パネル1のキャプションだけ変え、それ以外はすべて同じ。背景色だけ変え、キャプションは同一。パネルの順番だけ変え、内容は同一。遠回りに見えますが、各テストから積み上げられる学びが生まれます。ノイズに対して素早くイテレーションしても、それは進歩ではありません。
サンプルサイズ：多くのチームが過小評価している部分
PPEは標準的な頻度論的仮説検定を使用します。必要なサンプルサイズは次の要素によって決まります：
- ベースラインのコンバージョン率（無料アプリの場合は通常1〜5%、有料はそれ以下）。
- 検出したい最小効果量（相対的に5%の改善、10%、20%のどれか）。
- プロダクトページへのトラフィック量。
おおまかな目安として：3%のベースラインコンバージョン率において10%の相対的改善を検出するには、95%信頼水準でバリアントあたり約20,000インプレッションが必要です。アプリのプロダクトページが週2,000インプレッションであれば、1テストあたり10週間かかる計算になります。多くのインディーアプリは、小さな効果量で統計的にクリーンなテストを行えるだけのトラフィックを持っていません。現実的な選択肢はこちらです：
- 大きな変更だけをテストする — カラーパレットの入れ替え、パネルの順番変更、根本的に異なるキャプションのトーン。効果量が大きいため、有意差に達するのが早くなります。
- トラフィックの配分を3バリアントではなく1〜2バリアントに絞る。
- 有意差ではなく方向性を受け入れる。あるバリアントが4週間にわたって70%の信頼水準で勝ち続けているなら、それをリリースして別のテストに進みましょう。
うまくいくテスト設計
- 仮説を1つ選びます。「サムネイルでは小さいキャプションが判読不能になるため、パネル1のキャプションを大きくするとコンバージョンが上がるはずだ。」具体的な予測であり、「どれがいいか見てみよう」ではありません。
- バリアントAを設計します：変更は1箇所のみ。カルーセルはそのままに、パネル1のキャプションだけ変更。それ以外はすべて同一。
- コントロール50%、バリアント50%に配分します。2アームのテストは、3アームや4アームよりも早く有意差に達します。
- テスト期間を事前に設定します。「4週間、または95%の有意差に達するまでのいずれか早い方」と決めます。途中で覗き見して早期終了したくなる衝動に抵抗しましょう。
- 結果を記録します。勝っても、負けても、判定不能でも — 書き留めておきましょう。記録しなければ、半年後に同じテストを繰り返すことになります。
テストする項目（優先順位順）
- パネル1のキャプション。検索サムネイルとプロダクトページの第一印象の両方を左右するため、最もインパクトが大きい変数です。
- パネルの順番。具体的には、どの機能を最初に見せるか。
- カルーセルのカラーパレット / ダークかライトか。効果が大きく、テストが速いです。
- デバイスの傾きや向き。効果は小さいですが、設定コストも低めです。
- キャプションのトーン（命令形か説明形か）。「ランを記録しよう」か「ランの記録、完了」か。効果は小さく、クリーンなシグナルを読み取るのが難しいです。
フォント、わずかな色の違い、8〜10番目のパネルのコンテンツのテストはやめましょう。これらのテストはほとんど有意差に達することがなく、その背後にある効果量も小さいため、テスト予算に見合う勝利は得られません。
PPEにおけるローカライズ
PPEはロケールごとのバリアントをサポートしています。デフォルトロケールでテストを実施して勝者をリリースした場合でも、変更をすべてのローカライズ済みパネルバリアントに手動で適用する必要があります。有意差に達するのに十分なトラフィックのあるロケール（通常はen-US）を選び、その結果をほかのロケールに対するグローバルな方向性の指針として扱いましょう。39の実験を別々に走らせないでください。
よくある失敗
- 途中で覗き見して早期終了すること。有意水準はテスト中にランダムに変動します。バリアントが勝ちそうに見えた瞬間に停止すると、誤った結論に至ります。最短期間を決め、それを守りましょう。
- 多すぎる変数を同時にテストすること。全面的なリデザインはA/Bテストでクリーンに検証できません。新デザイン全体の検証（多変数、ある程度の交絡を許容）を別途行い、その後勝者に対して1変数ずつイテレーションテストを重ねる必要があります。
- 季節変動ノイズの中でテストを走らせること。ブラックフライデー、App Storeのフィーチャリング、マーケティングキャンペーンはいずれもトラフィックとノイズを増やします。スパイクをコントロールできない限り、これらの時期のテストは避けましょう。
- ロケールを無視すること。US向けのテスト結果が日本向けにも当てはまるとは限りません。確定した答えではなく、出発点となる仮説として活用しましょう。
今月やること
- 必要なサンプルサイズを見積もります。テストを設定する前に、トラフィックとベースラインのコンバージョン率をサンプルサイズ計算ツールに入力しましょう。
- 仮説を1つ選びます。1文で書き留めましょう。
- 1変数だけ変えてAとBを設計します。App Store Connectで立ち上げましょう。
- 実施期間を設定し、終了日をカレンダーに登録します。
- 結果に関わらず記録します。