Experiments & Open Source
Mixpanel Tracking Skill
A free, open-source skill for better Mixpanel instrumentation.
As a Growth PM, instrumentation is core to my job. I kept running into the same problem when using AI coding tools to add tracking: they wrote code fast, but not tracking I'd actually trust for a funnel or retention analysis. So I built a reusable skill that makes AI think like an analyst first, before it writes a single event. It proposes what to track and why, and waits for my approval before touching the code.
View on GitHub →Tested with: Claude Code · Lovable
AI can write tracking code. It can't tell you what's worth tracking.
As a Growth PM, I don't just need events to fire. I need a clean funnel, a trustworthy retention cohort, an activation signal I can act on. That's a product decision, not a coding task, and AI coding tools skip straight past it.
Events get added because an interaction exists, not because it answers a question I'd actually ask in a funnel or retention analysis.
AI tends to over-track, burying the signal I need in noise I didn't ask for.
Naming drifts across features, so the same user action shows up under three different event names.
Cleanup becomes a manual audit, because nothing tracks what should stay, change, or go as the product evolves.
“The problem isn't adding Mixpanel events. It's deciding what should be tracked, why it matters, and keeping it consistent.”
A structured workflow for AI-assisted Mixpanel instrumentation
I built this the way I'd want a good analytics engineer to work: understand what question we're trying to answer, check what's already being tracked, propose a focused plan, and only touch code once I've approved it. The skill makes any AI coding tool follow that same discipline.
This turns analytics from an ad-hoc coding task into a deliberate step in product development, one a PM can actually own.
What I built
New tracking
Given a requirement, it proposes the events and properties to track, tied to the question they answer.
Existing tracking audit
It reviews what's already there and flags inconsistent, unnecessary, or risky tracking, before I run a report on bad data.
Event planning
It proposes a small, focused set of events instead of tracking everything, the same discipline I'd apply reviewing a tracking plan myself.
Implementation planning
Before changing anything, it lists exactly which files will be touched, so I know the blast radius.
Human approval
It proposes first and waits. Nothing changes without a yes from me.
Implementation
Once approved, it makes the changes directly in the code.
Benefits
For Growth PMs
This is the workflow I actually needed: a way to turn "what do we need to learn from this feature" into an instrumentation plan I can review before it's built, instead of discovering bad data after launch.
For product teams
Forces a deliberate call on what should and shouldn't be tracked, instead of defaulting to "track everything."
For developers
Clear tracking requirements up front, instead of guessing the event structure for every feature.
For AI-assisted development
A repeatable process for analytics instead of ad-hoc prompting.
For existing products
An audit workflow for cleaning up tracking that's already spread across the codebase.
Free and open source
I released the skill publicly so product, growth, and engineering teams can inspect it, use it, and adapt the workflow to their own process.
v0.1.0 · MIT LicenseThis confirmed a bias I already had as a Growth PM
I went into this expecting to save time on writing tracking code. What I actually learned is that the bottleneck was never the code, it was the thinking before it: what question are we trying to answer, and does this event actually answer it. AI made the code faster to write, which just meant sloppy instrumentation could reach production faster too. The skill exists to slow that one step down, the same way I'd slow down a tracking plan review before it goes into a sprint.
“A funnel is only as trustworthy as the PM decision behind each event, not the code that logged it.”