When we started developing Dinopirates from Inner Space, we made design decisions based mainly on intuition and direct feedback from people playtesting internally. That works up to a point, but has a clear limit: intuition doesn’t scale, and direct feedback is hard to get in volume.

Analytics exist to give structure to that process. Not to replace design judgment, but to support it with real evidence of how people interact with a product.

The classic case: e-commerce

The most intuitive way to understand analytics in a digital product is by looking at how they’re used in e-commerce, where they’ve been perfecting the practice for decades.

When someone enters an online store, they follow a predictable path: they see an ad, land on the site, browse products, add something to the cart, and —ideally— buy. That path is called the customer journey, and in e-commerce every step is measured with precision.

Why does measuring it matter? Because at some point along that path, people leave. And knowing where they leave completely changes what problem you need to solve.

If 80% abandon on the product page, the problem is the presentation or the price. If they abandon at checkout, it may be friction in the payment process. If they abandon in the cart, maybe shipping is expensive. Without data, you can only guess which of those is your real problem.

In video games, exactly the same logic applies, with the game as the product and the player as the customer.

The customer journey in a video game

The equivalent in games is the path a player takes from opening the game for the first time to becoming someone who finishes it, recommends it, or keeps playing weeks later.

Every game has its own journey depending on its genre and mechanics, but the structure is similar:

Do they reach the core loop?  →  Do they understand it?  →  Do they try again?  →  Do they get hooked?

The question that guides analytics design is: at what point of that path do people drop off?

The Dinopirates funnel

For the Dinopirates Playtest, we defined a simple conversion funnel with four milestones:

Game Started → First Raid → Second Raid → Survey

Each of those milestones answers a specific question:

Game Started → Did the player open the game and get past the initial screen? This event comes for free with Unity Analytics — no additional code required.

First Raid → Did they understand the game well enough to jump into their first Raid? If many players stay in the main menu without entering a Raid, there’s an onboarding or loop communication problem.

Second Raid → This is the most revealing milestone. A player who dies in their first Raid and decides to try again is showing that the game generated enough interest to keep going. The conversion between First and Second Raid tells us whether the core loop is hooking people.

Survey → For the Playtest, filling out the survey is our final conversion event. It tells us which players reached the point of having a formed opinion about the game.

Four events, four clear questions. We don’t need to measure everything to make useful decisions.

Beyond the funnel: aggregated player data

In addition to conversion events, Unity Analytics automatically delivers aggregated information about who your players are. This is valuable for different reasons: it doesn’t tell you how they play, but rather in what context they do.

With the base integration, without defining any custom events, you can see:

  • Countries — where players are from. Important for language decisions, launch schedules, or campaigns.
  • Operating system — distribution of Windows, macOS, Linux in your user base.
  • Hardware — what CPUs and GPUs players use. Essential for knowing if your performance adjustments make sense for your real audience. If 60% of your players have a mid-to-low-range GPU, optimizing for high-end is the wrong priority.

In Dinopirates’ case, knowing the hardware distribution from the Playtest helps us calibrate performance targets before an eventual Demo launch.

Measuring to decide

The central idea of this article is simple: analytics are a tool for making better decisions, not an end in themselves.

The workflow that works for us:

  1. Question first: what do we want to know? Example — how many Playtest players try a second Raid?
  2. Identify the milestone: in this case, the secondRaidStart event.
  3. Measure: let the Playtest run and observe the conversion rate.
  4. Decide: if the number is low, something isn’t working between the first and second Raid. If it’s high, the core loop is doing its job.

Without that prior question, data is noise. With it, it’s actionable information.

In the next article we cover the technical side: how to implement Unity Analytics in your project, how to handle user consent correctly, and what data you get with the base integration.