Game Analytics for Indie Devs: 8 Metrics That Matter

For an indie game, eight numbers carry most of the signal: day-1 retention, day-7 retention, DAU/MAU stickiness, median session length, tutorial completion, per-level quit rate, crash-free sessions, and store page conversion. If you track nothing else, track these. Day-1 retention is the first among equals, because it answers the question every other metric depends on: did the game you shipped earn a second session?

This article explains what each of the eight means, what a healthy reading looks like, and how to collect all of them with free tools in an afternoon. It is the deeper half of the "read the numbers" loop in the post-launch strategy guide: that article tells you when to read; this one tells you what. (One honest note up front: Egmatic, the no-code editor this blog belongs to, is pre-alpha and exists to shrink the fix-and-re-ship half of this loop; more on that at the end.)

The short answer#

Your question	Metric	A healthy signal
Did the first session earn a second?	Day-1 retention	Around 40% is the classic bar; your own trend is the real judge
Is there a habit forming?	Day-7 retention	Around 20%; web games often run lower
Is the game sticky, not just visited?	DAU/MAU	Rising while the audience size holds
Does pacing hold attention?	Median session length	Close to the session you designed
Where does onboarding lose people?	Tutorial completion	The exact drop-off step is visible
Which level kills the run?	Per-level quit rate	No level spikes above its neighbors
Is the build technically clean?	Crash-free sessions	Far from Google's 1.09% bad-behavior line
Does the page sell the game?	Store conversion	Improving after each store-page change

Two ideas keep this table honest. First, benchmarks orient, cohorts decide: the industry numbers below tell you which league you are in, but only comparisons of your own weeks tell you what to fix. Second, every metric exists to trigger an action. A number you cannot act on is decoration.

The eight metrics#

1. Day-1 retention#

The share of players who start the game on one day and come back the next. It is the cheapest diagnosis of the first-play experience: a low number means the promise of the store page and the reality of the first minutes disagree. The widely used shorthand for a healthy curve is 40/20/10, and day 1 is the 40. GameAnalytics' own retention guide is careful to call that shorthand a baseline rather than a law, so calibrate by genre: a premium puzzle game should beat it, a hyper-casual web toy may run far under and still be fine.

If day-1 retention is low, the fix is almost never "more content". It is the first three minutes: load time, the first thing players can do, and whether the core loop is legible without a tutorial wall. Your game loop design is what this metric grades.

2. Day-7 and day-30 retention#

The same measurement further out: of the players who started on day zero, how many show up on day 7 and day 30. Day 1 tests the first impression; day 7 tests whether anything in the game pulls people back, and day 30 tests content depth. In the 40/20/10 shorthand these are the 20 and the 10. A game can hold a strong day 1 and a weak day 7; that shape usually means the loop is fun once but offers no reason to return, which is a design problem, not a marketing one. Features that create return visits, such as a proper save system, move this number.

3. Stickiness (DAU/MAU)#

Daily active users divided by monthly active users. The result reads as "what share of my monthly audience plays on a normal day", and it strips out audience size, which is why it is the fairest single number for a growing game. A game can double its downloads while stickiness falls; that shape means the store page is winning and the game is losing. Track the ratio weekly against your own past, because absolute stickiness targets vary too much by genre to be worth arguing about.

4. Median session length#

How long a typical session lasts, taken as a median, never an average: one 90-minute session among 20 two-minute sessions drags the average to nonsense. Compare the median against the session you designed. A game built for ten-minute runs with a two-minute median is losing players in a specific place, usually the first fail state or a difficulty wall, and the next two metrics tell you where.

GDevelop's built-in analytics shows this plainly: its dashboard counts a viewer as a player after 60 seconds and reports average minutes per player alongside the share of players passing 3, 5, 10 and 15 minutes. That last graph is session length turned into a curve, and it is the right shape to look at.

5. Tutorial completion#

Of the players who begin your tutorial or onboarding, the share who finish it. It is the first funnel in every game and the cheapest one to fix, because the drop-off localizes the problem to one screen or one instruction. GA4's event reference already names the two events for exactly this funnel, tutorial_begin and tutorial_complete, alongside level_start, level_end and level_up, so the vocabulary costs you nothing. If completion collapses at a specific step, film five players at that step; you will see the problem inside an hour, and it is rarely the one you expected.

6. Per-level quit rate#

For each level, the share of sessions that start it and never reach the next one. This is the metric that catches difficulty spikes and softlocks your playtesters were too good to hit. Two events per level, start and end with a success flag, are enough; GA4's level_start and level_end names them for you, and GameAnalytics structures the same idea as progression funnels. Read it as a bar chart across levels: the bars should undulate gently. One bar towering over its neighbors is either your hardest level working as intended or the place your game leaks players, and review scores will usually tell you which.

7. Crash-free sessions#

The share of sessions that end without a crash or hang. On mobile this is also a store matter, not only a quality one: Google Play defines bad behavior as at least 1.09 percent of daily users experiencing a user-perceived crash, or 0.47 percent hitting an app-not-responding error, with a separate 8 percent line per device model, and staying on the wrong side of those lines drags discoverability down. The same thresholds make a free target: keep crash-free sessions as close to 100 percent as you can hold, and check the per-device view, because one device model can burn while the aggregate looks healthy. Crash data lives in the store consoles (Android Vitals, Xcode Organizer) before it lives anywhere else, so this metric costs no SDK at all.

8. Store page conversion#

