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