Rebuilding funnels for GameAnalytics. Power users had abandoned our funnels and rebuilt them in Excel. I led the rebuild that won them back, starting from what they had already designed.
The problem. GameAnalytics is one of the most used game analytics platforms in the world, serving everyone from solo indie developers to publishers with billions of downloads. Funnels were among its most used features. And its most sophisticated users were abandoning them.
One studio had given up on the UI entirely. They exported raw funnel data and rebuilt the entire visualization themselves in Excel. That is the clearest signal a product can send: the people who need the feature most had decided it was easier to rebuild it than to use it.
As part of a total platform redesign, I led the funnels rebuild with a mandate to ship a beta for live testing with real studios.
The evidence. I ran the investigation on three fronts, in a deliberate sequence: production data first to shape the questions, interviews to explain the behavior, market research to find the strategic gap.
Production data. I exported the 1,000 most recent funnels and queried them with Google Scripts. Three findings anchored everything that followed:
- 84 percent of all funnel events were progression events
- Average funnel length was 18.5 steps, median 13.5
- 34 percent of funnels used filters, with build and country by far the most common
User interviews. Using customer support data, I identified developers, studios, and publishers who had recently asked about funnels and scheduled calls where they screen-shared their actual process. The production data let me ask precise questions instead of open ones. What came back:
- Funnels needed at least three iterations per game, across many games running simultaneously
- Processing could exceed 15 minutes, breaking flow and forcing context switches
- The creation form did not match the SDK event structure, causing constant confusion
- Logical operators were invisible, so users could not tell what their funnel actually computed
- The visualization gave no overview and required long horizontal scrolling, making results impossible to share in Slack or paste into a meeting deck
- Filters were hidden behind a modal
- Integration docs led teams into inconsistent event naming conventions
And then the Excel studio. I got their permission to share their homegrown report with other users. The response was overwhelmingly positive. Users had already designed the visualization they wanted. My job was to recognize it.
Market research. Competitor funnel features were generic conversion funnels, built for e-commerce flows of four or five steps. Their horizontal column charts physically could not handle an 18-step game progression funnel. No funnel tool specific to game design existed anywhere. We would be building the first one.
The strategic call. The interviews surfaced two jobs: measuring player progression, and tracking monetization, like which ad placements were most profitable. Monetization is the revenue story, and it was tempting.
We cut it from version one.
Progression was the dominant topic in every design partner conversation, and the production data confirmed it: 84 percent of events. Partners were reasonably satisfied with their existing monetization tracking, while progression was where they were building Excel workarounds. The beachhead was clear. I would rather ship the thing five studios were desperate for than over-engineer a first version chasing a use case they were only mildly interested in improving.
Decisions traced to evidence.
A heatmap adapted from the studio's Excel report. Dense, scannable, screenshot-friendly. It splits by the dimensions the data said mattered, build and country, with lazy loading so dimension splits would not explode server cost.
Progression-only mode. For the 84 percent case, a dedicated mode adding per-level detail that a generic funnel could never show.
A creation form that mirrors the SDK. Each step reads as a regular sentence, in the exact structure of the event the SDK fires. This closed the gap between what developers wrote in code and what they built in the UI, and made logical operators visible instead of implicit.
CSV import for bulk creation. Studios ran three or more iterations per game across many games. They planned all of it in spreadsheets. Spreadsheets were the universal power tool, so instead of fighting that, I built a bridge to it.
A visible filter flow. Filters moved out of the modal into the open, designed as a pattern to roll out platform-wide, not just in funnels.
The principled cut. We descoped a spreadsheet-mimicking inline editor to hit the beta. This looks like it contradicts the spreadsheet insight. It is the opposite. Users already had a planning tool they trusted. Rebuilding Excel inside our product was expensive front-end work that replaced something that already worked for them. The principle: do not rebuild what already works for the user, bridge to it. CSV import was the bridge, and it made the editor unnecessary for launch.
The outcome. We rolled the beta out partially first, to five design partners, the same studios and publishers from the research, including teams that had abandoned the old UI.
All five adopted it immediately. More telling than adoption: every one of them migrated their existing funnel tracking off their workarounds, the data exports and homegrown Excel dashboards, onto the new feature, running multiple funnels on real production data. Teams do not move live tracking onto a tool they do not trust.
I will be straight about what I do not have: an instrumented conversion metric. The platform was not measuring its own feature usage rigorously, and I pushed product leadership directly to change that. My interim role ended when the lead designer I was covering returned from parental leave, and I moved back to my family in Stockholm before longitudinal numbers existed. The evidence I stand on is behavioral: five sophisticated teams voluntarily migrating live workflows, immediately.
What I would do differently. One decision I am genuinely unsure about, and it was not mine alone.
We could have tested the core hypothesis, that game-specific funnels change behavior, far more cheaply. A headless first version: users keep planning in Excel, upload a CSV, and we render the visualization. No drag-and-drop builder, no expensive creation UI. Their spreadsheet is the interface, we own the analysis and the output. Validate the value, then invest in the interface once it is proven.
I saw this option at the time. Product leadership held a strong belief that all of the work should live inside our tool, and I did not fight hard enough for the headless path. The full UI shipped and it worked, but we spent significant front-end budget before the hypothesis was validated, and the descoping pressure at the end was a direct consequence.
The lesson I carry: when users have already built their own solution, the fastest deployment is often to meet them where they are, prove value inside their existing workflow, and earn the right to move them later. Distinguishing what a stakeholder wants the product to be from what the evidence says users need, and pushing harder when those diverge, is the muscle this project built.