A / Bテスト：段階的な分析

これは、ウェブサイトdou.uaに公開された記事の再投稿です。この記事では、PlariumKharkivのゲームアナリストであるAnnaPonomarevaが、A / Bテストを実施するための個人的なベストプラクティスを共有します。彼女は各ステップについて説明し、遭遇する可能性のある困難と落とし穴を強調し、それらを解決した経験について話します。







チームは、ゲームの各変更に多くの作業、労力、およびリソースを投資します。新しい機能またはレベルの開発に数か月かかる場合があります。アナリストの仕事は、そのような変更の実施によるリスクを最小限に抑え、チームがプロジェクトのさらなる開発について正しい決定を下せるようにすることです。



決定を分析するときは、直感的な仮定ではなく、聴衆の好みに一致する統計的に有意なデータに導かれることが重要です。A / Bテストは、そのようなデータを取得して評価するのに役立ちます。

A / Bテストの6つの「簡単な」ステップ

「A / Bテスト」または「分割テスト」という検索用語の場合、ほとんどのソースは、テストを成功させるためのいくつかの「簡単な」ステップを提供します。私の戦略にはそのようなステップが6つあります。







一見すると、すべてが単純です。

• グループA、コントロールがあり、ゲームに変更はありません。
• 変更を加えたグループBのテストがあります。たとえば、新しい機能が追加され、レベルの難易度が上がり、チュートリアルが変更されました。
• テストを実行して、どのバリアントのパフォーマンスが優れているかを確認します。

実際には、それはもっと難しいです。チームが最良のソリューションを実装するために、私はアナリストとして、テスト結果にどれほど自信があるかを答える必要があります。困難に段階的に対処しましょう。

ステップ1.目標を決定する

一方では、ボタンの色からゲームの難易度まで、各チームメンバーの頭に浮かぶすべてをテストできます。分割試験を実施する技術的能力は、設計段階で当社の製品に組み込まれています。



一方、ターゲットメトリックへの影響のレベルに応じて、ゲームを改善するためのすべての提案に優先順位を付けることが重要です。したがって、最初に、優先度の最も高い仮説から最も優先度の低い仮説への分割テストを開始する計画を作成します。



どの新機能がターゲットメトリックに影響を与えたかを正確に理解するために、複数のA / Bテストを並行して実行しないようにしています。この戦略では、すべての仮説をテストするのにより多くの時間がかかるようです。しかし、優先順位付けは、計画段階で見込みのない仮説を断ち切るのに役立ちます。

特定の変更の影響を最もよく反映するデータを取得し、疑わしい影響でテストを設定する時間を無駄にしません。



製品ライフサイクルのさまざまな段階で関心の焦点が変わるため、発売計画についてチームと確実に話し合います。プロジェクトの開始時、これは通常、保持D1です。これは、インストールの翌日にゲームに戻ったプレーヤーの割合です。後の段階で、これらは保持または収益化の指標になる可能性があります：コンバージョン、ARPUなど。



例。プロジェクトがソフトローンチにリリースされた後、保持メトリックには特別な注意が必要です。この段階で、考えられる問題の1つを強調しましょう。保持D1は、特定のゲームジャンルに対する会社のベンチマークのレベルに達していません。最初のレベルを通過するファネルを分析する必要があります。開始から第3レベルの完了までの間にプレーヤーの大幅な減少、つまり第3レベルの完了率が低いことに気付いたとします。







計画されたA / Bテストの目標：レベル3を正常に完了したプレーヤーの割合を増やすことにより、保持D1を増やすこと。

ステップ2.メトリックを定義する

A / Bテストを開始する前に、監視対象のパラメーターを決定します。メトリックを選択します。これにより、ゲームの新しい機能が元の機能よりも成功するかどうかが示されます。



メトリックには2つのタイプがあります。

• 定量的-セッションの平均期間、平均チェックの値、レベルを完了するのにかかる時間、経験の量など。
• 品質-保持、コンバージョン率など。

メトリックのタイプは、結果の重要性を評価するための方法とツールの選択に影響を与えます。



テストされた機能は、1つのターゲットではなく、いくつかのメトリックに影響を与える可能性があります。したがって、一般的な変更を検討しますが、ターゲットメトリックの評価に統計的有意性がない場合は、「何か」を見つけようとはしません。



最初のステップの目標に従って、次のA / Bテストでは、第3レベルの完了率（定性的な指標）を評価します。

ステップ3.仮説を立てる

各A / Bテストは、発売前に策定された1つの一般的な仮説をテストします。私たちは質問に答えます：テストグループにどのような変化が期待されますか？通常、表現は次のようになります。



「（影響）が（変化）を引き起こすと予想し



ます」統計的手法は逆の方法で機能します。仮説が正しいことを証明するためにそれらを使用することはできません。したがって、一般的な仮説を立てた後、2つの統計的な仮説が決定されます。それらは、対照群Aと試験群Bの間で観察された違いが事故または変化の結果であることを理解するのに役立ちます。



この例では：