Of the people who see your store page, the share who wishlist, download or buy. Every store reports its half of this: Steam's partner dashboard has dedicated wishlist and traffic reporting, Google Play and the App Store give impressions-to-installs, and itch.io shows views and downloads per project. Conversion is where marketing work and game work meet: if retention is healthy and conversion is poor, the page is the product, and store-page experiments are the highest-leverage fixes available, which is App Store optimization territory. During a launch, watch conversion daily; the launch day checklist has you record the baseline this compares against.

The tools, honestly compared#

Tool	Where it runs	Cost	What it gives you
Google Analytics 4	Web builds: itch.io embeds, gd.games pages, your site	Free	Full event model, recommended game events, funnels
Firebase Analytics	Native Android and iOS	Free	Same event model as GA4, with an SDK
GameAnalytics	Engine SDKs: Unity, Unreal, Godot, Construct, GameMaker, Defold, Flutter, plus a REST API	Free core, no MAU cap	Design-, progression- and funnels-first framing
GDevelop built-in analytics	Games published to gd.games	Sessions free; deeper metrics with a subscription	Sessions, 60-second bounce, minutes per player
Store dashboards	Steam, Google Play, App Store, itch.io	Free	Traffic, wishlists, installs, sales, crashes, Vitals

Three of these you already have: every store dashboard is included with the account you publish through, and GDevelop games report sessions with zero setup. That leaves one decision. If your game runs in a browser, GA4 is the default because the page can load a script. If it ships to mobile stores and you want design-shaped reports rather than raw events, GameAnalytics covers the no-code engines people actually use, Construct and GameMaker included, on a free tier with no cap on monthly active users.

Instrument a first game in an afternoon#

1. Write down the six events. game_start, tutorial_begin, tutorial_complete, level_start, level_end with a success flag, and one economy or progression moment. If a question matters that these six cannot answer, add a seventh then, not before.
2. Match the tool to the surface. Browser build: GA4. Mobile build: Firebase or a GameAnalytics SDK. GDevelop game: the dashboard already counts sessions. Store presence: the dashboard you already log into.
3. Verify in debug before launch. GA4's DebugView, a GDevelop preview session, or a GameAnalytics development build. The event that never fires is the one you discover two weeks after launch; spend ten minutes and find it now.
4. Record the day-one baseline. Units, wishlists, review average, crash counts, traffic sources. Every later reading is a comparison against this snapshot, the same discipline the post-launch strategy guide runs on.
5. Read weekly, decide one fix. Fifteen minutes, same weekday: retention trend, one funnel, crash line, conversion line. Then one change, shipped. Analytics that never ends in a shipped change is expensive astrology.

Common mistakes#

• Benchmark worship. 40/20/10 orients you; your own cohorts decide. A hyper-casual web game at 25% day 1 may be healthy; a premium puzzle game at the same number is a fire.
• Averages instead of medians. Session length and time-to-fail are median questions. One engaged friend in the data will otherwise veto the truth of a hundred bounces.
• Forty events on day one. Every event you add costs attention forever. Six events that each trigger a decision beat forty graphs nobody opens.
• Counting sessions as players. A session is a visit; a player is a person. GDevelop's 60-second threshold is one honest convention for the boundary; decide yours once and keep it fixed.
• Watching installs. Installs measure the store page and your marketing, not the game. Retention measures the game.
• No baseline snapshot. Without a day-one number for wishlists, conversion and crashes, week two has nothing to compare against and every trend becomes an opinion.
• Instrumenting after launch. The first cohort, the players who bought at launch, is the most valuable one you will ever get, and it cannot be re-collected later.

How Egmatic fits#

Every section above ends the same way this paragraph will: the number tells you what to change, and then the change has to reach players. That re-ship step, exporting a build, uploading to each store, waiting on review, updating listings, is where indie analytics goes to die, because the loop costs an afternoon and so simply stops being run. Egmatic is a no-code 2D editor and engine built on AI, currently pre-alpha, and its purpose is to make that loop cheap: you direct the fix, the editor and its publishing layer execute it, and the game you keep improving is the game that keeps its numbers. We are not claiming a magic dashboard; the claim is smaller and testable, that measuring, fixing and re-shipping should be one motion rather than three jobs. If that is the workflow you want, watch the pre-alpha take shape and join the waitlist at egmatic.com.

Where to start tomorrow#

Add the six events to whatever build is current, even if launch is months out. Open the store dashboard you already have and write down today's numbers next to the date. Put a 15-minute weekly read on the calendar and let it end in one shipped change. If the game in question is your first, the first mobile game guide covers the same loop with less machinery, and when money enters the picture, the metrics change shape, which is what the monetization guide is for.

Sources#

1. GameAnalytics — How to think about retention in games: the 40/20/10 shorthand, its non-universality, updated April 2026
2. Google Analytics Help — Recommended events: tutorial_begin, tutorial_complete, level_start, level_end, level_up and other suggested game events
3. GameAnalytics — SDK documentation (engine SDKs including Godot, Construct and GameMaker) and pricing (free core tier, no MAU cap)
4. GDevelop Wiki — Game analytics: 60-second player threshold, bounce rate, minutes-per-player, subscription split
5. Google Play Console Help — Monitor technical quality with Android Vitals: 1.09% user-perceived crash and 0.47% ANR bad-behavior thresholds, 8% per-device line
6. Steamworks Documentation — Wishlist reporting and Traffic reporting