実験の要約

このガイドでは、実験の手法に関する内容を提供します。 実験を早く実施すべき理由とベスト プラクティスの推奨事項を詳しく説明し、プロセスに慣れるのに役立つ情報を提供します。

実験が重要である理由

実験は、ゲーム エクスペリエンスの変更による影響を特定するための究極的な基準です。 ゲーム エクスペリエンスの変更による影響を理解し、それをバックアップするデータがあれば、より効果的なゲーム デザイン、エクスペリエンス、マーケティング戦略を作成するのに役立つ決定を簡単に行えます。 継続的な実験により、変更の有効性が時間の経過と共に減少するかどうかを判断することができます。

PlayFab 実験では、ゲームの開発過程のどの段階 (作成と操作のどちら) にあるかに関係なく、個人、チーム、スタジオがゲーム エクスペリエンスへの変更を慎重に行うことができます。また、経験的なデータを収集することで、ゲームに最適なのは何かを正確に理解できるようサポートします。

実験は、制御および限定した対象ユーザー (プレイヤー トラフィック) におけるゲーマーの行動に関する分析情報を提供する効果的なプラクティスです。 したがって、プレイヤー ベースを不満足なゲーム エクスペリエンスから保護します。 また、リソースの使用効率を高め、ライブ ゲームでゲーム機能を簡単に有効または無効にできます。 実験は、意思決定の動機を "考えている" から "わかっている" に変えるのに役立ちます。 制御および限定した対象ユーザー (プレイヤー トラフィック) におけるゲーマーの行動に関する分析情報を提供する効果的なプラクティスです。 したがって、プレイヤー ベースを不快なゲーム エクスペリエンスから保護します。 また、リソースの使用効率を高め、ライブ ゲームでゲーム機能を簡単に有効または無効にできます。

ゲーム スタジオが実験を行うときの一般的な目標を次に示します。

• アクティブなプレイヤー ベースの増加
• コンバージョン率の増加
• チャーン率の低下

実験の信頼性は重要

行っている実験の結果に基づいて意思決定をするとき、関係性/因果関係が存在することを確認する必要があります。 実験の信頼性は、実験結果の統計的有意性と同じです。

信頼性は PlayFab の実験結果の焦点となっています。 すべての指標について、統計的有意性があるかどうかがチェックされています。

たとえば、実験を行ってリテンションで 2% の上昇を測定し、確率価値が 0.04 で統計的に有意であることが示されている場合、A および B で違いがなかったと仮定すると (つまり、帰無仮説が正しいと仮定すると)、2% 以上の結果が確認されたであろう確率は 4% であることを意味しています。 実際の差を直接測定することはできないため、妥当な推定値を得るために統計が使用されます。 ノイズ (ランダム要素) によって判断を誤る場合があります。

統計的有意性は、リスク許容度と信頼度レベルを反映しているため、重要です。 指標は日々変わることがありますが、統計分析はノイズの多い環境でビジネス決定を行うための健全な数学的基礎を提供します。

PlayFab 実験は、信頼レベル 95% または確立価値が 0.05 の場合に、指標の動きが統計的に有意であるとしてフラグを付けます。

不一致率のサンプル (SRM)

不一致率のサンプル (SRM と呼ばれる) は、実験バリアント内で予想されるユーザー (実験を開始する前に構成されている、など) の比率と、実験の終了時に確認された実際のユーザーの割合の大きな違いを示すデータ品質チェックです。

SRM は、制御および治療バリアントに不均一な仕方で影響を与える、データの欠落や冗長性に関する問題があることを示します。 制御された実験の基本的な原則では、治療および制御バリアントが統計的に均一であることが求められています。 この原則に違反した場合、実験結果は選択バイアスの影響を受けるおそれがあります。

SRM を含む分析は信頼できないと見なされるため、意思決定に使用するべきではありません。 実験に SRM が含まれる場合、(SRM を処理するまでは) 分析結果からいかなる結果も絶対に導かないでください。

SRM を検出する方法

各制御および治療バリアントのトラフィックが 10% で実行するように構成されている実験の例を見てみましょう。

