Roblox onboarding funnels: find where players stop progressing

Start with a question rather than a chart #

Imagine a workshop where a newcomer picks up a parcel, walks to a station and receives a delivery confirmation. The creator sees short sessions and assumes the route is too long. However, the player may leave before receiving the parcel, misunderstand the button or complete delivery without noticing the reward. Total session duration cannot distinguish these situations.

Ask a concrete question: after which verifiable action do the most tutorial participants stop progressing? That question defines the event sequence before you choose a tool. Do not start by collecting as much analytics as possible. Each event should answer something about behavior, rather than merely establish that another function ran. A useful sequence explains what the player achieved and where the next investigation should begin.

The website and the game observe different actions #

Clicking Play on a website confirms a link interaction. It does not prove entry into a game server, completion of an order or receipt of an item. Measure the in-game path separately. Do not combine website visitors and game-server players into one funnel without an appropriate way to connect those observations.

This guide concerns Roblox analytics, rather than a new Yandex Metrica goal. The website counter remains unchanged. Reading a guide for a long time does not justify an in-game tutorial-completed event. Each action should be confirmed where it actually occurred. Keeping those boundaries clear makes results easier to interpret and prevents a website interaction from becoming a fictional game achievement.

Define the workshop's four stages #

Our proposed sequence is: the player enters the onboarding scenario; the server assigns the first order; the server confirms delivery; the server applies the first reward. These are original design labels, not required Roblox stages. Record a number, a stable name and a precise completion condition for each.

Displaying a hint differs from accepting an order. If you are investigating hint availability, measure its display separately, but do not substitute it for task acceptance. Likewise, spawning a chest differs from receiving its reward. The planning table should explain which server state supports each stage. That definition allows another developer to review the instrumentation without guessing what finished means.

Open full-size image ↗

Send events from the appropriate context #

Roblox documents LogOnboardingFunnelStepEvent for onboarding and LogFunnelStepEvent for other funnels. Events are sent by the server in a published game; Studio does not send them to the service. Testing your handler with a fake sender therefore does not establish that data appeared in Creator Hub.

Separate gameplay validation from analytics delivery. The server knows whether an order was assigned and a delivery accepted, and can report the corresponding stage afterward. A client request to record step four does not replace those conditions. The learning example below receives a validated stage from server logic rather than an arbitrary number supplied by a player's device. Gameplay handlers remain responsible for confirming the action. The example has not been connected to a live game.

The code below is an OnboardingObserver ModuleScript in ServerScriptService. A server Script creates observer = OnboardingObserver.new(function(player, step, name) AnalyticsService:LogOnboardingFunnelStepEvent(player, step, name) end). Call observer:RecordVerified(player, step) only after the game actually confirms that action; call observer:Forget(player) when the player leaves. The module connects no RemoteEvent and does not validate parcel delivery for you. It checks order 1–4 and suppresses repeats in its current state. true means a local call returned without an error, not dashboard delivery. After a failed send, a later stage returns OutOfOrder until the previous stage is sent successfully: inspect diagnostics without blocking gameplay rewards. State is not persistent across servers. Local Luau tests used a fake sender; no real events were sent.

At the start of the calling server Script, declare local AnalyticsService = game:GetService("AnalyticsService") and local OnboardingObserver = require(game:GetService("ServerScriptService"):WaitForChild("OnboardingObserver")). After creating observer, connect game:GetService("Players").PlayerRemoving:Connect(function(player) observer:Forget(player) end). Integrate RecordVerified into existing server handlers for confirmed actions, preserving their gameplay checks.

-- ModuleScript: OnboardingObserver, in ServerScriptService.
-- Call only from server logic after a verified gameplay action.
-- This module observes progress; it never grants rewards.
local Observer = {}
local names = {"EnteredWorkshop", "OrderAssigned", "DeliveryAccepted", "RewardApplied"}

function Observer.new(send)
    assert(type(send) == "function", "Sender required")
    local lastStep = {}
    local adapter = {}

    function adapter:RecordVerified(player, step)
        if player == nil then return false, "InvalidPlayer" end
        if type(step) ~= "number" or step ~= math.floor(step)
            or step < 1 or step > #names then
            return false, "InvalidStep"
        end
        local previous = lastStep[player] or 0
        if step <= previous then return false, "AlreadyObserved" end
        if step ~= previous + 1 then return false, "OutOfOrder" end
        local ok = pcall(send, player, step, names[step])
        if not ok then return false, "SendFailed" end
        lastStep[player] = step
        -- Local call completed. This is NOT a dashboard delivery receipt.
        return true, "CallCompleted"
    end

    function adapter:Forget(player)
        lastStep[player] = nil
    end

    return adapter
