Yuvraj Raulji | Mixpanel
Mixpanel is only as good as its tracking plan, and most implementations do not have one. Events get added by whoever needed a number that week, properties drift, and within a year nobody trusts a funnel enough to act on it. The work worth paying for is the naming, the schema and the governance, not the installation.
Quick answer
Mixpanel is a product analytics platform for event-based behaviour: what people do inside a product or a store, in what order, and who comes back. Unlike a session-based tool it models a user and their events, which is what makes funnels, retention and cohort analysis possible. The platform is straightforward to install and difficult to get value from, because everything downstream depends on a tracking plan: consistent event names, a property schema, and a rule for who owns changes. An implementation without that produces charts nobody trusts within about a year.
Best suited for
- Products and stores where behaviour matters more than pageviews
- Teams arguing about numbers from two different tools
- An existing Mixpanel nobody trusts any more
- Funnel and retention questions GA4 answers badly
Business problems
The symptom as the person with the problem describes it, what it is costing, and where the technology actually helps.
Two tools give two different numbers
Mixpanel and GA4 disagree on the same funnel, so meetings become arguments about instrumentation rather than decisions about the product. Nobody wins that argument, and the usual outcome is that both are ignored.
Opportunity
The two are measuring different things by design, session-based against event-based, and the fix is deciding which question each tool owns and reconciling the definitions once, in writing.
Event names were never agreed
Checkout Started, checkout_started and Started Checkout all exist, from three different releases. Every report has to know which is current, so the knowledge lives in one person rather than in the schema.
Opportunity
A tracking plan with a naming convention, a property schema and a review step before a new event ships. Unglamorous, and it is the whole difference between analytics and a data landfill.
Identity is broken across sign-in
A person is one user before they log in and another afterwards, so acquisition and retention both understate. This is the single most common Mixpanel implementation error and it is invisible in the charts.
Opportunity
Identity resolution set up deliberately, with aliasing and identity merge handled at the point of sign-in and sign-up rather than left to defaults.
Nobody knows what an event is supposed to mean
Properties were added ad hoc, some events fire twice, and a few fire on render rather than on action. The reports are precise and wrong, which is worse than obviously broken.
Opportunity
An audit against the live implementation: what fires, when, with what properties, and which of it contradicts the plan. The output is a list ordered by how much each error distorts a decision.
Approach
Five stages, in this order, on every engagement. Skipping the first one is the most expensive habit in this industry.
Understand
DecisionsQuestionsOwnersCurrent tools
Which decisions the data is supposed to inform, and who makes them. An analytics implementation designed without that produces a lot of events and no answers, which is the normal failure here.
Architect
Tracking planEvent schemaIdentityGovernance
Event names, properties, types and the identity model, written down before anything is instrumented. This is the deliverable that outlives the engagement, and the one most implementations skip.
Build
InstrumentationServer and clientQABackfill
Implemented against the plan, with server-side events where a client-side one would be blocked or unreliable, and each event verified against its definition rather than against whether it appeared.
Optimize
FunnelsRetentionCohortsDashboards
The reports the questions actually need, kept few. A workspace with forty dashboards has the same problem as no dashboards, because nobody knows which one is authoritative.
Scale
GovernanceWarehouseHandoverReview cadence
A review step for new events, a route into the warehouse where one exists, and enough documentation that the team can add an event correctly without asking. The goal is to hand it back.
Capabilities
Consulting
- Tool fit against GA4
- Question and decision mapping
- Measurement strategy
- Second opinion on a setup
Implementation
- Tracking plan
- Event and property schema
- Client and server instrumentation
- Identity resolution
Audit
- Live event review
- Duplicate and misfiring events
- Property drift
- Plan against reality gap
Reporting
- Funnels
- Retention and cohorts
- Dashboards worth keeping
- Alerting on the numbers that matter
AI and technology
What each application does, how it works, where the value is, where a person still reviews it, and what it will not do.
Finding the events nobody trusts
- What it does
- Reviewing a large event catalogue for names, properties and volumes that contradict the tracking plan.
- How it works
- The event schema and recent volumes are compared against the documented plan, and the differences are classified rather than listed, so the output is ordered by how much each one distorts a decision.
- Where the value is
- On a workspace with hundreds of events this is the difference between an audit that finishes and one that gets abandoned halfway.
- Where a human reviews
- Every proposed change is reviewed before anything is renamed or deprecated, because an event rename breaks historical reporting.
- What it will not do
- It cannot tell you what an event was meant to mean. Where the intent was never written down, the answer comes from the person who added it, or the event gets redefined deliberately.
Architecture
How the pieces sit together, top to bottom. Only technologies actually used appear here.
Product and storefront
Where the behaviour happens, and where most events originate.
WebAppCommerce platform
Client instrumentation
Events fired from the browser, with the caveat that ad blockers and privacy modes drop some of them.
Mixpanel JSGTM
Server instrumentation
The events that must not be lost: purchases, refunds, subscription state.
Server SDKWebhooksQueue
Identity
The model that decides whether one person is one user. Set deliberately, not by default.
IdentifyAliasMerge
Mixpanel
Events, user profiles, funnels, retention and cohorts.
Mixpanel
Downstream
Where the data goes next, when the questions outgrow the tool.
WarehouseBIEngagement platforms
When to use it
Good fit
- A product or store where the question is behaviour over time
- Funnels and retention that GA4 cannot answer cleanly
- A team that will actually act on the numbers
- Someone willing to own a tracking plan
Think twice
- Traffic and acquisition reporting, which GA4 does well and free
- A team with nobody to own event governance
- Sites where the real gap is that nothing is instrumented at all
- Buying a second tool to settle an argument the first one could answer
Comparison
These are not competing products so much as different jobs, and most stacks end up with more than one. The mistake is buying a second tool to answer a question the first one already answers.
| Criterion | Mixpanel | GA4 | WebEngage or MoEngage |
|---|---|---|---|
| Model | Event and user | Session and event | Event, plus messaging |
| Best question | What do people do, and do they come back | Where did traffic come from, and what did it do | Who should receive what, and when |
| Funnels and retention | Its core strength | Workable, less flexible | Present, in service of campaigns |
| Acts on the data | No, it reports | No, it reports | Yes, that is the point |
| Cost shape | Scales with events | Free at most volumes | Scales with contacts and messages |
Relevant work
Two platforms where the measurable behaviour was an internal workflow rather than a storefront funnel, which is the case Mixpanel handles better than a session-based tool.
Custom platform · B2BProcurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Magento 2 · MarketplaceMulti-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Business outcomes
Numbers a meeting can act on
The deliverable is not a dashboard. It is that one set of definitions exists, everyone reads the same funnel the same way, and a disagreement is about the product rather than about the instrumentation.
A tracking plan that outlives the engagement
Event names, properties, identity rules and a review step, written down. Without it a workspace degrades to the same state within about a year, whoever implemented it.
No percentage is published here. The measurement record on this site is GA4, Google Tag Manager and dataLayer work, and no Mixpanel engagement on it carries a published figure. A number borrowed from the Magento performance work would describe a different platform and a different problem.
FAQ
- Do we need Mixpanel if we already have GA4?
- Often not. GA4 answers acquisition and traffic well and costs nothing at most volumes. Mixpanel earns its place when the question is behavioural over time: does this cohort come back, where exactly does this multi-step flow break, what do the people who convert do differently. If nobody is asking those questions yet, a second tool adds cost and another set of numbers to disagree with.
- What is a tracking plan, and why does it matter so much?
- It is the document that defines every event, its properties, their types and when it fires, plus who approves a change. It matters because analytics degrades by accretion: events get added under deadline, names drift, and after a year nobody can say which of three similar events is authoritative. The plan is the only thing that prevents that, and it is what most implementations skip.
- Our Mixpanel data is not trusted. Where do you start?
- With an audit against the live implementation rather than a rebuild. What fires, when, with what properties, and which of it contradicts what people believe. The output is ordered by how much each error distorts an actual decision, because a wrong event nobody reports on is not worth the migration risk of renaming it.
- Should events be sent from the browser or the server?
- Both, with the split decided by cost of loss. Anything commercially significant, purchases, refunds, subscription changes, belongs server-side where ad blockers and privacy modes cannot drop it. Interaction detail that only needs to be directionally right can stay client-side.
- How does Mixpanel relate to WebEngage or MoEngage?
- Mixpanel reports behaviour; engagement platforms act on it. They overlap in that both consume events, and the common mistake is buying an engagement platform for its analytics or Mixpanel for messaging. Decide which tool owns which job before either is implemented, because the integration between them is straightforward and the ownership question is not.
Working together
Mixpanel takes an afternoon to install and about a year to stop trusting. The value is in the event schema, the identity model and the governance that keeps them true, which is unglamorous work that nobody sells because it does not demo well.
On Mixpanel this usually starts as a reporting request and becomes an audit, because the charts are only as honest as the events behind them.
Next step
Let us look at your business model, the systems you already run and where you are trying to get to, before choosing the technology. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.