Game Events: the new tool for understanding your players
Do your players behave the way you think? Meet Game Events, a new P4D analytics tool for understanding player behavior and testing your assumptions.
When you're building a game, it's easy to make assumptions about your players.
Maybe they're dropping off because a level is too difficult. Maybe a feature isn't appealing enough. Maybe the first object, upgrade, or mechanic you introduce is obviously the right one.
But without data to back those assumptions up, it’s hard to know if you’re right.
That's why we built Game Events, a new analytics tool in Poki for Developers (P4D) that helps developers understand what players actually do inside their games.
When player behavior challenges your assumptions
While developing Smash Room, Jim had three possible objects players could encounter first: a phone, a glass, and a cake.
His instinct was to start with the phone, thinking it would be the most relatable and satisfying object for players to smash, especially with the visual effect when it broke.
Instead of relying on that instinct, he randomized the three opening objects across players and used Game Events to measure how many players were still playing after three minutes.
Three minutes in, here’s how each opener performed:
- Glass: 33.7%
- Cake: 27.4%
- Phone: 23.8%
Turns out the ‘glass’ object had more appeal and ‘phone’ was the least effective of the three.
That's a small experiment with a useful consequence. Rather than debating which opener felt strongest, Jim could see which one actually kept more players playing.
Why we built our own analytics tool
There are plenty of analytics products already available. So why did we build another one?
Analytics for games on the web has some particular challenges.
Third-party analytics tools aren't designed around how games run, load, restart, and generate sessions on the web. The way data is collected and interpreted can differ from native apps, and that can make seemingly straightforward metrics harder to reason about.
Game Events sits directly within Poki's own ecosystem. The events are sent through the Poki SDK, while commercial and rewarded ad playback is already tracked automatically through existing SDK calls.
That means we can read events alongside the platform data we already collect. No reconciling two separate analytics systems.
Game Events also lives inside P4D. You don't have to treat behavioral analytics as an isolated dashboard. You can look at Game Events alongside your game versions and other Poki tools, making it much easier to connect the changes you make with changes in player behavior.
How Game Events works
At a high level, Game Events are analytics checkpoints you place at meaningful moments in your game.
With the Poki SDK's measure() function, an event has three parts: a broad category, the specific thing you're measuring, and an action describing what happened.
A level-based game could measure when players:
level → 5 → start
level → 5 → complete
level → 5 → fail
A game with a booster could measure:
booster → freeze → visible
booster → freeze → interact
If your game has mechanics that don't fit neatly into those patterns, you can create custom events for things like selecting a difficulty, spending currency, crafting an item, or reaching a particular milestone.
milestone → first-upgrade → reached
difficulty → hard → selected
You don't have to wait until your game is live to benefit from Game Events. During development and testing, it can help validate player flows and uncover issues early, giving you more confidence before submitting your game or an update for review.
Once those events are coming in, you can analyze them individually or combine them into custom Funnels to understand how players move through a particular journey.
Read the Game Events implementation guide
Turn individual events into player journeys with Funnels
Individual events can tell you what happened at a specific point. Funnels help you understand what happens across a sequence of them.
You can build custom funnels from your Game Events to follow the journeys that matter for your game and see how many players make it from one step to the next.
An onboarding funnel can reveal where new players decide not to continue. A level progression funnel can expose a level causing unusual drop-off. A feature adoption funnel can show how many players actually reach and engage with something you just released.
Because every game is structured differently, we don't prescribe what those journeys should look like. You choose the events and steps themselves, then save funnels to revisit or compare across different game versions.
Find where players are leaving
One of the most straightforward uses for Game Events is progression.
By tracking starts, completions and failures across levels, rounds, quests, or tutorial steps, you can see exactly where players begin to disappear.
That's what Erçin did with Satisbox Mini Games. The game contains many independent mini-games, and its average session time was around 4:50. He knew players were leaving earlier than he wanted, but not exactly where.
Once he started tracking progression with Game Events, some problem areas became immediately visible. Levels 1 and 2 were losing more than 15% of players, while Level 5 had one of the strongest completion rates.
Instead of redesigning everything, he changed the order. Stronger mini-games moved earlier in the progression. Weaker ones moved further back.
After the first update, average session time went from 4:50 to 5:43.
He collected more data, looked again at which mini-games encouraged players to continue and which coincided with exits, and reordered the progression a second time.
Average session time increased again, this time to 6:23.
The best part? I didn't have to guess. Game Events showed exactly where players were leaving, making it easy to validate every improvement and make smarter design decisions.
More than a minute and a half of additional average playtime. From changes guided by understanding where players were actually leaving.
Understand what’s behind player drop-off
A spike in player drop-off can point to issues beyond difficulty or game balance. Jim ran into this in another game, Stickman Fury.
A small number of players reported getting "stuck in the ground" at certain levels. Reports alone weren't enough to identify a pattern, so he looked at the Game Events data.
He found abandonment spikes at 17 specific stages, all of them after stage 56. No equivalent spikes before it.
At first, this seemed to point to a difficulty curve issue. It wasn’t.
Stage 56 was where the game runs out of authored levels and starts replaying them mirrored - which was the key finding to help fix the bug.
The data alone can't tell you there's a bug. But the pattern it revealed helped Jim narrow down the problem and eventually find it.
See whether players actually use the things you build
Progression is only one part of the picture. Game Events can also compare visibility with interaction.
Say you've added a booster. You can measure how many players were shown it and how many actually used it.
If 80% of players see a feature but only 3% interact with it, that’s a very different problem from only 10% of players ever seeing it. In the first case, you might question the feature itself, its value, or how well it's communicated. In the second, you might need to rethink the discoverability and placement.
The same approach works for shops, upgrades, character unlocks, power-ups, hints, rewarded opportunities, and other UI elements.
You can also go further with custom events. Measure which difficulty players choose, when a particular currency is spent, whether someone completes a crafting action, or when they hit a first-time milestone. The right events depend on your game.
Start with what you want to learn
As tempting as it can be to add events for every player action, it's more useful to start with a specific question. For example:
“Where are players leaving?”
Track progression.
“Are players noticing and using this booster?”
Track visibility and interaction.
“Which opening experience keeps people playing?”
Run an experiment and tag the different variants.
“Is this level actually too difficult?”
Look at starts, failures, completions and what happens immediately afterwards.
“Are players encountering our rewarded opportunities?”
Measure the placement's visibility and interaction, while Poki's SDK handles tracking the ad playback itself.
Build, measure, learn, repeat
Game development starts with intuition. Game Events helps you validate and refine those instincts with player data.
Sometimes your hunch is right. Sometimes a glass beats the phone you were convinced was the better opener. Sometimes what looks like a difficulty spike turns out to be a bug. And sometimes moving a few pieces of existing content around can increase average session time from 4:50 to 6:23.
The better you understand how players behave, the easier it is to decide what to improve next.