end

return Observer

Do not omit the beginning to improve the chart #

According to the documentation, a funnel begins with its first logged step. If your first event is receiving a reward, you observe only players who reached that point. You cannot conclude that everyone who joined completed onboarding: the others were outside the measured sequence.

Choose the beginning according to your question. For a complete arrival path, it may correspond to joining the server; for a particular tutorial, it may mean gaining access to that scenario. Write the definition beside the steps. Do not silently change it between versions. Otherwise two similar-looking charts describe different populations, and their differences cannot be interpreted as the effect of one tutorial improvement.

Repeated and skipped steps affect interpretation #

Roblox considers the first occurrence of a repeated funnel step, while additional logged events still use the event limit. Earlier skipped steps can be treated as completed when a later step arrives. A filled chart is therefore not automatic proof that the server sent every expected record.

Maintain an exercise log containing the action, expected step and actual logged step. Check paths where an old saved profile causes a reward to be applied automatically. That player may not have completed the new tutorial. If this represents a different situation, do not mix it with first-time onboarding or emit achievements simply to fill a report. Definitions and logs should explain the actual route.

Verify measurement before investigating abandonment #

Prepare a controlled route. One tester enters and stops before accepting an order. Another accepts it but does not complete delivery. A third completes the full scenario. For each, specify the events that should occur and those that must not occur.

Do not generate hundreds of identical visits to create an attractive chart. A small controlled test checks instrumentation; it does not characterize the ordinary audience. Mark test observations in your notes and account for them when the sample is small. These routes are a proposed test plan, not a claim that visits have already happened. Record actual outcomes separately when the appropriate published test environment is ready.

Interpret a fictional drop-off cautiously #

Suppose a fictional scenario has 100 entrants, 60 accepted orders, 45 completed deliveries and 40 received rewards. Those numbers are not statistics from our website or games. Forty participants did not advance between the first and second stages, but the four counts alone do not establish the cause.

Participants might fail to find the station, become distracted, encounter an error or decide the game is unsuitable. Next, reproduce that transition and inspect task clarity and possible failures. Do not declare the button responsible based only on the funnel. Measurement identifies a place to investigate; explaining the cause requires additional observations. Keep your hypothesis separate from what the counted actions actually support.

Compare phones and computers carefully #

Before comparing devices, confirm that they run the same tutorial. On a phone, a panel might cover the button. On a computer, a player might accidentally close a hint. These are separate testable hypotheses, rather than established conclusions about audience habits.

Roblox funnel filters apply to the first step; switching devices during the sequence does not move the entire result to another group. Account for that in your interpretation. Do not assume the final action necessarily happened on the device shown by the filter. During manual interface testing, record the tester's actual device separately. That record answers a different question from cohort attribution in the analytics view.

Change one specific thing #

Choose a testable change, such as placing the parcel explanation nearer the station, showing direction after order acceptance or making delivery confirmation more visible. These are ideas for our fictional workshop, not features added to the author's existing games.

Avoid simultaneously changing the route, rewards, prices and interface if you want to understand one adjustment. Preserve the publication date, scenario version and step definitions. Compare suitable periods and audience composition after the change. With few players, results can be unstable. No universal percentage guarantees successful onboarding for every game. Describe the actual sample and remaining uncertainty.

Open full-size image ↗

Recognize a measurement problem #

If almost everyone has a reward event but delivery events are rare, inspect ordering and skipped steps first. If different step names appear together after an update, select a period appropriate to the intended version. If no data appears, check publication, server context and whether the completion condition actually occurred.

Do not fix a report by sending invented achievements. Gameplay should follow its own rules even when analytics delivery fails: a reward is not granted because logging succeeded. Keep the game operation separate from its observation. Failure in one channel must not become fictional completion in another. A useful diagnostic explains the distinction rather than hiding it behind one generic success flag.

Prepare a handoff another developer can use #

Provide the step table, completion conditions, server call sites, release date, test plan and actual observations. List what remains unknown: unperformed checks, unverified filters, a small sample or unavailable data. Another chat can then continue without treating assumptions as findings.

This stage is ready when every step describes a clear action and delivery has been checked in the appropriate environment. That does not establish improved onboarding or increased retention. The article explains measurement design and the investigation cycle. Preparing this draft did not change a live game's analytics or the website's goals. Any later implementation requires its own validation and evidence.