A/B test a game change
Split players between the current version and a change, read the variant on the game server, and let the results tell you whether to ship it.
You think a shorter tutorial will get more new players to the fun part. Instead of shipping it to everyone and comparing this week with last week (a different week, different players, maybe a holiday), split new players in two and compare them on the same days. This guide runs that test end to end.
Track the goal
An experiment needs an event that says "it worked". Here that's tutorial_completed, sent from the server when a player finishes. Revenue comes for free from $purchase.
RoChart.track(player, "tutorial_completed", { seconds = os.clock() - startedAt })If you followed the onboarding guide, you already have it.
Create the experiment
Experiments → New experiment, or describe it in a sentence:
Does a 3-step tutorial instead of the current 6 steps get more new players to finish it?
Check the plan RoChart drafts:
- Who sees it: everyone, split 50 / 50 between
controlandshort, on a new flagshort-tutorial. - Primary metric: % of players who do
tutorial_completedwithin 1 day. - Secondary metrics: sum of
$robuxon$purchaseper player within 7 days, so you notice if the shorter tutorial costs you revenue. - Segments: platform, or a cohort such as Premium players, to see whether phones react differently.
Save it as a draft for now.
Read the variant on the server
Read the flag where the experience starts, when the tutorial begins, not when the player joins. Everyone who reads it counts as exposed, so reading it on join would dilute the result with players who never reached the tutorial.
local RoChart = require(game.ServerScriptService.RoChart)
local function startTutorial(player)
if RoChart.getFlag(player, "short-tutorial") == "short" then
runTutorial(player, SHORT_STEPS)
else
runTutorial(player, FULL_STEPS) -- "control", or the flag is off or unknown
end
endThe flag is evaluated per player on the game server, so a player can't change their variant from the client. The same player always gets the same variant, on every server and device. Anything that isn't "short" takes the current path, so the game keeps working if the flag is off.
Publish the place, then Launch the experiment. Old servers keep running the old code until they shut down, so give it a few hours, or use Shut Down All Servers if you want everyone on the new version.
Read the results
Results update continuously, and looking early doesn't invalidate them:
Experiment "Short tutorial" (running). Exposures: control 4,212, short 4,190.
Primary: tutorial_completed — control: 38.1% (n=4212); short: 47.9% (n=4190) lift +25.7% [19.8%, 31.9%], P(beats control) 100.0%. Verdict: winner (short).
Segment "Phone": tutorial_completed — … lift +34.0% [24.1%, 44.6%], P(beats control) 100.0%. Verdict: winner (short).
Recommendation: Ship "short": it is the best variant with 100.0% probability.Check the secondary metric before you ship. A tutorial that more players finish but that skips the shop might bring in less Robux. See Read results.
Ship the winner
Conclude the experiment and roll short out to everyone through the same flag. The code doesn't change. Later, when you remove the old tutorial, delete the flag check too.
Other things worth testing
- Prices: a 99 vs 149 Robux starter pack. Primary: % of players with a
$purchaseof that product; secondary: Robux per player. - Rewards: a daily reward on day 2. Primary: % who
daily_reward_claimedagain within 7 days. - Matchmaking or difficulty: primary: % who play a second
match_endedwithin the session.
Keep one primary metric per test, and pick it before launch. Or hand it to your agent with the experiment prompt on Create an experiment.