実験

*このコンテンツは、ベータ版のAI(人工知能)を使用して翻訳されており、エラーが含まれている可能性があります。このページを英語で表示するには、 こちら をクリックしてください。

実験を使用すると、ゲーム内およびマッチメイキングのA/Bテストを実行して、ゲームの変更がもたらす因果的影響を測定できます。たとえば、異なるプレイヤーに異なるオンボーディング体験を示し、プレイ時間、リテンション、その他の重要なパフォーマンス指標の違いを測定できます。

実験は、以下の測定に優れています:

  • エンゲージメント - オンボーディングフロー、進行システム、コントロールスキーム、カスタムマッチメイキング
  • マネタイズ - ショップの可視性とユーザー体験、スターターパックの種類、価格設定
Creator Hubの実験ページの概要

実験を作成する

実験には2つのタイプがあります:

  • ゲーム内実験は、異なる設定値の影響を測定できます。
  • マッチメイキング実験は、異なるカスタムマッチメイキング構成の影響を測定できます。ゲーム内実験とは異なり、同時に1つのマッチメイキング実験しか実行できません。
  1. まだ設定を持っていない場合は、ゲーム用に作成します。

  2. Creator Hub実験ページで、実験を作成をクリックします。

  3. タイプとして体験内を選択します。

  4. 実験の名前、目標指標、および計画された期間を指定します。実験は14〜60日間実行されます。

    目標指標として何を選んでも、実験はリスト内のすべての指標を追跡します。

  5. パーセントロールアウトを選択します。この数値は、実験に含めたいプレイヤーの割合です。

    一般的に、実験に含める人数が多いほどデータが良くなりますが、ゲームにとって最適なものを判断してください。

  6. バリアントとパーセンテージを指定します。

    バリアントは、設定の代替値です。制御値が500の数値設定キーbossHealthの場合、300のバリアントを指定することができます。実験には最大2つのバリアントと1つの制御を持つことができます。

    パーセンテージは、実験のロールアウト内でバリアントを割り当てる方法を決定します。次の例を考えてみてください:

    • 全体のロールアウトを40%に選択します。
    • 2つのバリアントと制御の間で50/50の分割を指定します。

    この例では、60%のユーザーが実験から除外されます。これらのユーザーは制御を受け取り、実験結果に影響を与えません。約20%のユーザーが実験の一部として制御を受け取ります。別の20%がバリアントを受け取ります。プレイヤー数によっては、この分布が実行可能な結果を得るには不十分な場合があります。

    バリアントページ

  7. 最後のステップはスケジューリングです。実験をすぐに開始するか、後の日付と時間にスケジュールできます。実験をスケジュールした後は、その構成(期間、ロールアウトパーセンテージ、バリアントなど)を変更できませんが、再スケジュールすることはできます。

指標

実験は、実験期間中に以下のすべての指標を追跡します。

指標説明
D1リテンション1日後にゲームに戻ったプレイヤーの割合。
D7リテンション1週間後にゲームに戻ったプレイヤーの割合。
プレイ時間プレイヤーがゲーム内で過ごした平均時間。実験の期間中の累積。
ARPUユーザーあたりの平均収益。収益をプレイヤー数で割ったもの。実験の期間中の累積。
ARPPU課金ユーザーあたりの平均収益。収益をゲーム関連アイテムを購入したプレイヤー数で割ったもの。実験の期間中の累積。
課金転換率ゲーム関連アイテムを購入したプレイヤーの割合。
セッション時間プレイ時間をセッション数で割ったもの。実験の期間中の累積。

実験のステータス

実験ページは、実験の以下のステータスを表示します。

ステータス説明
完了実験は終了しました。これは、手動で停止した場合、決定に達した場合、または決定日から14日後(ゲーム内の場合)、決定日直後(マッチメイキングの場合)に自動的に発生します。詳細と結果を確認できます。
決定が必要実験は決定日を迎えました。結果を確認するのに良い時期です。
実行中実験は実行中ですが、まだ決定日には達していません。
スケジュール済み実験は将来の日付に開始するようにスケジュールされています。
ドラフト実験は開始されていないか、スケジュールされていません。設定を完了できます。

