What Is a Good Match Rate for Conversion Tracking?

Match rate is the share of your conversions that can be tied back to a tracked visitor session. If 100 orders come in and 82 of them can be connected to a visitor whose journey you recorded, your match rate is 82%.

It is the single most load-bearing number in attribution, and almost nobody reports it. An unmatched purchase has no source, no campaign and no journey — it is revenue your reporting cannot explain. Every channel breakdown you look at is computed on the matched portion only, which means match rate silently determines how much of your business your dashboard is actually describing.

What does match rate actually measure?

It measures the join between two datasets you already have: conversions on one side, tracked sessions on the other.

A conversion arrives from your commerce system — a Shopify order, a Stripe charge, a CRM deal marked won. It carries an email, maybe a phone number, an order ID and an amount. Separately, your tracking has recorded sessions: visits carrying a source, a campaign, a landing page, sometimes a click ID.

Matching is the act of deciding that this order belongs to that visitor. When the join succeeds, the purchase inherits a journey and the revenue becomes attributable. When it fails, the order is still real and the money is still real — but it lands in your reporting as revenue from nowhere.

Three things make the join fail: the buyer converted on a device or session your tracking never saw, the identifiers don’t agree between systems (a work email at checkout, a personal one at signup), or the session data expired before the purchase happened.

Is match rate the same as Event Match Quality?

No, and conflating the two is the most common confusion on this topic.

They can move independently. You can have a superb Event Match Quality score of 9.5 — meaning Meta resolves your events beautifully — while your own match rate sits at 55%, because nearly half your orders never got connected to a session in the first place. The events you did send were excellent; you just didn’t send events for a lot of the business.

The relationship runs one way. Match rate is upstream: a conversion you can’t match is a conversion you can’t enrich with identifiers, so poor match rate eventually drags EMQ down too. Fixing EMQ does nothing for match rate.

Why does match rate gate every other metric?

Because every attribution number you read is computed on the matched subset, and almost no dashboard tells you how big that subset is.

Consider a month with $500,000 in revenue and a 60% match rate. Your channels table shows Google Ads at $120,000, Meta at $90,000, organic at $70,000 and so on — and every one of those figures is drawn from the $300,000 that matched. The other $200,000 isn’t wrong, isn’t missing from your bank account, and isn’t in the report.

Now the problem: the unmatched portion is not a random sample. It is systematically biased toward exactly the journeys that are hardest to track — cross-device buyers, long consideration cycles, privacy-restricted browsers, people who first arrived months ago. Those are disproportionately the journeys that start on paid channels and finish somewhere else. Scaling decisions made on the matched 60% are made on a sample that under-represents the channels most likely to be opening journeys.

This is why a reported ROAS can be confidently precise and still wrong. Precision describes the matched set; accuracy depends on what got left out.

The practical consequence: a channel report without a match rate beside it is uninterpretable. Two agencies can hand you attribution decks with identical channel splits, one computed on 90% of revenue and one on 45%, and nothing on the page distinguishes them.

What counts as a good match rate?

It depends far more on your business model than on your tracking quality, which is why a single industry benchmark would be misleading.

Four factors set your realistic ceiling:

How the purchase happens. A same-session ecommerce checkout is the easiest case — the buyer converts in the browser you were already tracking. A B2B deal closed by a salesperson three weeks after a whitepaper download is the hardest, because the conversion event happens in a CRM with no browser involved at all.

What you collect, and when. Matching runs on identifiers. If your form captures email and phone and your checkout captures the same email, the join is straightforward. If the visitor browses anonymously and only supplies an email at the payment step, you have one identifier and one chance.

Consideration length. Every day between first touch and purchase is another day for a cookie to expire, a device to change, or a browser to clear storage.

Device split. Mobile-first audiences convert across devices more often, and cross-device is the join that most tracking setups simply cannot make.

So rather than chasing a number, judge match rate three ways. Compare it to itself over time — a stable rate that drops ten points in a month is a signal something broke, and that’s worth more than any benchmark. Compare it across your own segments — if Shopify traffic matches at 85% and your lead-gen funnel matches at 40%, the gap tells you where to look. And ask what the unmatched revenue has in common, because the answer is usually a specific, fixable pattern rather than diffuse loss.

