実験は、ゲームへの変更が因果的に与える影響を測定するために、ゲーム内やマッチメイキングでA/Bテストを実行することを可能にします。例えば、異なるプレイヤーに異なるオンボーディング体験を提供し、プレイ時間、リテンション、その他の重要なパフォーマンス指標の違いを測定することができます。
実験は以下のような測定に非常に適しています：
- エンゲージメント - オンボーディングフロー、進行システム、コントロールスキーム、カスタムマッチメイキング
- マネタイズ - ショップの可視性とユーザーエクスペリエンス、スターターパックの種類、価格設定
実験を作成する
実験には2種類があります：
- ゲーム内実験は、異なる設定値の影響を測定します。
- マッチメイキング実験は、異なるカスタムマッチメイキング設定の影響を測定します。ゲーム内実験とは異なり、一度に実行できるマッチメイキング実験は1つのみです。
まだ設定を持っていない場合は、ゲーム用のものを作成します。
ゲームのCreator Hubの実験ページで、実験を作成をクリックします。
タイプとして、体験内を選択します。
実験の名前、目標指標、および計画期間を指定します。実験は14〜60日間実行されます。
目標指標として何を選択しても、実験はリスト内のすべての指標を追跡します。
パーセントロールアウトを選択します。この数値は、実験に含めたいプレイヤーの割合です。
一般的に、実験に含める人が多いほどデータの質が向上しますが、ゲームにとって最適な数を判断してください。
選択した指標における最小検出効果に注意してください。これは、実験が確実に検出できる選択した指標の最小の変化です。
バリアントとパーセンテージを指定します。
バリアントは設定の代替値です。制御値が500の数値設定キーbossHealthに対して、300のバリアントを指定することがあります。実験には最大2つのバリアントと1つの制御を持つことができます。
パーセンテージは、実験のロールアウト内でバリアントを割り当てる方法を決定します。以下の例を考えてみてください：
- 総ロールアウトを40%に設定します。
- 2つのバリアントとそれらと制御との50/50の分割を指定します。
この例では、60%のユーザーが実験から除外されます。これらのユーザーは制御を受け取り、実験結果に影響を与えません。おおよそ20%のユーザーが、実験の一環として制御を受け取ります。別の20%がバリアントを受け取ります。プレイヤー数によっては、この配分が実行可能な結果を得るには不十分かもしれません。
不明な場合は、大規模なロールアウトで1つのバリアントと1つの制御のシンプルな50/50の実験を推奨します。実験の設定が容易で、結果の解釈も簡単になります。
最後のステップはスケジュールです。実験を即座に開始するか、後の日付と時刻にスケジュールすることができます。実験をスケジュールした後は、その構成（期間、ロールアウトパーセント、バリアントなど）を変更することはできませんが、再スケジュールすることは可能です。
指標
実験は、実験の期間中、以下のすべての指標を追跡します。
| 指標 | 説明 |
|---|---|
| D1 リテンション | 1日後にゲームに戻ったプレイヤーの割合。 |
| D7 リテンション | 1週間後にゲームに戻ったプレイヤーの割合。 |
| プレイ時間 | プレイヤーがゲーム内で過ごした平均時間。実験の期間中の累積。 |
| ARPU | ユーザーあたりの平均収益。収益をプレイヤー数で割ったもの。実験の期間中の累積。 |
| ARPPU | 課金ユーザーあたりの平均収益。ゲーム関連アイテムを購入したプレイヤー数で収益を割ったもの。実験の期間中の累積。 |
| 課金転換率 | ゲーム関連アイテムを購入したプレイヤーの割合。 |
| セッション時間 | プレイ時間をセッション数で割ったもの。実験の期間中の累積。 |
実験の状態
実験ページは、実験の以下の状態を示します。
| 状態 | 説明 |
|---|---|
| 完了 | 実験が終了しました。これは、手動で停止した場合、決定に達した場合、またはその決定日から短期間後に自動的に終了します（ゲーム内の場合は14日後、マッチメイキングの場合は即時）。詳細と結果を引き続き確認できます。 |
| 決定が必要 | 実験が決定日を迎えました。結果をレビューするのに良いタイミングです。 |
| 実行中 | 実験が実行中ですが、まだ決定日には達していません。 |
| スケジュール済み | 実験が将来の日付に開始する予定です。 |
| ドラフト | 実験が開始またはスケジュールされていません。設定を完了できます。 |
コードに実験を追加する
このセクションはゲーム内実験にのみ適用されます。マッチメイキング実験にはコードの変更は必要ありません。
ゲーム内実験の適用は、設定を適用するの類似です。主な違いは、ConfigService:GetConfigForPlayerAsync()の使用です。このメソッドは、ConfigService:GetConfigAsync()ではありません。
GetConfigForPlayerAsync()は、プレイヤー専用のスナップショットを取得します。GetValue()を呼び出すと、スナップショットはアクティブな実験を確認し、ロールアウトの割合に基づいてユーザーを登録します（または登録しません）。
local ConfigService = game:GetService("ConfigService")
local Players = game:GetService("Players")
local function onPlayerAdded(player)
local playerConfig = ConfigService:GetConfigForPlayerAsync(player)
local leaderboardColor = playerConfig:GetValue("leaderboardColor")
end
Players.PlayerAdded:Connect(onPlayerAdded)
プレイヤーごとにGetConfigForPlayerAsync()を別々に呼び出す必要があります。GetConfigAsync()は実験を適用しません。
プレイヤー専用スナップショットでGetValue()を呼び出すと、そのスナップショットに関連付けられたプレイヤーは、そのキーおよびそのキーのみに対する実験に登録されます。メソッドへの将来の呼び出しは、実験の期間中同じ制御またはバリアントを返します。最初の呼び出しのみがランダムです。
GetValue()を呼び出すのは必要になってから待ってください。GetValue()を早すぎるタイミングで呼び出すと、ゲームの実験対象に全く関与しないプレイヤーを登録してしまう可能性があります。
実験への登録は、新しいユーザーに限定されません。ユーザーが以前にGetConfigAsync()から値を受け取った場合でも、GetConfigForPlayerAsync()のプレイヤー専用スナップショットを使用して、そのユーザーを実験に登録することができます。
プレイヤー専用スナップショット内のキーにアクティブな実験がない場合、GetValue()は標準設定値を返します（値がない場合はnil）。
ターゲット登録
特定の基準を満たすプレイヤーの一部をターゲットにしたい場合、追加のコードを記述して、これらの基準を確認し、次にGetValue()を呼び出して実験に登録する必要があります。次の例を考えてみてください：
- ゲーム内で新しいコントロールスキームをテストしたい。
- 既存のプレイヤー（既存のスキームに慣れ親しんでいると思われる）を含めたくないので、新規プレイヤーのみを含めたい。
あなたのコードは以下のようになるかもしれません：
local function getControlScheme(player, racesCompleted)
if racesCompleted > 0 then
return "standardScheme"
else
-- プレイヤーが新しいため、実験に登録
local playerConfigSnapshot = ConfigService:GetConfigForPlayerAsync(player)
if playerConfigSnapshot:GetValue("useNewControlScheme") then
return "newScheme"
else
return "standardScheme"
end
end
end
コントロールスキームを後のセッションで持続させたい場合、データストア内のプレイヤーのエントリに値を追加する必要があるでしょう。
結果の表示と解釈
実験が少なくとも24時間実行された後、表示をクリックして詳細と結果を確認します。
登録されたプレイヤーの総数、制御値および各バリアントを受け取ったプレイヤーの数を確認できます。このページを実験の初期段階で表示するのは、実験が適切に実行されていることを確認するためだけに有用であり、アクションを取るためではありません。アクションを取る前に、ベストプラクティスを参照してください。
実験が完了したら、結果タブを確認します。目標指標における統計的に有意な変化を探し、ダッシュボードが緑または赤で強調表示します。これらの変化は、バリアントの影響を示す可能性が高く、偽陽性または偽陰性である可能性が低くなります。
任意の指標にカーソルを合わせると、信頼度を表示ボタンが表示され、信頼区間を確認できます。
指標は、パーセント変化の信頼区間が0%と重複しない場合に統計的に有意です。次の例では、D1のリテンションが17.4%上昇し、下限および上限がそれぞれ8.02%と22.03%であるため、この変化は統計的に有意です。
便利なことに、結果ページではデフォルトの設定値を実験のいずれかのバリアントで置き換えることができます。決定を行うをクリックしてバリアントを選択するか、気が変わった場合は勝者を変更をクリックします。その後、設定ページに戻ると、新しい値を確認できるはずです。
実験のベストプラクティス
最小検出効果（MDE）を使用して、実験を実行する価値があるかを判断します。
Robloxは、目標指標とバリアントごとのプレイヤー数を使用してMDEを計算します。これは、日次アクティブユーザー、ロールアウトのパーセンテージ、実験の期間、およびバリアントの分割に基づいています。目標指標に対するMDEが高すぎる場合（例えば、100%を超える場合）、統計的有意性に達する可能性が低くなります。1,000未満の日次アクティブユーザーを持つゲームは、実験から得られる有用なデータに苦労する可能性があります。
仮説から始めましょう。 単に変数を変更して結果を確認するのではなく、何を変更したのか、何が起こると予想するのか、なぜなのかを説明する因果関係の文を記述します。実験を重ねることで、結果に合わせて書面の仮説を用意することが思考を明確にし、新しい実験アイデアを生む助けになります。
実験を全期間実行させる。 新しさの効果（「これが新しいから」という理由での変化への一時的な関心）は、早期の結果を大きく歪める可能性があります。実験を早期に終了すると、異常なピークに基づいて早まった行動を取るリスクが高まります。より多くのデータによって平滑化される可能性のあるデータです。
統計的有意性なく行動しない。 プレイヤー行動の変化が一見大きくても、通常は小さなサンプルサイズのため、統計的に有意ではない場合があります。変化が統計的に有意でない場合は、それを無視してください。
実験中の変更を避ける。 重大なバグには確かに修正が必要ですが、実験中のコンテンツ変更はプレイヤーの行動に影響し、結果を無効にする可能性があります。変更が実験に無関係に思えても同様です。実験を同時に実行する場合は、互いに対話しないと確信している場合に限ります。
信頼区間を使用して指標を深く分析し、統計的有意性の境界ケースを確認します。信頼区間が広すぎる場合、その指標は統計的に有意にはならない可能性があります。
一つの指標が有意に向上し、別の指標が有意に低下している場合、そのトレードオフが価値があるかを判断しなければなりません。他の統計的有意な変動とも合わせて判断する必要があります。
実験は強いシグナルを提供しますが、統計的有意性は確率に関するもので、確実性に関するものではありません—そのため信頼区間が存在します。データの変動性、サンプルサイズ、変化の大きさが、バリアントがプレイヤーの行動に影響を与えたかを検出する確率に影響します。実験の結果に基づいて取る任意の行動は、プレイヤーのフィードバックやゲームの全体的なビジョンとバランスを取るべきです。
結果と決定をドキュメント化する。 追加の実験を実行する際に使用しなくても、知識の体を持ち、証拠を記録することは、ゲームの設計方法を通知するのに役立ちます。