Type	1 日	2 日	3 日	5 日	7 日	14 日	21 日
治療バリアントの数	105	1,050	10,500	105,000	1,050,000	10,500,000	100,500,000
制御バリアントの数	100	1,000	10,000	100,000	1,000,000	10,000,000	100,000,000
サンプル比率	1.05	1.05	1.05	1.05	1.05	1.05	1.05
SRM の確率価値	0.7269	0.2695	0.0005	~=0	~=0	~=0	~=0

このシナリオでは、2 つのフライト間の実際の比率は各シナリオで一致していますが、そのうち 1 つでは、治療および制御で大きい方のユーザー数における確立価値が次第に減少しています。 これは、確認された結果が想定されたものと異なることを示しています。

SRM を調査する方法

SRM の調査および解決は、複雑で不確かなプロセスです。 そのため、SRM を解決するには、包括的な視点と構造的なアプローチ、および根本原因の可能性と解決戦略への理解が必要です。 これを行うには、

• "なぜこうなったのか?" という質問から始めます
• その SRM の原因に関する仮説を立てます
• その仮説が正しければどんな証拠を確認できるかを予測します
• その証拠を見つけます
• 解決策を特定するために、原因を分析します

フォローアップの質問をすると、調査において解決に必要な手順を考案するのに役立ちます。 例:

• これが発生した分析/実験は 1 つだけですか、それとも複数ですか?
• この治療の内容は? 実験の性質はどのようなものですか?
• 現在 (SRM) および以前 (SRM がない以前の実験) で何かが変わりましたか?
• ビュー、パイプライン、フィルターのいずれかが変更されましたか?

SRM の一般的な根本原因

• ゲームの治療エクスペリエンスで、制御エクスペリエンスよりも多くクラッシュする
• 治療エクスペリエンスが意図せずに異なる量のデータを送信する。 たとえば、テレメトリ バッファーを増加させるクライアントでの実験では、返されるデータの量は必ず増加し、それによって SRM が発生します

実験を実際に行う

• 仮説から始める

  仮説を立てて、実験に明確な目標と実験シナリオがあることを確認します。 また、テストの対象となる変更内容に意味があり、重要であることも確認します。

  仮説を立てるには、次のテンプレートを使用します。

  観察 [A] とフィードバック [B] のため、プレイヤー [D] に対して [C] を変更すると [E] が起こると考えます。 [F] が示されて [G] が得られると、このことが実証されます。

• 実験を正しくスケジュールする

  信頼できる結果を得るには、比較可能な期間にわたって A/B 実験を行います。 季節的な浮き沈みを考慮に入れます。

• 実験の期間

  十分な時間を用いて実験を行います。 実験に割り当てる時間が不十分な場合、結果が不正確になる可能性があります。 実行時間が短すぎる場合、統計的に正確な結果を得るためのデータ ポイントを収集できないことがあります。 実行時間が長すぎる場合、適したバリアントを潜在的なユーザーにロールアウトしないことでコンバージョンを逃してしまうことがあります。 疑いを持った場合、再テストするのが妥当です。

• フライトのパーセーンテージに注意する

  フライトのパーセンテージは、サンプル サイズを特定します。 適切なサンプル サイズのユーザーを対象とします。そうしないと、信頼できる結果が得られず、そのデータに基づく決定には欠陥がある可能性があります。

• 種類 1 および種類 2 のエラーを回避する 実験で得た統計は、確実性ではなく確率を提示します。 そのため、実験で 1 つのバリアントが最善であるかどうかに関して 100% の確実性を提示することはできません。 そのため、種類 1 および種類 2 のエラーは回避してください。

  種類 1 のエラーを回避するには、決定を下したり、データをさらに収集するために実験を延長したりする前に、必要な有意レベルを上げます (ここでは既に実行済みで、既定で 95% に設定されています)。 また、種類 2 のエラーが発生する可能性を低くするため、実験のフライト人口 (サンプル サイズ) を増加させます。

• 実験の途中で変更を加えない

  理想的な期間が終了する前にテストを中断したり、当初の仮説の一部ではない新しい変数を導入したりすると、結果は信頼できなくなります。 つまり、変化のいずれかがコンバージョンの増加の原因となったのか、あるいは単なる偶然だったのかを判断することが難しくなります。

  変動が多いほど、信頼できる結果を得るためにテストを行うべき期間が長くなることに注意してください。 細かなアプローチをします。 バリアント グループで 2 〜 4 つの変数に対して同時に実験を行うことが推奨されています。 これにより、テスト期間と効率のバランスが最も良くなります。

