Why your Mixpanel attribution doesn't match your ad platforms

It's budget-review week. Mixpanel's first-touch chart says one number, the Google Ads conversion column says another, and two dashboards are telling two stories to the people deciding next quarter's spend. There usually isn't a bug to find. Mixpanel and your ad platforms disagree because they measure with different models, windows, capture points, and identity logic, mostly by design.

So the job isn't forcing the numbers to match; it's an audit that separates the deltas you should expect from the defects you should fix. Run the steps below and you walk into the review with a one-page memo ("here's why they differ, here's the part that's actually broken") instead of a panic. This page is that audit.

#The five legitimate reasons they differ

1. Model. Mixpanel attributes conversions using the model you configured: first-touch, last-touch, or a multi-touch spread. Google Ads credits its own clicks under its attribution setting (data-driven by default), and Meta does the same with its own rules. Three tools, three credit assignment policies, one conversion. They can all be "right" and still disagree.

2. Window. Each system only looks back so far, and they don't agree on how far. An ad platform's click-through window, Mixpanel's configured lookback, and your sales cycle are three different clocks. A conversion 40 days after the click can be inside one window and outside another. Windows also anchor differently: platforms typically book the conversion against the click date, while Mixpanel books events when they happen.

3. Capture point. The platform counts the click on its own infrastructure; Mixpanel only knows what its SDK captured after the page loaded. Everything between click and capture (consent banners blocking the script, redirect chains stripping UTM parameters, single-page apps routing past the landing URL, ad blockers) turns a platform-visible click into a Mixpanel session with no attribution. This is the layer where most real defects live, and a written naming convention plus intact UTMs is the prerequisite for everything downstream (utm naming conventions).

4. Identity merge. Mixpanel stitches anonymous activity to a known user when identities merge on its distinct_id logic; the first-touch UTMs that "win" for a user depend on which sessions got merged. Ad platforms match conversions to clicks with their own identity graph, including cross-device matches Mixpanel never sees. Same human, two different reconstructions (Identity resolution: how user stitching actually works covers how stitching actually works).

5. Platform self-attribution. Ad platforms grade their own homework: they claim view-through conversions (no click at all), engaged-view conversions, and cross-device matches. Mixpanel structurally cannot see an impression, so every view-through conversion is a guaranteed, permanent, by-design gap. Why every platform's claimed total exceeds anyone else's count is its own story: Every platform claims the same conversion: why ad platforms overreport.

#The audit, step by step

Scope it tight: one campaign set, one conversion event, one 30-day period. The goal is an explained gap, not a reconciled spreadsheet of everything.

1. Check UTM capture on every entry path. In Mixpanel, chart sessions or signups by their first-touch UTM properties and count the share with empty attribution. Then click your own ads: landing pages, redirect chains, and embedded forms must all preserve utm_* parameters into the tracked session. Empty attribution on ad-sourced traffic is the number-one real defect this audit finds.
2. Align model and window, on paper. Write down Mixpanel's configured attribution model and lookback (in your attribution settings) next to the ad platform's attribution setting and click-through window. You usually can't make them identical; the deliverable is knowing exactly where they differ and in which direction that skews the counts.
3. Review identity merging. Sample a handful of converted users in Mixpanel and inspect their merged activity: did the first-touch UTMs come from the session you'd expect, or from an earlier merged visit? Note whether conversions predominantly happen on a second device or later session. That's where platform identity graphs and Mixpanel diverge hardest.
4. Compare the counts side by side. For the same event, same period: platform-claimed conversions, Mixpanel-attributed conversions, and the tiebreaker: the system of record (CRM or database signups). The platform number should be highest (self-attribution), and Mixpanel should sit near the system of record minus capture losses.
5. Classify every gap using the table below, and write the memo.

Run against a live Mixpanel property, the findings tend to sort the same way (illustrative split; your proportions will differ): a meaningful minority of ad-sourced sessions arriving with empty UTMs, the genuine capture defect worth fixing; a model/window mismatch explaining most of the remaining count gap without being anyone's bug; and identity merging explaining the puzzling individual journeys more than the totals.

#What's a defect vs what's by design

That table is the memo. A stable, explained delta is a healthy stack. An unexplained or growing one is work.

#The question behind the question

If reconciling these numbers keeps landing on your desk, the real issue is that Mixpanel is being asked a spend question. It's a product-analytics tool: built to answer what users do after they arrive (activation, retention, feature usage), and it does that well. "What did my ad spend return" is a different question with different data requirements: platform claims checked against a system of record, across channels, with values. Tuning Mixpanel harder won't close that; knowing which tool answers which question will. That boundary is drawn honestly in Where Buron fits alongside your product analytics. Runs on Amplitude or PostHog instead? The same audit, with their capture mechanics, is in Why Amplitude and PostHog attribution doesn't match your ad platforms.

#Run it continuously

A manual audit is true for the week you ran it. Capture decays (a form change, a consent update, a redirect added by someone who never heard of UTMs), and the platform-side numbers drift for reasons of their own (Why your GA4 and Google Ads conversions don't match catalogues those). Buron runs the spend-side of this audit continuously alongside your Mixpanel: ad-platform claims cross-checked against warehouse-verified conversions, so a widening gap becomes a finding in your inbox, not a surprise in a budget review. Your Mixpanel stays; the reconciliation stops being a quarterly fire drill.

Frequently asked questions

Why is Mixpanel different from Google Ads?

They measure different things by design. Google Ads credits its own clicks using its attribution setting and lookback windows, counts view-through and cross-device conversions, and reports against click time. Mixpanel attributes from the UTMs and referrers it captured in the browser, under its own model and window, against event time.

Can Mixpanel do marketing attribution?

Yes, within its capture boundary: Mixpanel attributes conversions to the UTM parameters and referrers its SDK recorded, using configurable single- and multi-touch models. What it can't see are clicks that never became tracked sessions (blocked scripts, stripped parameters, consent-denied visitors), or the ad platform's own view-through and cross-device matching.

Should Mixpanel match my ad platform's numbers?

No. A gap is expected even when both tools are healthy, because model, window, capture point, identity logic, and platform self-attribution all differ. The audit's job is to explain the gap and bound it. A stable, explained delta is a healthy stack; an unexplained or growing one is a defect.