Ask your analytics tool a simple question: "Do people who complete onboarding upgrade faster than people who don't?"
Now watch someone open Mixpanel to answer it and go quiet.
Not because Mixpanel is bad. Because there are four events that might mean "completed onboarding," two of them fire twice, one of them is named event_47, and nobody can say with confidence which one is real.
This isn't a tooling problem. This is what happens when tracking gets treated like a checkbox instead of a decision.
"Add Mixpanel" Is Not a Ticket
Somewhere in every growing product, a ticket gets filed that says “add analytics tracking” and goes into the sprint like any other task.
The engineer does exactly what the ticket says. They instrument the button. They name the event after the button. They ship it and move on, because the ticket never mentioned personas, funnels, or what question someone might ask in six months.
Nobody owned the event. So the event has no opinion about anything. It just knows a click happened.
Do this fifty times across a few quarters and you get the thing every mid-size product eventually has: 140 events, three of which mean "user signed up," none of which agree on what a signup actually is.
What an Event Actually Is
An event is not "some JavaScript ran." That's a log line, and log lines belong in your error tracker, not your product analytics tool.
An event is a record that a user completed a piece of intent. They meant to do something, and they did it.
"Button rendered" is not intent. "Modal opened" is not intent. "User submitted the payment form and it succeeded" is intent. "User invited a teammate" is intent. "User clicked something near the pricing page" is a shrug wearing a tracking SDK.
If you can't say what the user was trying to accomplish, you don't have an event yet. You have a UI crumb.
The One-Sentence Test
Before anything gets instrumented, it should pass one sentence:
As a [persona], when I [action], I want to know if they did [event], because it answers [question].
If you can’t fill in the question, stop. Don’t ship the event “just in case it’s useful later.” It won’t be. It’ll just be one more row in a dropdown that everyone scrolls past six months from now, squinting.
This sentence is annoying to write. That's the point. Annoying to write means someone had to think. Thinking is the actual deliverable here - Mixpanel is just where the thinking gets recorded.
Properties, Not Event Explosion
The single most common taxonomy accident: naming the method instead of the action.
Signup_Google. Signup_Email. Signup_SSO. Three events, one underlying question - "did the user sign up" - now requires three different funnel steps to answer, and God help whoever adds a fourth auth method next quarter without noticing the pattern.
The fix is boring and correct: one event, Signup Completed, with a method property set to google, email, or sso.
Same logic applies everywhere. Don't create Upgrade_Monthly and Upgrade_Annual. Create Plan Upgraded with a billing_cycle property. Don't create Payment_CreditCard and Payment_Paypal. You get the idea.
The event name answers "what did they do." The properties answer "how, with what, under which conditions." If your event names are doing the properties' job, you don't have a taxonomy, you have a naming convention wearing a taxonomy's clothes.
A Taxonomy That Fits on a Sticky Note
Most products need far fewer events than they have. Here's roughly what a durable core looks like:
| Event | Fires When | Key Properties |
|---|---|---|
Signup Completed
|
Account is created and verified |
method
|
Activation Completed
|
User hits the "aha" milestone, defined once, in writing |
time_to_activate
|
Core Action Performed
|
The thing your product actually exists to do |
object_type, count
|
Upgrade Completed
|
Server confirms plan change |
from_plan, to_plan, billing_cycle
|
Payment Succeeded
|
Payment processor confirms, not the client |
amount, currency
|
Payment Failed
|
Payment processor rejects |
reason
|
Invite Sent
|
Teammate invite is sent |
invite_channel
|
Seven events. Every question a reasonable PM asks in the first year - retention, activation rate, upgrade conversion, revenue funnels - can be answered from this list plus properties. Everything else is a nice-to-have you can add when someone actually asks the question it would answer, not before.
What Not to Send
Page views nobody reads. Hover states. Scroll depth on pages where nobody has ever opened that report. Every one of these is technically trackable and mostly worthless, and it costs you later, because it's noise sitting on top of the seven events that matter, and analysts stop trusting the dataset once they've been burned by it twice.
Also don't send debug events to production analytics. And don't send "optimistic" client-side success - the client saying "payment succeeded" before the server confirms it is not tracking, it's wishful thinking with a timestamp. If the client fires and the server later fails, you now have a happy funnel describing a broken product.
Track Less, Name Like a Product
The instinct to track everything comes from fear - fear of missing the one metric someone might ask for later. But an event list with 140 entries doesn't answer more questions than one with 15. It just makes the 15 good ones harder to find.
Track fewer things. Name them like a product person would defend the name in a meeting. Put the variance in properties, not in the event name. And treat every new event like you'd treat a new API endpoint - someone owns it, someone can explain what it means, and it doesn't ship without a reason attached.
Mixpanel was never the bottleneck. The bottleneck was that nobody decided what counted as a thing worth tracking before it landed on an engineer’s plate as a ticket.