コードに実験を追加する

ゲーム内実験の適用は、設定の適用に似ています。主な違いは、ConfigService:GetConfigForPlayerAsync()を使用することです。

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()を呼び出すと、そのスナップショットに関連付けられたプレイヤーは、そのキーとそのキーのみの実験に登録されます。以降のメソッド呼び出しは、実験の期間中、同じ制御またはバリアントを返します。最初の呼び出しのみがランダムです。

  • 実験への登録は新しいユーザーに限られません。ユーザーが以前に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%であり、この変化は統計的に有意です。

指標の信頼区間

便利なことに、結果ページではデフォルトの設定値を実験のバリアントの1つに置き換えることができます。決定を下すをクリックしてバリアントを選択するか、気が変わった場合は勝者を変更をクリックします。その後、設定ページに戻ると、新しい値が表示されるはずです。

実験のベストプラクティス


  • 最小検出効果(MDE)を使用して、実験を実行する価値があるかどうかを判断します。

    Robloxは、目標指標とバリアントごとのプレイヤー数を使用してMDEを計算します。これは、日次アクティブユーザー、ロールアウトパーセンテージ、実験の期間、バリアントの分割に基づいています。目標指標のMDEが高すぎる場合(たとえば、100%を超える場合)、統計的有意性に達することは難しいです。日次アクティブユーザーが1,000人未満のゲームは、実験から有用なデータを得るのが難しいかもしれません。

    作成中の不十分なMDE画面。

  • 仮説から始める。 変数を変更して結果を確認するのではなく、何を変更したか、何が起こると予想するか、なぜそうなるのかについての因果関係の声明を書きます。実験を重ねるにつれて、結果に伴う書面による仮説のセットを持つことは、思考を明確にし、新しい実験のアイデアを生むのに役立ちます。

  • 実験をその全期間実行させる。 新しさの効果(変化に対する一時的な興味)は、早期の結果を大きく歪める可能性があり、時には統計的有意性の内外で揺れ動くことがあります。実験を早期に終了すると、異常なスパイクに基づいて早急な行動を取るリスクが高まります。より多くのデータがあれば、スパイクは平滑化されるか、反対の結果になる可能性があります。

  • 統計的有意性がない限り行動を起こさない。 プレイヤー行動の大きな変化に見えるものでも、一般的にサンプルサイズが小さいため、統計的に有意でない場合があります。変化が統計的に有意でない場合は、それを無視してください。

  • 実験中の変更を避ける。 重大なバグはもちろん修正が必要ですが、ゲームコンテンツの変更はプレイヤー行動に影響を与え、結果を無効にする可能性があります。変更が実験に無関係に見えても同様です。さらに、実験が互いに影響しないと確信している場合を除き、同時に実験を実行しないでください。

  • 信頼区間を使用して指標を深く掘り下げ、統計的有意性の境界ケースを確認します。 信頼区間が広すぎる場合、その指標は統計的有意性に達しない可能性があります。

  • 1つの指標が大幅に上昇し、別の指標が大幅に下降している場合、トレードオフが価値があるかどうかを決定する必要があります。これは、他の統計的に有意な動きと組み合わせて行うことができます。

  • 実験は強い信号を提供しますが、統計的有意性は確実性ではなく確率に関係します。したがって、信頼区間があります。データの変動性、サンプルサイズ、変化の大きさは、バリアントがプレイヤー行動に影響を与えたかどうかを検出する確率に影響します。実験の結果に基づいて行動を起こす場合は、プレイヤーのフィードバックやゲーム全体のビジョンなどの定性的データとバランスを取る必要があります。

  • 発見と決定を文書化する。 追加の実験を実行するために使用しなくても、知識と証拠の体を持つことは、ゲームの設計方法に影響を与える可能性があります。

©2026 Roblox Corporation。Roblox(ロブロックス)、RobloxロゴおよびPowering Imaginationは、米国並びにその他の国における登録商標および非登録商標です。