Conversion Tracking Accuracy: How to Measure Yours Instead of Quoting Someone Else's

The short answer. Conversion tracking accuracy is the share of real conversions your ad platforms actually receive. You cannot look it up, because every published percentage was measured on somebody else’s traffic. You measure yours by comparing your own order or CRM records against what each platform reports, over a closed time window.

Every vendor in this category, including us, publishes an accuracy number. Thirty to forty percent lost. Sixty to seventy percent captured with pixels alone. Ninety-five to ninety-eight percent with server-side. Those numbers are real in the sense that somebody measured something, but not one of them was measured on your site, your checkout, your traffic mix or your consent rate.

Your accuracy is a property of your setup. It is measurable, it takes about an hour, and almost nobody does it. This post is the method.

The four numbers people call “accuracy”

The word does a lot of work. When a marketer says “our tracking is 70 percent accurate” they are usually describing one of four different things, each with a different denominator and a different fix.

Number	Denominator	What breaks it	What fixes it
Capture rate	Every real conversion in your own records	The tag never fired: ad blocker, block checkout, off-site payment gateway, JS error, consent decline, mobile in-app browser	A server-side event fired from your backend, not the browser
Match rate	The conversions you did capture	No click ID stored, click ID expired, no hashed customer data, weak event match quality	Server-set first-party storage, enhanced conversions, hashed identifiers
Attribution rate	Captured conversions that carried an identifier	Attribution window, cross-device journeys, view-through rules, platform modeling	Very little. This one is the platform’s call, not yours
Reporting variance	The same conversions, counted by two tools	Date basis, counting method, independently computed data-driven attribution	Nothing. Stop trying to close it

These multiply. A site with an 82 percent capture rate, an 84 percent match rate and an 88 percent attribution rate is running at 61 percent end to end, which is exactly the “60 to 70 percent with pixels alone” figure the category quotes, arrived at honestly rather than borrowed.

The practical consequence: an accuracy problem is only worth fixing once you know which of the four it is. Three of them have different fixes and the fourth has none.

The reconciliation everyone runs is the wrong one

Search this topic and you get a wall of posts explaining why GA4 and Google Ads disagree. They are good posts. Google Ads books a conversion on the date of the click, GA4 books it on the date it happened. Google Ads can count every conversion per click, GA4 counts key events per session. Both run data-driven attribution but each computes its own model on its own view of your traffic with its own lookback. A 20 to 30 percent gap between them is widely described as normal.

All true, and all beside the point. Both numbers come from the same browser-side tag. If the tag never fired, both are wrong, and they can still agree with each other perfectly. Reconciling GA4 against Google Ads measures your attribution settings, not your tracking. It is a comparison of two systems that share a failure mode, which is the one comparison guaranteed to hide that failure mode.

The only reconciliation that measures accuracy compares platform-reported conversions against a record that exists whether or not any JavaScript ran. For an ecommerce store that record is the order table. For a subscription business it is the billing system. For a lead-gen business it is the CRM.

The uncomfortable part: lead gen cannot measure this the same way

Worth being straight about, because no post in this SERP separates the two cases.

If you sell products, the order exists in your database regardless of tracking. Payment was taken, a row was written, and that row is ground truth. You can count what you missed.

If you generate leads, the form submission is the conversion, and it is usually captured by the same JavaScript that reports it. When the tag fails you do not get an unattributed lead, you get no lead record at all. There is no independent denominator to measure against. Lead-gen sites can measure match rate and attribution rate normally, but capture rate has to come from a server-side form handler, meaning you have to fix it before you can measure it. If someone quotes you a capture rate on a lead-gen site with no server-side form endpoint, ask where the denominator came from.

Running the measurement

Two numbers, in this order.

Step one, capture rate. Take every conversion in your own records for a closed window. Count how many have a corresponding tracking event. This needs no attribution logic at all, which is why it is the honest floor.

Step two, match rate and delivery. Of the ones you captured, count how many carried a usable click ID or hashed identifier, then compare that to what the platform confirmed for the same window.