What is not good is a match rate you can’t see. The failure mode here isn’t a low number; it’s not knowing the number.

How do you raise it?

Five things, in descending order of impact.

1. Collect a second identifier. Email alone gives you one chance to join. Email plus phone gives you two, and they fail in different situations — people use work and personal email addresses across contexts far more often than they use two phone numbers.

2. Capture before the conversion, not at it. If the only identifier you ever see arrives at checkout, every pre-purchase session is anonymous and can only be joined backwards. Capturing an identifier earlier in the funnel means the journey is already attached to a person by the time they buy.

3. Make the visitor ID survive. Much matching depends on recognising a returning browser. A visitor ID written by JavaScript is capped at seven days in Safari; one set by the server as a first-party cookie is not. That difference alone decides whether a three-week consideration cycle can be matched.

4. Normalise identifiers on both sides. John.Smith@Gmail.com and johnsmith@gmail.com are the same mailbox and will not join as strings. Phone numbers arrive in half a dozen formats for the same number. Normalising to a canonical form before comparing — lowercase and trim for email, E.164 for phone — recovers matches that were always there.

5. Keep unmatched conversions instead of discarding them. A purchase that can’t be matched today can often be matched later, when the same person returns and identifies themselves. Systems that drop unmatched conversions throw away the evidence permanently.

How does PartialLeads measure and raise match rate?

By reporting it as a headline number rather than burying it, and by matching on a tiered ladder of identifiers rather than a single join key.

Match Rate is a KPI, not a footnote. It sits in the Attribution Report’s KPI strip alongside attributed revenue, attributed purchases, time to purchase and recovered revenue — each with a comparison against the prior period. The number that tells you how much of your business the report covers is displayed with the report, not buried in a settings page.

Unmatched revenue is displayed, not hidden. A Revenue by Match Quality donut splits total net revenue three ways: partial-captured, submit-completed, and unmatched. The third slice is the honest one — the report shows you its own blind spot, and its size, every time you open it.

Matching runs on a confidence-ranked ladder. Every incoming purchase is matched against sessions in tiers: a visitor-ID echo carries the highest confidence, then email, then phone, then IP. The first tier that resolves wins, so a strong signal is never displaced by a weak one, and a weak signal is still better than no match at all.

Identity clustering gives the join more than one chance. Sessions are unioned into one person across six tiers — visitor ID, email, phone, IP and user agent, device fingerprint, and click ID. A purchase matched to any session in a cluster inherits the whole cluster’s journey, which is what makes cross-device and multi-session matching possible rather than aspirational.

Identifiers are normalised before comparison. Email is lowercased and trimmed, phone is converted to E.164 with a country-code fallback derived from session geography. This is unglamorous and it recovers a real share of joins that would otherwise fail on formatting alone.

The visitor ID is built to survive. Stored in localStorage with a first-party cookie backup, and the cookie is set by the server rather than by script — so Safari’s seven-day cap on script-written cookies doesn’t apply. Long consideration cycles stay matchable.

Unmatched purchases are retained and recoverable. They land as anonymous rather than being discarded, and become matchable later when identity arrives. There’s a manual re-match interface for the cases a human can resolve and an algorithm can’t.

Honest boundaries. Match rate has a ceiling that no tool sets. A buyer who researches on a phone you never saw, buys on a laptop in a private window, and uses a different email at checkout is unmatchable by any method that respects the data available — and pretending otherwise would require guessing. A high match rate also doesn’t mean the attribution is right, only that a join was made; the quality of that join depends on which tier resolved it. And the tiers are deliberately confidence-ranked rather than permissive, because a wrong match is worse than an honest blank.

Sources

1. Meta for Developers — Customer information parameters: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters
2. Meta for Developers — Conversions API best practices: https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices
3. Google Analytics Help — [GA4] Understand (direct) / (none) traffic: https://support.google.com/analytics/answer/15258820
4. WebKit — Tracking Prevention in WebKit: https://webkit.org/tracking-prevention/
5. Wikipedia — E.164 international telephone numbering plan: https://en.wikipedia.org/wiki/E.164