A/B テストのベストプラクティス
クリエイティブ、配置、ペーシング、ウォーターフォールの各戦略についてA/Bテストを実施し、パフォーマンスを分析して広告の設定を調整することで、Monetizationを促進します。
読み終わるまでの所要時間 13 分最終更新 6日前
A/B テストは、すべてのビジネス戦略の重要なコンポーネントです。コントロールグループに対して前提条件をテストし、新しいアプローチが収益を最大化し、ビジネスを成長させることを確認します。Unity LevelPlay の A/B テストツールでは、さまざまな Monetization 変数を試して、ユーザーがどのように広告にエンゲージメントしているかを理解し、成功する戦略を選択することができます。
A/B テストでは、最も確実な結果を得るために、スマートな計画と明確な目標が必要です。以下のベストプラクティスは、Unity LevelPlay の A/B テストツールを使用してクリーンなテストを実施する際にヘルプます。そのため、正確なデータに基づいて最適な決定を下すことができます。
A/B テストを設定するためのベストプラクティス
ARPDAU に影響を与える可能性のあるすべてのものをテストします。** ARPDAU のブーストにヘルプ変数は常にテストする必要があります。以下のテストを出発点として使用します。
- 新しい広告ネットワークを追加して、収益性を確認します。
- ハイブリッド ウォーターフォールと従来のウォーターフォール、特定の国に対する新しいウォーターフォール、異なるインスタンスの価格設定、インスタンスの追加または削除、セグメントおよびグループのウォーターフォールなどのウォーターフォール最適化テスト
- エンゲージメントを損なうことなく最大の利益をもたらすさまざまな上限設定とペース戦略
- バナーパフォーマンスを最大化するためのバナー更新頻度
- 動画リワード報酬の金額によって、エンゲージメントのレベルが最も高い動画を決定する
- AB トラフィック アロケーターを使用します。
- コントロール グループとテスト グループを 50/50 で均等に分割してテストを開始しない場合は、A/B トラフィック分割アロケーターを使用してトラフィックを 90/10 に分割します。これにより、テストグループに大量のトラフィックをコミットすることなく、テストグループのパフォーマンスを分析できます。
- テスト グループのパフォーマンスが良好であれば、一度に 5 ~ 10% のトラフィックの増加を開始します。
- 一度に 1 つの変数をテストします。
- 広告戦略を最適化すると、テストする変数が複数あることがわかります。
- 変更の重大度を効果的に評価する唯一の方法は、1つの変数を分離してその影響を測定することです。つまり、例えば、新しいネットワークをアクティベートしながら動画配置の報酬額も変更すべきではありません。
- テストで変数を一括変更します。
- Bグループ内の同じ変数に対する、KPIに沿った複数の変更をテストします。例えば、リアルタイム ピボット待ち時間レポートを使用して待ち時間（変数）が大きいインスタンスを特定している場合は、ウォーターフォール待ち時間が長くなっていると思われる複数のネットワークを削除します。
- 非常に低い DAU アプリでのテストは避けてください。
- データ主導型ビジネスで最も多くの結論に達するには、アプリケーション レベルで15,000以上のDAUが必要です。
- テスト期間は最短で3日間、最長で14日間です。
- これにより、グループ B の十分な学習が確保され、他の変数を迅速に連続してテストできます。
- グループ A だけを残します。
- テストする変数を特定したら、コントロール グループ(グループA)を変更しないでください。グループ A の設定は、現在の広告戦略としてすでに存在します。
- 変更は、現在の戦略に挑戦し、結果を比較するグループ B でのみ行ってください。
A/B テストの実行中のベストプラクティス
- **結果をリアルタイムで表示：**リアルタイムピボットで A/B ダッシュボードに移動し、テストが稼働していることを確認し、結果をリアルタイムで確認します。
- テストデータの監視:A/B ダッシュボード を使用してデータを追跡し、変更の結果として極端な変化が発生しないようにします。
- Don't make changes to 50% split test (50/50 分割テストに変更を加えない):半々のテストテスト中にグループ B を変更しないでください。別の前提条件をテストする場合や、現在のテストにわずかな調整を加える場合は、テストを終了し、別のテストを開始します。別のトラフィック割り当てでテストを開始した場合は、テスト開始から 24 時間以内に変更を加えないようにしてください。これは非常に重要であり、分析のためにデータを整理してクリーンに保つのにヘルプます。
結果を分析するためのベストプラクティス
- データの掘り下げ:A/B ダッシュボードを結果の分析の出発点として使用します。テストを開始する前に設定した KPI に従って、2 つのグループのデータとパフォーマンスを比較します。さらに詳しく調べる必要がある場合は、ダッシュボードにリンクされているパフォーマンス レポートとコホート レポートを確認してください。
- **ARPDAU をガイドライトとして使用:**どのグループを継続するかを決定する際の指針となる主な指標は、ARPDAU です。テスト グループで行われた変更後のアプリケーションのユーザー動作を確認するには、1日あたりのアクティブ ユーザーあたりの平均収益を分析します。新規ユーザーやユーザー獲得によって影響を受ける他の指標もありますが、ARPDAUでは、既存のすべてのユーザーの動作と戦略に対する反応をより明確に把握できます。
累積 ARPU 指標も、特に特定の日からの新規ユーザーを分析する場合に考慮すべき重要な指標です。ARPU は累積 ARPU 指標と密接に関連しているため、これらをまとめて監視することが重要です。
- 適切なデータを適切なタイミングで外観:グループBに対するすべての変更後にのみ結果の分析を開始し、すべての変更の影響を確認できます。テストの初日も分析から除外する必要があります。A/B トラフィック アロケーターをテスト期間中に 5 つのテスト グループに対して使用する場合は、テストの完全な結果を得られるように、少なくとも 24 時間待つようにしてください。
- Ignore daily データ：仮定をテストするとき、あなたは毎日の変化ではなく、長期的な改善を目指しています。1 日のパフォーマンスは変動しやすいため、テスト全体のデータを日数で分割せずに分析します。
- **テスト終了後のアプリケーション傾向のフォローアップ:**テストが終了した 2 週間後にテスト済みアプリケーションの A/B ダッシュボードに戻り、最初の A/B テストの進行中の結果を分析します。これにより、試験の持続可能性と長期的な影響を学習できます。
A/B テストルーチンを作成して、アプリケーションパフォーマンスを継続的に向上させます。小さな変更と増分の変更がすぐに積み重なって、収益を大幅に増加させる可能性があり、常に最適化の余地があります。前回のテストの分析から得られた情報を使用して、次回のテストでさらに改善する方法を理解します。