Use a closed window. End it far enough in the past that the click window, the conversion lag and platform processing have all completed, which for Google Ads means ending it at least 30 days before today. Measuring a window that includes yesterday guarantees an undercount that has nothing to do with your tracking, and this is the single most common way people frighten themselves for no reason.

// reconcile.js
import { getOrders } from './lib/orders.js';
import { getTrackedEvents } from './lib/events.js';
import { getPlatformConversions } from './lib/platform.js';

// Closed window: ends 30 days ago so click windows and processing have settled.
const WINDOW = { from: '2026-06-14', to: '2026-07-14' };

const EXCLUDE = (order) =>
  order.isTest ||
  order.refundedAt ||
  order.isSubscriptionRenewal ||   // no click preceded it
  order.channel === 'wholesale';

export async function measureAccuracy() {
  const orders = (await getOrders(WINDOW)).filter((o) => !EXCLUDE(o));
  const events = await getTrackedEvents(WINDOW);
  const byOrderId = new Map(events.map((e) => [e.orderId, e]));

  const captured = orders.filter((o) => byOrderId.has(o.id));
  const matched = captured.filter((o) => {
    const e = byOrderId.get(o.id);
    return Boolean(e.clickId || e.hashedEmail);
  });

  const reported = await getPlatformConversions('google_ads', WINDOW);

  return {
    orders: orders.length,
    captureRate: captured.length / orders.length,
    matchRate: matched.length / captured.length,
    attributionRate: reported.count / matched.length,
    endToEnd: reported.count / orders.length
  };
}

Exclusions matter more than the arithmetic. Test orders, refunds, subscription renewals with no preceding click, wholesale and phone orders, and traffic from your own office IPs all inflate or deflate the result. If you already run IP exclusions on your tracking but not on your order export, your two sides are counting different populations and every number below is wrong.

Accuracy is a distribution, not a percentage

Here is the part that costs money, and it is the reason a single site-wide number is close to useless.

The following is an illustrative model, not a benchmark. It shows a store measuring 82 percent capture overall.

Segment	Share of orders	Capture rate
Chrome desktop, no blocker	34%	96%
Safari iOS, in-app browser	22%	86%
Desktop with an EasyPrivacy-enabled blocker	14%	45%
Checkout via off-site gateway	18%	74%
Everything else	12%	90%

Weighted, that is 82 percent. The headline looks survivable. The third row does not.

Smart Bidding and Advantage+ do not learn from your average. They learn from the conversions they receive, and they receive less than half of what one segment produces. The algorithm concludes that segment converts poorly and bids down against it. Ad-blocking desktop users skew technical and higher income, which on most B2B and considered-purchase sites is the cohort you least want deprioritized. The loss is not the missing 18 percent of conversions. The loss is the budget reallocated away from people who buy, on the strength of data that was never about them.

Same logic on the fourth row. If your PayPal and Klarna buyers are under-captured, you are systematically bidding against people who prefer those payment methods.

Segment your capture rate by browser, device, and payment method before you do anything else with it. If you want the underlying mechanics of the blocker row, we broke down exactly what filter lists do and do not stop in our guide to ad blocker conversion tracking.

The recovery percentages do not stack

One more piece of category arithmetic worth puncturing, because you will see it in every competing post.

Server-side recovers 20 to 40 percent. Enhanced conversions recover 5 to 30 percent. Consent Mode modeling recovers 15 to 25 percent. Add those and you are recovering more than the gap you started with.

They do not add, because they fix overlapping populations. Enhanced conversions repair conversions where the tag did fire but the identifier was weak. Server-side capture repairs conversions where the tag never fired at all. A conversion lost to a blocked request is not also available for enhanced conversions to recover, because there was no request. Consent-modeled conversions are estimates the platform inserts, not records you supplied, and they can overlap both.

Layering them is still correct, and we recommend it. But the honest expectation is that each layer recovers a shrinking remainder, not that the percentages sum. This is also why “we got to 95 percent” claims should always be met with “measured how, on which denominator”. Ours included.

Diagnosing which number is broken