• 確率価値に反映される統計的有意性に注意する

  データが信頼できることを確認します。 データの信頼性の基準は統計的有意性です。これは、結果が偶然によるものではないことを判断します。

  確率価値は、AB 実験が基盤としている帰無仮説の統計的有意性を判断するために使用されます。 収集したデータと帰無仮説の間の互換性を評価します。 これが低いほど、確信を持って帰無仮説を退けることができます。

• 先入観を持たない

  自分でも驚くかもしれませんが、決定を行うため、一般的な知識や過去の経験を支持して、統計的な情報を無視したくなることがあります。 テストの結果に確信が持てない場合、もう一度行ってデータを比較します。

実験の文化とプロセスを採用する

実験の文化は貴重です。 他のプロセスの一部として受け入れ、組織全体ですべての人が利益を得られるようにする必要があります。 一貫性のある A/B 実験は、プレイヤーにプラスの製品価値を加える方法を見つける機会がより多いため、コンバージョンを大幅に向上させるのに役立ちます。

意思決定パラダイムを HiPPO (高い給料を得ている人による意見) からデータ主導型の選択にシフトすることができます。 より多くの従業員のアイデアがテストという形で公表されることになります。 重要なこととして、アイデアを試しやすい場合は、結果と次のステップについて話してください。 その上、従業員が仕事に来るためのモチベーションが上がります。

実験の文化を構築するには、信頼でき、反復可能なプロセスを導入し、ゲームで反復できるようにします。 次の基礎的な手順に従って、一貫性のある実験の文化を得ることができます。

• 目標を設定する

  アクションにつながる実験の目標 (エンゲージメントなど) を持つと、チームが “成長” などの抽象的な目標でつまずくことなく実験を進めるのに役立ちます。

• チームのサポートによってさらにテストし、優先順位を付ける

  仮説やアイデアについてブレインストーミングし、ビジネスに与える影響に基づいて優先順位を付けるのに役立つ、定性的および定量的なデータを収集して分析します。 信頼でき、反復可能なフレームワークを使用して、実験の取り組みにおいてチームを導きます。そうしないと、さらに実験を行って複数の変更を加えるよう突然依頼したときにチームは戸惑ってしまうでしょう。

• 結果をチームに伝える

  チームにテスト結果を伝えて、実験に勢いを付けます。 共有することで、チームは今後のテストを反復し、改善する方法に関する洞察を得ることができます。 これは、今後のテストへの関心を高めることにもなります。

• 失敗を生かす

  失敗はテストの一部であるため、普通のことと考えましょう。 失敗によって実験を止めるのではなく、じっくり考えて学び、前へ進んで実験を続けます。

• 実験の衛生状態を良くする

  チームが行うすべての実験に対して標準プロトコルを作成します。 これは、実験を制御しているのが誰かに関係なく、実験結果を正確かつ意義あるものに保つのに役立ちます。

実験を行うための推奨される計画プロセス

段階	説明
機会の分析
調査	実験の所有者が実験の機会を調査して分析します。 実験に優先順位を付ける
実験の設計
スコープ設定	実験の設計を開始します。 目標となる指標を特定し、仮説を立てます
機能設計の確認	機能/エクスペリエンスの変更の設計を完了します。 実験の一環として、変数を介して治療バリアント グループに導入されます
コーディング	機能の変更を実装します
製品の展開	実験の設計を確認します。 関連するコードを展開します
実験の作成
実験の構成	PlayFab で実験を作成します
実験の実行
A/B 実験を行います	実験の構成のとおりに実験が開始します。 実験は対象ユーザーに編成されます。 テレメトリが収集され、統計的計算が行われます
実験の分析
結果の評価	スコアカードを使用して結果を評価します
リリース決定を行う	関係者がリリース決定を評価します
ロールアウトまたはロールバック
最終実験	成功した変数が 100% の対象ユーザーにロールアップされます