Most indie developers don’t think about analytics until something goes wrong. A game ships, reviews are mixed, players are dropping off somewhere, and suddenly everyone’s guessing. Was it the tutorial? The difficulty spike in level three? The shop UI? Nobody knows, because nobody set up the tools to find out.
Here’s what I tell people who are just starting to think about this: analytics isn’t a “big studio” thing. It’s not overkill for a two-person team. It’s actually more important for small teams, because you don’t have the budget to iterate blindly. Every build cycle costs you time you can’t get back.
What you actually need to measure (and what you don’t)
Before you touch a single SDK, get clear on your questions. This sounds obvious. It isn’t. I’ve watched teams instrument 40 custom events, generate a CSV the size of a phone book, and then stare at it with no idea what to do next.
Start with three questions that would genuinely change a decision you’re about to make. For most indie games, those are: Where are players stopping? How long is a first session? And what percentage of players who start the tutorial actually finish it?
Retention and session length matter most. Almost everything else is decorative until you’ve nailed those two. If your Day 1 retention is below 30%, no amount of monetization data is going to save you. Fix the experience first.
Funnels are where most teams get the most immediate value. A funnel is just a sequence of events you expect players to hit in order: launched game, completed tutorial, reached first level, opened shop. Each drop-off point tells you something. A 60% drop between “launched game” and “completed tutorial” is catastrophic. A 15% drop between “opened shop” and “made first purchase” might be totally acceptable, depending on your monetization model.
Don’t instrument for completeness. Instrument for decisions.
Choosing your tools without overthinking it
| Tool | Free Tier Limit | Best For | Setup Complexity |
|---|---|---|---|
| GameAnalytics | 5 billion events/month | Solo devs, small teams, premium/F2P mobile | Low |
| Unity Analytics | Restrictive (varies) | Existing Unity ecosystem | Low |
| Amplitude | 50,000 monthly tracked users | Live-service, web presence, marketing funnels | High |
| Mixpanel | Varies by plan | Custom queries, SQL-style analysis | High |
Most indie teams should start with GameAnalytics. It’s free, it has a Unity SDK and an Unreal SDK, it handles up to 5 billion events per month on the free tier (which you will never hit), and the dashboard is genuinely readable by humans. I’ve set it up in a weekend project and had data flowing within a couple of hours.
If you’re already in the Unity ecosystem and want something tighter, Unity Analytics (now part of Unity Gaming Services) works fine. But the free tier limits have gotten more restrictive over the last couple of years and the pricing for larger studios has gotten messy. Worth knowing about, not necessarily worth defaulting to.
For more complex needs, Amplitude is excellent. It’s what you’ll use if your game has real live-service components, a web presence, or a marketing funnel you need to connect to in-game behavior. The free tier supports up to 50,000 monthly tracked users, which covers most indie launches comfortably. The tradeoff is that Amplitude is built for product analysts, not game developers, so the setup takes longer and the mental model is different.
Mixpanel is in the same category as Amplitude. Slightly different pricing structure, similar power. I’ve used both. If you’re comfortable with SQL-style thinking and you want to build custom queries, Mixpanel’s JQL is nice. If you’re not, it’s a headache you don’t need.
My actual recommendation for a solo dev or tiny team shipping a premium or free-to-play mobile game: GameAnalytics first. Upgrade to Amplitude if you start making real money and need to understand your funnel at a deeper level.
Setting it up without sinking a sprint into it
A lot of producers hesitate here. They know they want analytics, but they’re afraid it’ll eat a week of dev time they don’t have. It won’t, if you’re disciplined.
Here’s roughly how to approach the initial integration:
Add the SDK to your project. For GameAnalytics in Unity, it’s a package you pull through the Package Manager or download from their site. The initialization is maybe 10 lines of code. Point it at your game key and secret key (both generated when you create a project in their dashboard), call GameAnalytics.Initialize() in your startup scene, and you’re collecting basic session data immediately.
Define your event taxonomy before you write any tracking calls. Decide on a naming convention and write it down somewhere your whole team can see. Something like [feature]:[action]:[detail] works well: tutorial:completed:true, level:started:3, shop:opened:mainmenu. The specific convention matters less than the consistency. Inconsistent event names are the single fastest way to end up with useless data.
Instrument your funnel first. Not your wish list. Your funnel. The five to eight events that represent the critical path through your core loop. Ship that. Look at the data for two weeks. Then add more.
One thing I’ve seen go sideways: teams who add analytics right before launch and then have no baseline. You want to be running analytics during playtesting and soft launch, so you have something to compare against when the real player data comes in. Even a small closed beta with 50 people gives you reference points.
Reading the data without lying to yourself
Sources
- Rajat Yadav
- is going to save you
- flowing within a couple of hours
- immediately
- for two weeks
Data can be comfortable. You can look at your average session length and feel good about it while completely missing the fact that a tiny percentage of power users are inflating the number and most players are bailing in under two minutes.
Segment your players. New users vs. returning users. Platform splits if you’re on multiple platforms. Paid vs. organic acquisition if you’re running ads. GameAnalytics does basic segmentation automatically. Amplitude makes it easy to build custom segments. The point is: aggregate numbers hide things. Medians are often more honest than averages.
The other trap is confirmation bias. You set up a funnel, you see a drop-off at the point where you already suspected there was a problem, and you immediately conclude the data confirms what you knew. Maybe it does. But also check whether the drop-off is consistent across all device types, all acquisition sources, all play sessions. Sometimes a “tutorial drop-off” is actually an Android-specific crash you don’t know about yet.
Firebase Crashlytics (free, integrates with Unity and Unreal via the Firebase SDK) alongside your analytics tool is worth setting up at the same time. Crashes and drop-offs can look identical in a funnel. Knowing which is which changes your response entirely.
Photo: Rajat Yadav via Pexels
Jordan Lee