Symptom	Broken number	First thing to check
Platform total is far below your order count, gap is stable	Capture rate	Off-site gateways, block checkout, blocked requests
Capture is fine but the platform credits far fewer	Match rate	Click ID storage duration, hashed customer data, event match quality
Gap widened suddenly with no code change	Capture rate	Consent rate shift, a plugin update, a filter-list update
Two analytics tools disagree, both roughly match orders	Reporting variance	Nothing. This is expected and is not costing you money
Long sales cycle, conversions vanish entirely	Attribution rate	Click window versus your actual conversion lag

The fourth row is the one to internalize. A stable disagreement between two reporting tools is not a problem. A change in that margin is the real signal, and it usually traces back to consent, a deployment, or a platform policy change rather than anything you did on purpose.

For the underlying mechanics of why browser-based capture degrades in the first place, start with our pillar on server side tracking, and for the specific ways revenue goes missing between click and conversion, see why you’re losing conversion data.

What measuring accuracy does not fix

Being straight about the limits, since this post is an argument for honest numbers.

Measurement does not create consent. If a visitor declines tracking, a correctly measured capture rate tells you accurately how much you are not allowed to collect.

It does not recreate a click ID that was never in the URL. If your landing page strips parameters or your redirect chain drops them, the conversion is unattributable no matter how well you count it.

It does not fix bad event configuration. Counting a thank-you page view as a purchase produces a very accurate number for the wrong event.

And it does not create demand. Accuracy work recovers the record of conversions that already happened. That changes how the bidding algorithms spend, which is worth real money, but a measurement project is not a growth channel.

Where Convultra fits

Capture rate is the number we exist to move. Convultra runs server side conversion tracking from a single line of JavaScript plus a server-side event from your backend, so the conversion record is written whether or not the browser cooperated. Click IDs (gclid, gbraid, wbraid, fbclid, msclkid and OpenAI’s oppref) are stored server-side for 90 days rather than the seven days a browser-written cookie survives under ITP, which is the match-rate half of the problem.

The part that matters for this post specifically: every conversion shows its per-platform delivery status individually, so the reconciliation above is something you can read off a dashboard rather than assemble from exports. Conversions that lose their click ID through a payment processor redirect are stitched back to the original paid click, which is exactly the off-site gateway row in the model above.

Where we are the wrong tool: if you need arbitrary transformation logic on events in flight, or bespoke destinations we do not support, a tagging server you administer yourself is the honest answer. We compared both approaches properly in our writeup on server side vs client side tracking.

FAQ

What is a good conversion tracking accuracy rate?

Above 90 percent capture rate, evenly distributed across browsers, devices and payment methods, is a healthy target for an ecommerce site. Even distribution matters more than the headline number, because a high average hiding one badly under-captured segment still distorts automated bidding.

Why don’t my Google Ads and GA4 conversion numbers match?

Different date basis (click date versus conversion date), different counting rules (every conversion per click versus key events per session), and two independently computed attribution models. A gap of 20 to 30 percent is normal and is not a tracking failure. Neither number tells you your accuracy, because both come from the same browser tag.

How do I measure my own conversion tracking accuracy?

Export every real conversion from your order system or CRM for a closed window that ended at least 30 days ago, exclude test orders, refunds and renewals, then count how many have a matching tracking event and how many the ad platform confirmed. The first ratio is capture rate, the second is match and attribution.

Does server-side tracking guarantee 95 percent accuracy?

No, and treat any vendor guaranteeing a specific number with suspicion, since it depends on your traffic mix, checkout, consent rate and implementation. Server-side capture addresses the largest single cause of loss, which is the tag never firing, but consent declines and missing click IDs remain.

Can lead generation sites measure capture rate?

Only with a server-side form handler. If the same JavaScript that reports the lead also creates the lead record, a failure produces no record at all, so there is no independent denominator to measure against.

How often should I re-run a conversion tracking accuracy check?

Quarterly, plus after any checkout change, consent platform change, or major plugin update. The absolute number matters less than a change in it, and those three events are what usually move it.

Measure it, then decide

Run the reconciliation on a closed 30-day window before you buy anything, including from us. If your capture rate comes back above 90 percent evenly across segments, your tracking is fine and your budget belongs somewhere else. Start a free Convultra trial if it does not.