【Google Play】A/Bテストの信頼性を向上させる方法

Simon Thillay by 
Head of ASO at AppTweak

1 分の読了時間

月刊ニュースレターを購読する

この記事は、2020年5月13日に開催されたASO Conference Onlineでも紹介されたものです。

A/Bテストは標準的なモバイルマーケティング手法になりましたが、ASOもその例外ではありません。 A/Bテストの仕組みは単純です。まず、オーディエンスをさまざまなサンプルに分割し、それらに対して異なるバリアント (複数の異なるスクリーンショット一式など) を表示します。その後、各バリアントのパフォーマンスを測定し、使用するバリアントを個人的な好みではなくデータに基づいて決定します。

ここで問題となるのは、テスト結果の信頼度がテスト自体の信頼度を超えることはないということです。また、Google Playにはネイティブ環境でテストを実行できるといった大きなメリットがいくつかありますが、多くの ASO実践者は勝者バリアントを100%のユーザーに適用すると、これまで発生したことがないようなコンバージョンの上昇をツールが予測することを確認しています。このような結果は_偽陽性結果_と呼ばれており、Google Playの統計機能に関わる欠陥によるものです。また、当社は新しいテスト手法を使ってこのような結果を検出できる場合があると考えています。

1. Google PlayのA/Bテストで発生する「統計ノイズ」を理解する

偽陽性が発生する主な原因には、Google Playにおけるテスト対象サンプルの生成方法が挙げられます。Google Play Store Experimentsの結果にはデータの内訳が含まれていないため、GoogleのA/Bテストツールではユーザーを区別できないと思われます。そのため、複数の異なるサンプルをコンバージョンする際に大きな不均衡が生じる可能性があります。アプリのストアページに流入するユーザーは一様ではなく、それぞれの目的は大きく異なっている可能性があるためです。

  • 正確な名称を検索したユーザーは目的のアプリを知っている可能性が非常に高いため、ストアの掲載情報を読み飛ばしてアプリをダウンロードする可能性が非常に高いと考えられます。
  • 一方、UA (ユーザー獲得) キャンペーンや通常の検索から流入したユーザーは、広告で約束されていた内容がダウンロード後に提供されることを期待している可能性があります。そのため、ストアの掲載情報に含まれる内容にはより注意が必要です。
    Google Play Store ExperimentsでA/Bテストを行う際、ユーザーはトラフィックソースでフィルタリングされません。

    Google Play Store ExperimentsでA/Bテストを実行する際、ユーザーはトラフィックソースによって絞り込まれません。

ユーザーを区別せずにA/Bテストの異なるバリアントに割り当てた場合、Google Play Store Experimentsでは構成がまったく異なる別々のテスト対象サンプルが生成される可能性があります。その結果、バリアントの違いとは関係なくコンバージョンに大きな違いが生じる可能性があります。

また、季節がストア内の状況にどのような影響を及ぼし、テスト内の各サンプルによる日々の行動にどのような変化が生まれるかということも問題となります。これは配信者側では制御できないものの、A/Bテストの実行方法に関して考慮できる事柄です。

  • 週次の季節変動の影響を抑えるには、テストを7日間以上実行します。これは、Google自身が推奨しているベストプラクティス (英語) であるにもかかわらず、Google Play Store Experimentsプラットフォームはわずか数日間でA/Bテストの結果を示す傾向があります。テストをあと数日間実行し続ければ結果が変わる可能性があり、場合によってはテストの勝者が逆転することがあると多くの開発者が考えているにもかかわらずです。
  • ユーザー側でイベントの受け入れ準備が完了する前に、季節イベント用のクリエイティブ要素に対してA/Bテストを事前に実行しないでください。ただし、イベントの開始時にテストを実行するか、新しいクリエイティブ要素をすぐに適用してから開始前/開始後のコンバージョン分析を行ってください。

休暇シーズンのケーススタディでアプリの季節ごとの動向を確認してください。(英語)

2.統計的有意性と統計的検出力の違いを理解する

Google Play Store ExperimentsとA/Bテスト全般をより深く理解するには、A/Bテストの基礎をなす統計モデルを理解することが重要になります。A/Bテストを真に決定的なものにするには、バリアントAとバリアントBそれぞれで得られた結果に十分に大きな (有意な) 差異があるかどうかを測定するだけでなく、テストが差異を検出する可能性 (正確な差異を検出しないことを偽陰性結果と呼びます) や、実際には差異がないのに差異があると結論付ける可能性 (偽陽性結果) がどの程度なのかを把握する必要があります。