• ヌル仮説（H0）：レベル3の難易度を下げても、レベル3を正常に完了したユーザーの割合には影響しません。グループAとグループBのレベル3の完了率は実際には違いはなく、観察された違いはランダムです。
• 代替仮説（H1）：レベル3の難易度を下げると、レベル3を正常に完了するユーザーの割合が増加します。レベル3の完了率はグループAよりもグループBの方が高く、これらの違いは変更の結果です。

この段階では、仮説を立てるだけでなく、期待される効果を評価する必要があります。



仮説：「レベル3の難易度が下がると、レベル3の完了率が85％から95％、つまり11％以上増加すると予想されます。」



（95％-85％）/ 85％= 0.117 => 11.7％



この例では、レベル3の予想完了率を決定するときに、開始レベルの平均完了率に近づけることを目指しています。

ステップ4.実験の設定

1.実験を開始する前に、A / Bグループのパラメーターを定義します。テストを開始するオーディエンス、プレーヤーの割合、各グループに設定する設定。



2.サンプル全体の代表性と、グループ内のサンプルの均一性を確認します。 A / Aテストを事前に実行して、これらのパラメーターを評価できます。これは、テストグループとコントロールグループが同じ機能を持つテストです。 A / Aテストは、両方のグループのターゲットメトリックに統計的に有意な差がないことを確認するのに役立ちます。違いがある場合、そのような設定（サンプルサイズと信頼レベル）を使用したA / Bテストは実行できません。



サンプルは完全に代表的なものではありませんが、ユーザーの特性（新旧のユーザー、ゲームのレベル、国）の観点からユーザーの構造に常に注意を払っています。すべてがA / Bテストの目的に関連付けられており、事前に交渉されます。各グループのユーザーの構造が条件付きで同じであることが重要です。



ここには、潜在的に危険な2つの落とし穴があります。

• 実験中のグループの高いメトリックは、良好なトラフィックを引き付けた結果である可能性があります。エンゲージメント率が高い場合、トラフィックは良好です。悪いトラフィックは、メトリックが低下する最も一般的な原因です。
• サンプルの不均一性。私たちの例のプロジェクトが英語を話す聴衆のために開発されているとしましょう。これは、英語が主要な言語ではない国からのより多くのユーザーがグループの1つに分類される状況を回避する必要があることを意味します。

3.サンプルサイズと実験期間を計算します。



オンライン計算機の膨大なセットを考えると、その瞬間は透明であるように思われます。







ただし、それらを使用するには、特定の初期情報を入力する必要があります。オンライン計算機に適切なオプションを選択するには、データタイプについて考え、次の用語を理解してください。

• 一般人口-A / Bテストの結論が将来配布されるすべてのユーザー。
• サンプル-実際にテストされるユーザー。サンプルの分析結果に基づいて、一般集団全体の行動について結論が導き出されます。
• , . — , , , .
• , . .
• (α) — , (0), .
• (1-α) — , , .
• (1-β) — , , .

これらのパラメーターの組み合わせにより、各グループで必要なサンプルサイズとテストの期間を計算できます。



オンライン計算機では、入力データを操作して、それらの関係の性質を理解できます。



例。Optimizely計算機を使用して、1％の変換率のサンプルサイズを計算してみましょう。期待される効果のサイズが95％の信頼レベルで5％であると考えてください（指標は1-αとして計算されます）。この計算機のインターフェースでは、統計的有意性という用語は、5％の有意水準での「信頼度」を意味するために使用されていることに注意してください。







Optimizelyは、87万人のユーザーを各グループに含める必要があると主張しています。

サンプルサイズをおおよそのテスト期間に変換する-2つの簡単な計算。



計算番号1.サンプルサイズ×実験のグループ数=必要なユーザーの総数



計算番号2.必要なユーザーの総数÷1日あたりの平均ユーザー数=実験のおおよその日数



最初のグループに87万人のユーザーが必要な場合、2つのオプションのテストの合計ユーザー数は174万人になります。1日あたり1,000人のプレイヤーのトラフィックを考慮すると、テストは1、740日間続くはずです。この期間は正当化されません。この段階で、通常、仮説、ベースラインデータ、およびテストの適切性を修正します。



レベル3が改善されたこの例では、コンバージョンはレベル3を正常に完了した人の割合です。つまり、コンバージョン率は85％なので、この指標を少なくとも11％増やしたいと考えています。 95％の信頼で、グループごとに130人のユーザーを獲得しています。







1000ユーザーの同じトラフィック量で、テストは、大まかに言えば、1日未満で完了することができます。この結論は、毎週の季節性を考慮していないため、根本的に間違っています。ユーザーの行動は曜日によって異なります。たとえば、休日に変わる場合があります。また、この影響が非常に強いプロジェクトもあれば、ほとんど目立たないプロジェクトもあります。これは、すべてのプロジェクトおよびすべてのテストで必要な条件ではありませんが、私が取り組んだプロジェクトでは、KPIの毎週の季節性が常に観察されました。



