Find a first-session drop-off by defining the player journey, recording a small set of meaningful milestones, and checking which players reach each one in order. Validate event delivery before treating missing events as player behavior. A funnel can locate a step to investigate; it does not, on its own, explain why players leave.
The event map and counts in this article are proposed and synthetic. They are not measurements from an Agentium game, a retention benchmark, or a promise about the effect of an onboarding change.
Define what “first session” means in your game
Choose the start and end boundaries before comparing numbers. A first app open, an account’s first session, and a player’s first attempt at a level describe different groups. Reinstalls, account switching, interrupted sessions, and offline play can complicate each definition.
For this example, imagine a new installation reaching the main menu, beginning a tutorial, finishing it, and attempting the first level. Document how a returning installation is excluded and how the session ends. If the available identifiers cannot support that distinction reliably, label the cohort accordingly.
Do not quietly change the cohort definition between two builds. You could otherwise attribute a measurement change to the tutorial when the underlying population changed.
Map the few milestones that answer a question
Start with a question such as: are players reaching the first playable level after the tutorial? Record the events needed to answer it before collecting every tap.
| Milestone | Proposed event | Important context |
|---|---|---|
| Main menu ready | menu_ready | Build version, platform, session reference |
| Tutorial begins | tutorial_begin | Tutorial version |
| Tutorial completes | tutorial_complete | Tutorial version, completion path |
| First level starts | level_start | Level identifier, attempt reference |
| First level ends | level_end | Same attempt reference, outcome, level identifier |
Google Analytics documents recommended events including tutorial and level events. The menu event and field names above are a proposed application design, not a universal analytics-provider contract. Check the requirements of the SDK you use.
Avoid personal text, free-form player messages, or unnecessary identifiers in the event payload. Decide how consent and regional requirements affect collection before enabling the map in a real release.
Test the event map before reading a funnel
Walk through the game while inspecting event output in the SDK’s development tools or your own test sink. Confirm when each event fires, which values it carries, and whether the same action can send it more than once.
Include cancellation, backgrounding, reconnecting, retrying a level, and closing the app during the tutorial. Verify that an attempt reference links one level start to the corresponding end instead of mixing several retries.
Record known delivery gaps. A missing level-end event might mean a player left, a device went offline, or the code never sent the event. Those possibilities require different investigations.
The example event map includes a validation checklist. It is a design artifact, not a tested SDK integration.
Use the same unit at every step
For an ordered first-session funnel, count eligible sessions that reached each milestone, not the total number of event messages. A player restarting a tutorial can generate several events without representing several new players.
Here is a deliberately synthetic illustration, with no real player data:
| Ordered milestone | Eligible sessions reaching it | Share of the initial 100 |
|---|---|---|
| Menu ready | 100 | 100% |
| Tutorial begins | 80 | 80% |
| Tutorial completes | 50 | 50% |
| First level starts | 45 | 45% |
In this invented example, 30 of the 80 tutorial starters do not have a later completion event within the defined funnel window. The tutorial completion rate among starters is 50 divided by 80, or 62.5%. That differs from the 50% share of the initial menu cohort.
Keep the denominator beside the metric. Otherwise, two people can discuss “tutorial conversion” while using different populations.
Investigate the step without assuming the cause
The synthetic gap between tutorial start and completion suggests where to look next. It does not prove that the tutorial is too long. Players may encounter a crash, confusing controls, an inaccessible prompt, a loading problem, or an event-delivery failure.
Inspect the game flow and relevant technical evidence. Segment by platform and build where the sample supports it, and check whether the event change coincided with a code release. Avoid turning a tiny segment into a confident explanation.
Acquisition also matters. A campaign may bring players expecting a different type of game. If the population changes between builds, an onboarding comparison needs to account for that change before claiming an improvement.
Choose one change and one review rule
Write an experiment hypothesis tied to an observed problem. For example: if a particular instruction is unclear, a clearer prompt may help players reach the next step. Define the intended metric and any important guardrail, such as crashes or failure to load.
Choose the comparison method, eligibility rules, and stopping or review criteria before interpreting the outcome. This article does not prescribe a universal sample size or minimum lift. Those depend on the design, traffic, uncertainty, and consequences of a mistaken decision.
Start by validating one event map. A small map you can explain is more useful than a dashboard whose events nobody has checked.