アプリ内 A/B テストを実施してアプリを改良する
A/B テストは、一部のユーザーを対象にしてアプリの改良をテストし、そのデータを基にユーザー全体にとって最適なソリューションを選択できる手法です。
解説
A/B テストは、アプリの機能やコンテンツの変更が有益かどうかを判断する際の客観的な根拠となります。また、変更を一部のユーザーに対してテストできるため、アップデートを全ユーザーに公開した後で思いがけない悪影響が出てしまうような事態を防ぐことができます。
手順
- 適切な A/B テスト プラットフォームを選択します。たとえば、Firebase Remote Config のランダム パーセンタイル ターゲティングと Firebase 向け Google アナリティクス、Google タグ マネージャーを組み合わせて、アプリと統合します。
- テストしたい機能またはコンテンツのバリエーションと、それが成功したかどうかを測定する方法を決定します。
-
各テスト バリエーションとして、また、テスト対象外のユーザーに表示する機能やコンテンツをセットアップします。以下の例をご覧ください。
シナリオ: 既存の機能の新しい実装
例: タブの代わりに下部ナビゲーションを使用することで、ユーザー エンゲージメントが向上するかどうか。
グループ ユーザーに表示される内容 テスト対象外のユーザー 既存の実装（タブ） バリエーション A 既存の実装（タブ） バリエーション B 新機能の実装（下部ナビゲーション） バリエーション C、D など（省略可） 追加機能の実装（例: ナビゲーション ドロワー） シナリオ: 新しい指標を作成する新機能
例: アプリ内購入アイテムを価格順ではなく人気順で表示することで、収益が増えるかどうか。
グループ ユーザーに表示される内容 テスト対象外のユーザー 新機能なし（アプリ内購入は有効にしない） バリエーション A 新機能の実装 1（アプリ内購入アイテムを人気順でリスト表示） バリエーション B 新機能の実装 2（アプリ内購入アイテムを価格順でリスト表示） バリエーション C、D など（省略可） 追加機能の実装（例: 購入アイテムをアルファベット順で表示） シナリオ: 既存の指標を使用して測定する新機能
例: ユーザーがアイテムにマークを付けられるようにすることで、ユーザー エンゲージメントが向上するかどうか。
グループ ユーザーに表示される内容 テスト対象外のユーザー 新機能なし（アイテムのマーキングは無効） バリエーション A 新機能なし（アイテムのマーキングは無効） バリエーション B 新機能の実装（例: ハートマークを使用してアイテムをマーキング） バリエーション C、D など（省略可） 追加機能の実装（例: スターマークを使用してアイテムをマーキング） - テストの母集団の規模やテスト期間を選択します。A/B テスト プラットフォームの機能に応じて異なりますが、テストの母集団には少なくとも 1,000 ユーザーを確保できるようにします。
- テストを実施します。
- テスト結果を確認して、統計的に有意な結果かどうか、テストしたバリエーションの中にアプリのパフォーマンスを改善したものがあるかどうかを判断します。
- 効果があった変更をすべてのユーザーに適用します。
おすすめの方法
- 大規模なテストが可能なプラットフォームを選択します。アプリやビジネスが成長するにつれて、多くの A/B テストを頻繁に実施する必要が出てくることがあります。選択したプラットフォームで、同じ母集団を対象に複数のテストを並行して実施できるかどうかを確認します。母集団を共有できればなお理想的です（1 人のユーザーが同時に複数のテストに参加できるようにするため）。
-
テストを実用的なものにするため、適切な数のバリエーションをテストします。アプリを改善できる可能性がある有用な機能やコンテンツが複数ある場合は、3 つ以上のバリエーションをテストすることを検討してください。
バリエーションの定義には多変量の手法を使用することをおすすめします。次に例を示します。
| ボタンのテキスト（アスペクト 2） | |||
| 買う | 購入 | ||
| ボタンの色（アスペクト 1） | 青 | バリエーション A | バリエーション B |
| 緑 | バリエーション C | バリエーション D | |
- 周期的な変化を排除できるように長期間テストを実施します。ユーザーの行動は、時間単位、1 日単位、週単位など、一定の周期で変わる場合があります。テストの期間を設定する際、こうした周期を考慮する必要があります。ユーザーの行動が比較的長い周期で変わることがわかっているときには、テスト期間を短くして結果を予測することが必要になる場合もあります。
- ユーザー セグメント間の既知の差異がテストに影響しないようにします。ユーザー行動がユーザー セグメントごとに異なると予想される場合は、1 つのセグメント内でテストを実施するか、ユーザー全体の代表サンプルを使用するようにします。たとえば、国によってユーザーあたりの収益に差があることがわかっている場合には、1 つの国のユーザー、またはすべての国から抽出したサンプル ユーザーのいずれかを対象にテストを実施します。
- 複数のセグメントを対象にテストします。有用な既知のユーザー セグメント（国別、獲得チャネル別など）がいくつかある場合は、異なるセグメントに対してテストを実施し、セグメント間でテスト結果に違いがあるかどうかを確認します。その後、必要に応じて一部のセグメントにのみ変更を適用したり、セグメント別に異なる変更を適用したりします。
- テスト期間を設定する際に、潜在的なビジネス上のメリットを考慮します。テスト期間やテストグループの規模、ならびにテスターにバリエーションが表示されるまでの時間を設定する際は、テスト期間を短くした場合に早期にメリットを実現できるといったビジネス上のメリットがあるかどうかについて検討します。
- テストが予想外の悪い結果を生んでいないかモニタリングして、いつでもテストを中止できるようにします。ごく一部のユーザーしかテストに参加していない場合でも、思わしくない結果になればアプリの評価やレビューに影響したり、ソーシャル メディアで共有される情報を通じて他のユーザーにもマイナス イメージを与えたりするおそれがあります。
- プラットフォームで対応可能であれば、変更を段階的に適用します。テスト結果では変更した場合の統計的なメリットが示されているとしても、ユーザー全体に変更を適用したときに思いもよらない結果になることもあります。変更を段階的に適用することで、変更後のアプリを使用するユーザーが増えたときの結果をモニタリングし、想定どおりの効果が得られない場合は変更適用プロセスを中止することができます。
- オプトインしたユーザーは指標から除外します。 テスト対象の新機能の表示や使用をユーザーがオプトインできるようにしている場合は、オプトインしたユーザーを指標から除外します。