Google Play Store Experimentsはすべて、90%信頼区間と呼ばれる統計モデルを利用しています。このモデルにはすでに次のような2つの大きな欠点があることが分かっています。

  • この有意水準は、ほとんどのA/Bテストで使用されている95%信頼区間の水準を下回っていること。
  • Play Store Experimentsでは、さまざまなテストの信頼性に関する明確なデータが提供されていないこと。そのため、一部のテストの信頼性が実際には他のテストよりも高い場合でも、すべてのテストが同じ可能性で予測結果が導かれていると思うかもしれません。

これは、テストの統計的検出力が各サンプルのサイズに由来しているためです。サンプルが大きいほど偽陽性結果が検出されるリスクは減り、より小さなコンバージョンの上昇が検出される可能性が高くなります。

3.A / B / Bテストを実行して偽陽性結果にフラグを立てる

私たちのチームはGoogle Play Experimentsで偽陽性結果が頻発する原因を特定した後、このような問題に遭遇するリスクを減らすことを考え、結果が偽陽性結果である可能性がどの程度なのかをテスト結果から把握できる可能性を高めようとしました。

私たちが導いた結論は次のとおりです。

  • 週次の季節変動によって発生しうる誤った結果を減らし、すべてのテストの統計的検出力を高めるのに十分なサンプルサイズを確保するには、すべてのテストを7日間以上は実行し続けることが不可欠であること。
  • ASO実践者は、マーケティングチームがUAキャンペーンを実施中にテストを実行することを躊躇すべきではないこと。ただし、テスト全体を通じて各マーケティングチャネル間のトラフィックを安定的に分割させる必要があります。
  • テストで2つの同じBバリアントを2つ作成する (→A / BではなくA / B / Bテストを効果的に設計する) と、結果が偽陽性に当てはまっているかどうかを評価するのに役立ちます。両方のBサンプルが同様の結果を提供する場合、それらの結果は偽陽性であると考えられます。それに対し、結果が異なる場合はいずれか片方が偽陽性だと考えられます。
  • このように構成すると、サンプルのトラフィックはそれぞれ 33.34%、33.33%、33.33%になります。他の (C) バリアントをテストに追加することはできません。
    1つ目のBサンプルでは、+0.3%~+4.8%の上昇が予測されるのに対し、2つ目のBサンプルでは、-2.4%~+2.5%の変動が予測されます。

最初のBサンプルと2番目のBサンプルの結果は大きく異なっています。そのため、A/B/Bテストによって2つの結果のうち1つ以上が偽陽性結果であると疑うことができます。

この新しい手法の大きなメリットは、わずか1週間でテストの信頼性を評価できることです。それに対し、別の有名な手法では最初の週に A/B テストを実行し、2 週目にB/Aテストを実行し、最初のテストの結果を確認していました。 両方とも偽陽性結果の適用を回避するのに適した手法ではありますが、A/B/Bテスト構成を使用すると「確定」サンプルを確実に同時にテストしながら、行動を起こすのに必要な時間を短縮し、季節による偏りをなくせることが分かりました。

4.A/B/B手法による影響の評価: ASO実践者の協力を求めています

ここまで統計について学習してきましたが、当社はA/B/Bテストに関して、ASO実践者への実際の影響を評価することを次の目標にしています。そのため、意欲的な読者の皆さんに自身のアプリを使用してこの手法を試し、その結果をAppTweakにご提供いただきたいと考えています。A/B/Bテストの実際の影響や、テストによる偽陽性結果の検出あるいは非検出の頻度を今後の記事で皆さんにお伝えできればと思います。

各テストについて皆さんから募集している情報は次のとおりです。

  • アプリ名 (省略可)
  • アプリのカテゴリー
  • テスト対象のストアのカスタム掲載情報 (グローバル / デフォルトのen-us/en-uk/es-spain/…)
  • 開始日と終了日
  • テスト対象のバリアントタイプ
  • 適用したトラフィック分割
  • バリアントごとのインストーラー
  • 信頼区間の下限
  • 信頼区間の上限
  • 適用対象バリアントのテスト前の週から次の週までのコンバージョンの上昇

テスト結果を提供するためのテンプレートはこちらから取得できます。提供されるデータはAppTweakによって機密保持され、A/B/Bテスト手法に関する統計を集計する目的でのみ使用されます。

テスト結果の提供を希望する、あるいはA/B/B手法に関する質問がある場合は、当社のWebサイト、メール、ソーシャルメディア、またはASO StackのSlackチャンネルでチームにお問い合わせください。

無料トライアルを始める

Simon Thillay
by , Head of ASO at AppTweak
Simon is Head of ASO at AppTweak, helping apps boost their visibility and downloads. He's passionate about new technologies, growth organizations, and inline speed skating.