したがって、季節性を考慮して、テスト期間を数週間に丸めます。ほとんどの場合、A / Bテストのタイプに応じて、テストサイクルは1〜2週間です。

ステップ5.実験の実施

A / Bテストを開始した後、すぐに結果を確認する必要がありますが、ほとんどのソースでは、ピークの問題を排除するためにこれを行うことを固く禁じています。問題の本質を簡単な言葉で説明すると、私の意見では、これまで誰も成功していません。そのような記事の著者は、確率の評価、数学的モデリングのさまざまな結果に基づいて証明を行い、読者を「複雑な数式」の領域に導きます。彼らの主な結論は、ほとんど議論の余地のない事実です。必要なサンプルが入力され、テストが開始されてから必要な日数が経過するまで、データを確認しないでください。その結果、多くの人が「のぞき見」の問題を誤解し、文字通り推奨事項に従います。



プロジェクトのKPIを監視するための関連データが毎日表示されるようにプロセスを設定しました。事前に準備されたダッシュボードでは、実験の進行状況を最初から追跡します。グループが均等に採用されているかどうか、テストの開始後に結果に影響を与える可能性のある重大な問題があるかどうかなどを確認します。



主なルールは、時期尚早の結論を出さないことです。すべての結論は、A / Bテストの定められた設計に従って定式化され、詳細なレポートに要約されています。 A / Bテストの開始以来、インジケーターの変化を監視してきました。



たとえば、A / Bテストの場合と同様に、完了率は日ごとに変わる可能性があります。発売後の最初の2日間、ゲームバリアントは変更なしで勝ちました（グループA）が、それは単なる偶然であることが判明しました。すでに2日目以降、グループBの指標は一貫してより良い結果を獲得しています。テストを完了するには、統計的有意性だけでなく安定性も必要なので、テストの終了を待っています。







A / Bテストを途中で終了する価値がある場合の例。立ち上げ後、グループの1つが非常に低いレートを示した場合、すぐにそのような低下の理由を探します。最も一般的なエラーは、ゲームレベルの構成と設定にあります。この場合、現在のテストは途中で終了し、修正された新しいテストが開始されます。

ステップ6.結果の分析

重要な指標の計算は特に難しいことではありませんが、得られた結果の重要性を評価することは別の問題です。



オンライン計算機を使用して、保持や変換などの品質メトリックを評価するときに、結果の統計的有意性をテストできます。



このようなタスクのための私のトップ3オンライン計算機：

• EvanのAwesomeA / B Toolsは、最も人気のあるツールの1つです。テストの重要性を評価するためのいくつかの方法を実装します。使用する場合は、入力した各パラメータの本質を明確に理解し、結果を個別に解釈して結論を​​出す必要があります。
• , A/B Testguide. , . — , .
• A/B Testing Calculator Neilpatel. -, .

例。このようなA / Bテストを分析するために、結論を導き出すために必要なすべての情報を表示し、ターゲットを大幅に変更して結果を自動的に強調表示するダッシュボードがあります。







計算機を使用して、このA / Bテストについて結論を出す方法を見てみましょう。



初期データ：

• グループAでは、レベル3を開始した3870人のユーザーのうち、3252人のユーザーだけが合格しました。これは84％です。
• グループBでは、3968人のユーザーのうち、3730人がレベルを正常に通過しました（94％）。

EvanのAwesomeA / B Tools計算機は、サンプルサイズと選択された有意水準を考慮して、各オプションの信頼区間を計算しました。







独立した結論：

• A — 84,00%, 82,8%—85,1%. B — 94,00%, 93,2%—94,7%. (94%-84%)/84% = 0,119 => 12%
• 12% , A. — , . 95%.
• .

A / Bテストガイド計算機で も同様の結果が得られます。しかし、ここではすでに設定を試して、グラフィカルな結果と定式化された結論を得ることができます。







非常に多くの設定を恐れている場合は、計算機によって計算されたさまざまなデータを処理する必要がないか、必要ありません。NeilpatelのA / B TestingCalculatorを使用できます。







各オンライン計算機には独自の基準とアルゴリズムがあり、実験のすべての機能が考慮されていない場合があります。その結果、結果の解釈に疑問や疑問が生じます。さらに、ターゲットメトリックが定量的である場合（最初のセッションの平均チェックまたは平均長さ）、リストされているオンライン計算機は適用できなくなり、より高度な評価方法が必要になります。



A / Bテストごとに詳細なレポートを作成するので、結果の統計的有意性を評価するために、タスクに適した方法と基準を選択して実装しました。

結論

A / Bテストは、「どちらのオプションが優れているか」という質問に明確な答えを与えることはありませんが、最適なソリューションを見つける途中の不確実性を減らすことしかできないツールです。それを行うとき、詳細は準備のすべての段階で重要であり、それぞれの不正確さはリソースを消費し、結果の信頼性に悪影響を与える可能性があります。この記事がお役に立てば幸いです。A/ Bテストの間違いを避けるのに役立ちます。