A fast-growing education startup ran three separate web products (Typesy, Spreeder, Wordela) but had no shared way to measure daily active users, retention, or feature engagement — and the budget only allowed Mixpanel's free plan. I designed and delivered the entire tracking setup to fit inside those limits.
Role Led the analytics project end to end — audit, tracking design, and engineering rollout, working within Mixpanel's free-tier limits
Leadership needed basic growth numbers — daily and monthly active users, retention, feature usage — across all three products, but no tracking setup existed to produce them.
None of the three products had a working setup to measure how many people used them, or how often.
The startup's budget required staying on Mixpanel's free plan, which limits how much data and detail you can track.
Whatever was built needed to give a combined view across Typesy, Spreeder, and Wordela, not three separate setups.
Before designing anything, I audited the live products end to end. That audit surfaced three problems standing in the way of clean tracking.
The free plan blocked access to lookup tables, so events only showed raw codes like course_id or game_id — not anything a person could read.
The core features (course player, game player, word lists) load content without changing the page URL, so standard page-view tracking couldn't see people dropping off mid-task.
Early tracking attempts across the three products used inconsistent names and formats, risking duplicate or conflicting data once combined.
Working directly with leadership and engineering, I designed a tracking setup that worked around each limitation, then helped build and check it before launch.
Worked directly with the startup's leadership team to agree on the core numbers that mattered — active users, retention, and feature engagement — and turned that into a tracking roadmap.Stakeholder alignment
Set up a small set of shared details (which product, what type of user, which company) to be attached automatically to every action a user takes, so reports could be filtered and grouped without needing the paid lookup tables.Shared event context
Built custom tracking for the course player, game player, and word-list tools so each step a user takes inside these tools is recorded directly, even though the page itself never changes.In-app step tracking
Wrote a simple naming guide (consistent event and property names) for engineering to follow, then worked alongside engineers to fix bugs and check real, live data before anything went to production.Naming guide · QA
The five dashboards give leadership and product teams a shared, working view of active users, retention, feature engagement, onboarding, and subscription conversion — across all three products, without any new software spend.
Attaching shared context to every event turned unreadable database IDs into data that can actually be filtered and grouped by product, user type, or account.
Custom tracking inside the course, game, and word-list tools shows exactly where users get stuck, something standard page tracking could never see.
A written naming guide gives engineering clear rules for any new tracking, preventing the inconsistent logging that caused problems before.
Only the data analyst can change the tracking schema now, removing the risk of engineers making untracked changes that break reports later.
Let's talk
Tell me your biggest data or AI bottleneck and I'll send you how I'd approach it — the same way I worked this problem. No résumé dump, no pitch. Just a useful conversation.
Start the conversation →