> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # 実験のベスト プラクティスと推奨事項 > テスト設計、オーディエンスのサイズ設定、サンプル比率不一致、データ駆動型意思決定など、ライブ ゲームで PlayFab の実験を実行するためのベスト プラクティス。 # 実験のまとめ このガイドでは、実験の実践について紹介します。なぜ早期に実験すべきか、ベスト プラクティスの推奨事項、そしてプロセスに慣れるための情報を詳しく説明します。 ## 実験が重要な理由 実験は、ゲーム体験の変更の効果を特定するためのゴールド スタンダードです。ゲーム体験の変更の効果を理解し、それを裏付けるデータがあれば、より効果的なゲーム設計、体験、マーケティング戦略を構築できる意思決定が容易になります。継続的な実験により、変更の効果が時間経過とともに減衰するかどうかを判断できます。 ゲーム開発の旅路 (作成または運用) のどの段階にいても、PlayFab Experiments は個人、チーム、スタジオが実証データを収集しながらゲーム体験に慎重な変更を加えることを可能にし、ゲームにとって何が最適かを正確に把握するのに役立ちます。 実験は、制御された限られたオーディエンス (プレイヤー トラフィック) におけるゲーマーの行動に関する洞察を得られる効果的な実践です。したがって、プレイヤー ベースを不満足なゲーム体験から守ります。また、リソースをより有効に活用でき、ライブ ゲームでゲーム機能を簡単に有効化または無効化できます。実験は、「私たちはこう思う」から「私たちは知っている」という意思決定力への変革を助けます。実験は、制御された限定的なオーディエンス (プレイヤー トラフィック) でゲーマーの行動に洞察を与える効果的な実践です。したがって、プレイヤー ベースを不快なゲーム体験から守ります。また、リソースをより有効に活用でき、ライブ ゲームでゲーム機能を簡単に有効化/無効化できます。 以下は、実験時のゲーム スタジオの一般的な目標です: * アクティブ プレイヤー ベースの増加 * コンバージョン率の向上 * 離脱率の低下 ## 実験の信頼性は重要 実施している実験の結果に基づいて意思決定する際、関係性・因果関係が存在することを確認したいでしょう。実験の信頼性は、実験結果の統計的有意性と等しくなります。 信頼性は PlayFab の実験結果の焦点です。すべての指標は統計的有意性についてチェックされます。 たとえば、リテンションで 2 パーセントのリフトを測定する実験を実行し、それが p 値 0.04 で統計的に有意と示された場合、それは A と B に差がなかった (つまり帰無仮説が真だった) と仮定した場合に 2% 以上の結果が観測される確率が 4% であることを意味します。真の差は直接測定できず、統計は妥当な推定を得るために使用されます。ノイズ (ランダム性) が私たちを誤らせる可能性があります。 統計的有意性は、リスク許容度と信頼水準を反映するため重要です。指標は日々変動する可能性があり、統計分析はノイズの多い環境でビジネス上の意思決定を行うための健全な数学的基盤を提供します。 PlayFab Experiments は、95% の信頼水準または p 値 0.05 で指標の変動を統計的に有意としてフラグ付けします。 ## サンプル比率不一致 (SRM) サンプル比率不一致 (SRM) は、実験バリアント間のユーザーの期待される割合 (たとえば実験開始前に構成された割合) と、実験終了時に観測されたユーザーの実際の割合の間に有意な差があることを示すデータ品質チェックです。 SRM は、コントロール バリアントとトリートメント バリアントに不均一な影響を与える、データの欠落または冗長性の問題があることを示します。制御実験の基本原則は、トリートメント バリアントとコントロール バリアントが統計的に等価でなければならないことを要求します。この原則が破られると、実験結果は選抜バイアスの影響を受ける可能性があります。 SRM を持つ分析は信頼できないと見なされ、意思決定に使用すべきではありません。実際、実験に SRM がある場合は、分析から結論を導き出さないでください (SRM に対処するまで)。 ### SRM の検出方法 コントロールとトリートメントの各バリアントで 10% のトラフィックで実行するように構成された実験を例に取ります。 | **タイプ** | **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 p 値** | 0.7269 | 0.2695 | 0.0005 | \~=0 | \~=0 | \~=0 | \~=0 | このシナリオでは、各シナリオで 2 つのフライト間の実際の比率は同じですが、トリートメントとコントロールのユーザー数が大きくなるにつれて p 値がますます小さくなります。これは、観測された結果が期待どおりでないことを示します。 ### SRM を調査する方法 SRM の調査と解決は複雑で不確実なプロセスです。したがって、SRM を解決するには構造的なアプローチ、パノラマ的な視点、根本原因と解決戦略の可能性への認識が必要です。そのため、 * 「なぜこれが起こったのか?」という質問から始めます * その SRM の原因について仮説を立てます * その仮説が真だった場合に観察される証拠を予測します * それらの証拠を見つけます * 原因を分析して解決策を特定します 追加の質問をすることで、解決に必要な手順を考案するための調査を助けることができます。たとえば: * これは 1 つの分析/実験だけで起きたのか、複数で起きたのか? * トリートメントは何をするのか? 実験の性質は何か? * 現在 (SRM) と以前 (SRM がない前回の実験) の間で何かが変わったか? * ビュー、パイプライン、フィルターに変更はあったか? ### SRM の一般的な根本原因 * ゲーム内のトリートメント体験がコントロール体験よりもクラッシュが多い * トリートメント体験が意図せず異なる量のデータを送信している。たとえば、テレメトリ バッファーを増やすクライアント上の実験は、戻ってくるデータ量を確実に増やし、SRM を引き起こします ## 実践としての実験 * **仮説から始める** 実験に明確な目標とシナリオがあることを確認するために仮説を立てます。また、テストする変更が意味を持つほど有意であることを確認します。 仮説を立てるには、次のテンプレートを使用します: 観察 \[A] とフィードバック \[B] のために、プレイヤー \[D] にとって \[C] を変更すると \[E] が起こると信じています。\[F] を見て \[G] を得たときに検証されます。 * **実験を正しくスケジュールする** 信頼できる結果を得るために、A/B 実験を比較可能な期間実行します。季節的なピークと落ち込みを考慮に入れてください。 * **実験の期間** 実験に十分な時間を与えます。実験に割り当てられた時間が不十分だと、結果が歪む可能性があります。実行時間が短すぎると、統計的に正確な結論を得るのに十分なデータ ポイントを収集できない可能性があります。実行時間が長すぎると、勝利バリアントを可能な対象者に展開しないことでコンバージョンを逃すリスクがあります。疑わしい場合は、再テストするのがまったく妥当です。 * **フライトの % に注意を払う** フライトの % はサンプル サイズを決定します。適切なサンプル サイズでオーディエンスをターゲットにしないと、信頼できる結果が得られず、そのデータに基づく意思決定に欠陥が生じる可能性があります。 * **タイプ 1 とタイプ 2 のエラーを避ける** 実験における統計は、確実性ではなく確率を提供します。したがって、実験のあるバリアントが最良かどうかについて 100% の確実性を提供することはできません。そのため、タイプ 1 とタイプ 2 のエラーを避けてください。 タイプ 1 エラーを避けるには、意思決定に達する前に必要な有意水準を上げ (既定で 95% に設定してあります)、より多くのデータを収集するために実験を長く実行します。そしてタイプ 2 エラーの可能性を減らすには、実験のフライト対象人口 (サンプル サイズ) を増やします。 * **実験の途中で変更しない** 理想的な期間の終了前にテストを中断したり、元の仮説の一部でなかった新しい変数を導入したりすると、結果は信頼できなくなります。つまり、変更の 1 つがコンバージョンのリフトを引き起こしたのか、単なる偶然なのかを判断することが難しくなります。 バリエーションが多いほど、信頼できる結果を得るためにテストを長く実行する必要があることに注意してください。細分化されたアプローチを取ってください。推奨事項は、任意のバリアント グループで同時に 2〜4 個の変数を実験することです。これがテスト期間と効率の最良のバランスを提供します。 * **p 値に反映される統計的有意性に注意する** データが信頼できることを確認してください。データの信頼性の尺度は統計的有意性であり、結果が偶然によるものでないことを判断します。 p 値は、AB 実験の基礎となる帰無仮説における統計的有意性を判断するために使用されます。これは、収集されたデータと帰無仮説の間の適合性を測定します。低いほど、帰無仮説を棄却することにより自信を持つことができます。 * **オープンな心を保つ** 時には、意思決定のために統計情報を無視して、従来の知識や過去の経験を使いたくなるかもしれません。それがどれほど驚くべきものであっても。テストの結果に納得できない場合は、再度実行してデータを比較してください。 ## 実験の文化とプロセスを取り入れる 実験の文化は価値があります。組織全体で誰もが恩恵を受けられるように、他のプロセスの一部として身に付ける必要があります。一貫した A/B 実験は、プレイヤーに肯定的な製品価値を追加する方法を見つける可能性が高まるため、コンバージョンを大幅に向上させることができます。 HiPPO (最高給者の意見) に頼ることから、データに基づく選択に意思決定パラダイムをシフトすることができます。従業員のより多くのアイデアがテストという形で日の目を見るようになります。重要なのは、アイデアを試すことが容易なとき、結果や次のステップについて話すことです。加えて、従業員は仕事に来ることに意欲を感じます。 実験文化を構築するには、ゲーム反復のための信頼性が高く反復可能なプロセスを導入します。以下の基礎的なステップを使用することで、絶え間ない実験の文化を獲得できます: * **目標を設定する** 実行可能な実験の目標 (エンゲージメントなど) は、チームが「成長」のような抽象的な目的で行き詰まるのではなく、実験を前進させることを可能にします。 * **チームのサポートを得てより多くテストし、優先順位を付ける** 定性的および定量的データを収集して分析し、ビジネスへの影響に基づいて仮説/アイデアをブレインストーミングして優先順位付けできるようにします。信頼性が高く反復可能なフレームワークを使用して実験の旅を通じてチームを導いてください。そうしないと、突然「もっと実験して、複数の変更を行って」と求めれば、チームは迷子になるでしょう。 * **結果をチームに伝える** テスト結果をチームで共有することで、実験を巡る勢いを構築します。共有は、将来のテストを反復して改善する方法について、チームに洞察を提供します。これは、更なる実験に人々を興奮させます。 * **失敗を受け入れる** 失敗はテストの一部であり、失敗を通常化してください。失敗が実験を停滞させないようにし、振り返り、学び、実験を続けるために前進してください。 * **良い実験衛生を実践する** チームが実行するすべての実験に標準プロトコルを作成します。実験を管理する人が誰であっても、実験結果を正確かつ意味のあるものに保つのに役立ちます。 ## 実験を実行するための推奨計画プロセス | **段階** | **説明** | | :-------------- | :------------------------------------------------------------------- | | **機会の分析** | | | 調査 | 実験オーナーが実験の機会を調査・分析します。実験に優先順位を付けます | | **実験の設計** | | | スコーピング | 実験設計を開始します。仮説を立てるために目標指標を特定します | | 機能設計レビュー | 機能/体験変更の設計を確定します。実験の一環として、変数を介してトリートメント バリアント グループに導入されます | | コーディング | 機能変更を実装します | | 本番デプロイ | 実験設計をレビューします。関連コードをデプロイします | | **実験の作成** | | | 実験構成 | PlayFab で実験を作成します | | **実験の実行** | | | A/B 実験の実行 | 実験構成に従って実験が開始されます。対象オーディエンスに体験がオーケストレーションされます。テレメトリが収集され、統計計算が実行されます | | **実験の分析** | | | 結果の評価 | スコアカードで結果を評価します | | ローンチの意思決定 | ステークホルダーがローンチの意思決定を評価します | | **展開またはロールバック** | | | 実験のまとめ | 勝利バリアントがオーディエンスの 100% にロールアップされます | ## Related topics - [実験の分析](/ja-jp/services/playfab/live-service-management/game-configuration/experiments/analyze-experiments.md) - [SHAPE オーディオ フローグラフ構築のベスト プラクティス](/ja-jp/build/console-features/audio/overviews/best-practices-audio-flowgraph-construction.md) - [Insights のベスト プラクティス](/ja-jp/services/playfab/data-analytics/legacy/insights/best-practices.md) - [ゲーム ストリーミングにおけるカスタム解像度のベスト プラクティス](/ja-jp/build/core-features/common/game-streaming/game-streaming-custom-resolution-best-practices.md) - [モダン ゲーマータグのベスト プラクティスとテスト](/ja-jp/services/xbox-services/fundamentals/identity/user-profile/gamertags/live-modern-gamertags-best-practices-and-testing.md)