Skip to content

Three tags counted one store’s sales, and disagreed by 30.1%.

By Conner Crowe  ·  Measured to  ·  Published , wording updated  ·  Read-only. Anonymised and aggregated.

These are the ad accounts of 3 online stores I manage, over 90 days, plus a fourth too small to use. All sell physical products direct to consumers. Several findings rest on a single store, and each one says so. It shows how far the tracking already installed on these accounts disagreed with itself, not a rate for all of ecommerce. N next to a figure is how many stores it comes from.

The short version

  • I pulled 90 days of read-only data from the ad accounts of 3 online stores I manage, and on one of them the store’s own order list too.
  • On one store, three tags that each count the same purchases disagreed: the lowest counted 30.1% fewer than the highest (N = 1). The account bid toward the highest.
  • On 2 of 3 stores, 16.6% to 17.2% of what the account called conversions were people adding to cart or starting checkout, not buying (N = 3).
  • On all 3, the "All conversions" column was 99.4% to 99.8% things other than purchases (N = 3).
  • On the one store where I could read the order list, the ad platform claimed purchases equal to 58.5% of every order the store took, while the store credited none of the orders with journey data to paid ads (N = 1). Either side could be wrong, and both are tracking failures.
  • 30.1% gap between three tags counting the same purchases, one store (N = 1)
  • 16.6 to 17.2% of counted conversions were cart or checkout events, on 2 of 3 stores (N = 3)
  • 99.4 to 99.8% of "All conversions" weren’t purchases, on all 3 stores (N = 3)
  • 58.5 to 65.9% of one store’s orders, claimed by the ad platform (N = 1)

Read the N on each tile. The noise ratio and the conversion-action sprawl held across all three stores. The cart-event finding is 2 of 3. The 30.1% gap and the order-book comparison are each a single store, and the order-book comparison is N = 1 because Store A is the one store whose order list I could read.

Three tags counted the same
sales, and disagreed.

A tag is the bit of code that tells the ad platform a purchase happened. Store B had three purchase tags live at once: one installed by the store’s sales channel, one set up in a tag manager, and one imported from analytics. Same store, same window, same purchases. The lowest counted 30.1% fewer than the highest. This is one store, so read it as N = 1.

The account has four enabled purchase actions in total. Three of them carried data across the common live window and are the three compared here. The fourth is in the conversion-action count in the lookback-window note further down.

PURCHASES RECORDED · COMMON LIVE WINDOW 2026-05-17 TO 2026-08-10 Store sales-channel tag 382.02 Tag-manager deployment 321.59 Analytics-imported purchase 266.99 30.1% spread THE ACCOUNT COUNTS ONLY THE TOP BAR IN ITS BIDDING METRIC
Measured over the common live window of all three tags, 17 May to 10 August 2026, so a late deployment can’t explain the gap. The lowest reading sits 30.1% below the highest. The middle one is 15.8% below.

382.02

Store sales-channel tag

The only one counted in the bidding metric

321.59

Tag-manager deployment

15.8% below the highest

266.99

Analytics-imported purchase

30.1% below the highest

The account bids toward the highest of the three. So the target it optimises toward is the most generous of three disagreeing counts, and the other two sit in the same interface, unused, contradicting it every day. Nobody chose that. It accumulated. A sales channel installed the first one, a tag-manager project added the second, an analytics link imported the third, and no one removed anything.

On two of three stores, cart events
counted as conversions.

Between 16.6% and 17.2% of the conversions those two stores reported were people adding to cart or starting checkout, and so was between 19.8% and 25.8% of the conversion value. Nothing in the interface labels this. The column reads "Conversions". The value column reads "Conv. value". Nothing about this lives in the storefront. It’s entirely a question of which conversion actions the account elected to count.

Store Conversions that were purchases Conversions that were cart or checkout events Conversion value that wasn’t revenue
Store A 82.8% 17.2% 25.8%
Store B 99.3% 0.7% (phone calls) 0.0%
Store C 83.4% 16.6% 19.8%

Return on ad spend (ROAS) is conversion value divided by ad cost. Calculated from those two columns on either store, it’s wrong by a fifth to a quarter, and wrong in the flattering direction, which is why nobody catches it. One store in three counted no cart or checkout events, which is enough to show the behaviour is avoidable rather than inherent. Category splits are the platform’s own classification, not my reading of action names.

SHARE OF COUNTED CONVERSIONS Store A 17.2% cart Store B 0.7% calls Store C 16.6% cart PURCHASES NOT PURCHASES
Two of three stores counted add-to-cart or begin-checkout events inside the metric their bidding optimises toward. On Store A that also carried 25.8% of the reported conversion value. On Store C, 19.8%.

One campaign had
no purchase goal.

Store C runs a Shopping campaign whose only biddable conversion goals are add-to-cart and begin-checkout. There’s no purchase goal on it. This is one campaign on one store, so read it as N = 1. In 90 days that campaign reported 5.96 conversions. All 5.96 were cart or checkout events. Zero were sales. Its reported conversion value was cart value, and the algorithm bid to maximise it.

The same account’s Performance Max campaign is configured correctly and reported 29.93 purchases. Both campaigns roll up into one account total, and the account total is what a monthly report shows. I verified this against the campaign’s biddable conversion goals rather than its action names, because names lie and goal settings don’t. If you audit only at account level you will never see it.

"All conversions" was
99.4% to 99.8% noise.

Next to the Conversions column sits "All conversions", which adds up every action the account tracks. On all three stores, 99.4% to 99.8% of it was something other than a purchase (N = 3): page views, session starts, scroll depth and search-results views imported from analytics. They are left out of bidding, and they swamp the column right beside it. Every store also had at least three enabled purchase actions and counted exactly one.

ALL CONVERSIONS PER ONE COUNTED CONVERSION · BAR LENGTH IS THE RATIO Store A 698× 0.158% PURCHASES Store B 790× 0.312% PURCHASES Store C 131× 0.637% PURCHASES
Bar length is proportional to the ratio, so Store C’s 131x reads as the shorter bar it’s. The accent sliver marks the purchase share but is not to scale: at 0.158% of the longest bar it would be well under one pixel, so it’s drawn at a fixed minimum width. On Store B the largest single contributor to "All conversions" was a page-view action at 227,278 events across the window, against 405.51 counted purchases on that account over the full 90 days. That’s a different window from the 382.02 in the lead finding, which is restricted to the shorter window where all three of that account’s purchase tags were live.

Anyone who exports "All conversions" into a spreadsheet, or wires it into a dashboard because it sounds more complete, is reporting a number that’s between 99.4% and 99.8% engagement noise. I’ve seen it wired into client dashboards for exactly that reason. It’s the least useful number in the account.

The numbers behind the chart
Store All conversions divided by Conversions Share of "All conversions" that were purchases
Store A 698x 0.158%
Store B 790x 0.312%
Store C 131x 0.637%

The two columns have different numerators, so don’t multiply them and expect 100%. The ratio divides every conversion action on the account by the one purchase action the account counts. The purchase share is measured across every purchase-category action, counted or not. On an account carrying three or four concurrent purchase tags the second numerator is larger than the first, so ratio times purchase share comes out above 100%: 110% on Store A and 247% on Store B. That excess is the same tag duplication the lead finding measures, seen from a different angle.

The ads claimed most of
one store’s orders.

On Store A, the purchases the ad platform counted, the number its bidding optimised toward, equalled 58.5% of every order the store took in 90 days. Counting every purchase action on the account, used for bidding or not, it rises to 65.9%. Treat 58.5% as the claim and 65.9% as the upper bound. The store’s own data credited none of the orders it had journey data for to paid ads.

This comparison runs on one store, because Store A is the one store whose order list I could read. Read it as N = 1. The denominator is the store platform’s own order count at EXACT precision, cross-checked against a full enumeration of every order record. Everything below is a share of that order book.

STORE A ONLY · N = 1 · 90 DAYS · SHARE OF THE STORE'S OWN ORDER BOOK The store's own order book 100% Counted in the bidding metric 58.5% All-conversions purchase total 65.9% The store attributed to paid 0% 58.5% IS ONE COUNTED PURCHASE ACTION · 65.9% SUMS ALL THREE ENABLED ONES JUST UNDER A THIRD OF THE ORDERS CARRY A PRODUCT-SYNC PARAMETER READING AS ORGANIC
Both ad-platform rows count the same purchases through different numerators. The store platform’s own last-click journey data classified none of the orders it had journey data for as paid. One order arrived with no journey summary at all and sits outside that split.
MeasurementShare of the order bookWhat the numerator is
The store’s own order book 100% Platform-verified at EXACT precision, cross-checked against a full enumeration. The denominator for every row below
Counted in the bidding metric 58.5% One counted purchase action. This is the number bidding optimised toward
All-conversions purchase total 65.9% Summed across the account’s three enabled purchase actions, counted or not
Classified as paid by the store 0% Measured against the orders that carried journey data at all
Placed through a channel ads can’t see One order Counted in the order book, invisible to the ads side
Cancelled inside the window About a tenth No restatement was sent to the ad platform
Refunded inside the window About a sixth No restatement was sent to the ad platform
Carrying the product-sync parameter Just under a third On the last recorded visit. Its campaign value reads as organic

The two systems can’t both be right, and the honest reading is a fork. Either the ad platform is crediting itself with organic and direct orders on a 90-day click-through window plus a view-through window, in a Performance Max campaign that also serves free product surfaces. Or the store platform is collapsing paid product-surface clicks into an organic-labelled campaign parameter. Just under a third of the orders carry the store platform’s product-sync parameter on their last recorded visit, and its campaign value reads as organic.

Both branches are tracking failures. Neither number is safe to budget against. I’m not going to pretend I can pick between them from the API alone, and the fork is more useful than a winner.

One note on precision. Both ad-platform figures are reported as the API returned them, unrounded, and both came back as whole numbers on this account in this window. Fractional counts appear elsewhere on this page because data-driven attribution splits credit where it applies. I can’t explain the whole-number return further from the API, so I’m flagging it rather than smoothing over it. The order base here is small enough that individual orders move the shares materially, and caveat 04 sets out what that costs the estimate.

One reporting setting moved one store’s
conversion value by 7.4%.

An ad account can credit a purchase to the day of the click or the day of the purchase. Switching only that setting moved Store C’s reported conversions by 5.8% and its conversion value by 7.4%. Same account, same window, same conversion actions. Store B moved 2.1% and 2.2%, and Store A not at all (N = 3).

CHANGE WHEN ATTRIBUTING TO CONVERSION DATE INSTEAD OF CLICK DATE COUNT VALUE 0% +8% Store A +0.0% Store B +2.1% / +2.2% Store C +5.8% / +7.4%
Nothing about reality changed. Only the reporting convention did. Any comparison between ad-platform conversions and store orders that doesn’t state its date basis carries this much error before it starts.
The numbers behind the chart
StoreCount moves byValue moves by
Store A 0.0% 0.0%
Store B +2.1% +2.2%
Store C +5.8% +7.4%

Each store mixed different lookback windows

A click-through window is how many days after a click the account still credits a purchase to the ad. Store C mixes 30, 60 and 90-day windows across its enabled conversion actions. Stores A and B each mix 30 and 90. Every store has at least three enabled purchase actions, and every store counts exactly one of them. Store B’s four is the highest, and only three of those four carried data across the common window compared in the lead finding.

Conversion actions and windows, store by store
Store Conversion actions defined Enabled Enabled purchase actions Click-through windows in use (days)
Store A 24 22 3 30, 90
Store B 50 36 4 30, 90
Store C 19 16 3 30, 60, 90

One store’s reporting day didn’t match the ad account’s

Store B carries a two-hour offset between the ad account’s reporting time base and the store platform’s. Every day-level comparison between the two is out of phase by that much, and the offset can’t be removed after the fact, because the ad platform aggregates to account-local days before the data leaves the API. Store A’s two systems agreed. Those are the only two pairs where both time bases were readable.

Six checks I would run
on your account tomorrow.

  1. Open the conversion-action list and read the category of every action counted in the bidding metric. Read the category, not the name. Two of three accounts here were counting cart events as conversions.
  2. Check biddable goals per campaign, not per account. One campaign in this sample had no purchase goal at all while its account total looked reasonable.
  3. Count how many purchase-category actions are enabled. All three accounts had at least three. One is counted. The others exist to disagree with it.
  4. Stop reporting "All conversions". It was 99.4% to 99.8% non-purchase on every account here.
  5. Confirm the ad account reporting time base matches the store platform’s. One of the two verifiable pairs was two hours out of phase.
  6. Pull the store’s own order count for the same window and put it beside the ad platform’s purchase count. On the one account where both were readable, the ad platform’s counted purchases equalled 58.5% of the entire order book, and its all-conversions purchase total equalled 65.9%, while the store attributed none of it to paid.

Every one of those checks is a symptom of the same thing: a stack that grew one tag at a time with nobody holding the whole picture. The architecture I rebuild accounts to is the Tracking Stack, eight layers from the store through the container, server-side, analytics and the ad platforms. Read it once, then hand it to whoever owns your tracking.

If you want these questions asked of your account, two doors. The free audit works from read-only access and comes back within 24 hours of access. With that access I can read your conversion-action list and your biddable goals per campaign, so the ad-account checks above go into the written audit; the store’s own order count is the one number I’d ask you to pull. If you’d rather talk it through live, a strategy call is the other door. Either way you end up with your numbers, not mine.

What I measured,
and what I didn’t.

The window

13 May through 10 August 2026 inclusive. 90 days. The window ends on the last complete day before the pull on 11 August 2026, so no partial day is counted. Every ad-platform query used a literal date clause the platform evaluates in each account’s own reporting time base. Store order queries used explicit UTC offsets matching each store’s own time base, so the store day boundary and the store’s own reporting day boundary agree.

All access was read-only. Nothing was written to any store, ad account, tag container or analytics property. Ad-platform data came through a read-only query runner that rejects any statement not beginning with SELECT. No mutate path was touched.

The sample, and N

Four ecommerce advertiser accounts were examined. Three carried enough volume to report, so N = 3 on the ads-side findings. One reconciliation ran the full comparison across ad platform, analytics and store platform, so N = 1 on the store-to-ads reconciliation, because that’s the one account whose store platform’s order table I could read. All four sell physical products direct to consumer. Every ads-side finding here is a conversion-action finding, and none of those turn on which store platform an account runs. The Store A reconciliation does, and the mechanism is named in caveat 03.

N = 3 is the ceiling, not the typical case. Several findings are single-account observations inside that sample, and each one says so. Nothing here is a population estimate, and nothing here should be read as a rate that generalises to ecommerce accounts at large.

The sample is ecommerce accounts I’ve managed, and no client is ever named. Store D was excluded for volume: a few thousand impressions, a single-digit click count and zero purchases across the 90 days. Padding N with it would be dishonest.

Sector descriptors and volume figures below are deliberately coarse, and no account’s store platform is named anywhere on this page. The working set records all three, and publishing any of them would identify these accounts against the case studies elsewhere on this site. Campaign mix and inclusion verdict are the parts that bear on the findings, so those are the parts published. If that redaction costs you something as a reader, it’s buying the clients their anonymity, and that trade isn’t close.

Store Profile Campaign mix 90-day paid click band Verdict
Store A Consumer retail, high AOV Performance Max only Thousands Included. Full reconciliation.
Store B Consumer retail, mid AOV Performance Max heavy Tens of thousands Included, ads side only.
Store C Consumer retail, mid-to-high AOV Performance Max plus Shopping Thousands Included, ads side only.
Store D Consumer retail, negligible volume Not reported Single digits Excluded for volume.

Words used here

Conversion
An action the ad account counts: a purchase, or on some accounts an add-to-cart or a checkout start.
Conversions column
The column that contains only the conversion actions an account or campaign has elected to count. This is what bidding optimises toward. It isn’t a purchase count unless every counted action is a purchase, which wasn’t the case on any of the 3 stores here: two counted cart or checkout events and one counted phone calls (N = 3).
All conversions
Every conversion action, counted or not, including page views and scroll depth imported from analytics.
Purchase tag
A conversion action set up to record a purchase. One store can have several, each installed by a different tool.
Conversion action category
The ad platform’s own classification of each action: purchase, add-to-cart, begin-checkout, page-view, engagement. Category assignments are taken from the platform, not inferred from action names.
Biddable campaign conversion goals
The authoritative statement of what a campaign is bidding toward. Used to verify the definition mismatches instead of relying on action names.
Conversion value
The money value the account attaches to each conversion. For a purchase it should be the order value.
ROAS
Return on ad spend: conversion value divided by what the ads cost.
Performance Max
A campaign type that runs across search, shopping, video and other placements from one budget.
Conversions by conversion date
The same conversions attributed to the day the conversion happened rather than the day the ad was clicked. Used to isolate the date-basis effect.
Click-through window
How many days after a click the account will still credit a purchase to the ad.
Order count
The store platform’s own order count with a created-at range in store-local time at EXACT precision, cross-checked against a full enumeration of the underlying order records. Cancelled, refunded, test and non-online-store orders are counted and reported separately rather than filtered out silently.
Order attribution
The store platform’s own last-visit and first-visit journey data, carrying its own source-type classification plus raw UTM parameters. Its last-click model is used as stated, not reconstructed.
N
How many stores a number is based on. N = 1 means one store.

Compared, and deliberately not compared

This is a tracking-accuracy piece. Comparing two numbers whose definitions differ, then calling the gap an error, would be the exact failure the piece is about. So I compared counted conversions split by the platform’s own category within a single account and window, multiple purchase-category actions inside a single account over their common live window, platform order count against ad-platform claimed purchases for the one store where both are readable, and click-date against conversion-date totals for the same account.

I didn’t compare ad-platform conversions against store revenue as if they measured the same thing, because they don’t. I didn’t compare Store B’s ads figures against Store B’s order count, because the order data wasn’t readable. I didn’t average across stores, because with N = 3 an average would imply precision that doesn’t exist.

Not measured

  • Direct analytics-platform session and channel data. No analytics API credential was reachable. Where an analytics measurement appears here it’s that platform’s own purchase event as the ad platform received it, and it’s labelled that way.
  • Store-platform order data for Stores B and C. Store B’s available API credential lacked order scopes and returned an access error. Store C’s order data wasn’t reachable through any read path available to me. The three-way reconciliation is N = 1 and is reported as N = 1 everywhere it appears.
  • Consent-mode modelling. No account exposed a modelled-versus-observed split through the API, so no claim is made about consent effects.
  • Any cross-store average. With N = 3 an average would imply precision that doesn’t exist. Every figure is per store, with the range given.

Not claimed: that any single number above is the true one. The point is that the systems disagree by measurable amounts, and the amounts are large enough to change a budget decision.

Seven caveats a reader should weigh

  1. Attribution models differ by construction. The ad platform uses data-driven or last-click attribution across a click-through window of 30 to 90 days depending on the action, plus a view-through window of 1 to 30 days, and credits the conversion to the click date by default. The store platform uses last non-direct click within its own visit history and stamps the order at order time. Those are different questions. Where I report a gap I’m reporting that two systems disagree, not that one of them is lying.
  2. Fractional conversions are real. Data-driven attribution splits credit, so counts like 29.93 and 5.96 appear. They are reported as returned, not rounded to integers.
  3. The store platform’s Google channel tagging is ambiguous. The Google and YouTube sales channel stamps a product-sync medium and an organic-reading campaign name on product-surface traffic. Whether every click carrying it was unpaid can’t be settled from either API. The finding built on this is stated as a fork with both branches named, and both branches are tracking failures.
  4. The reconciled account’s order base is small. Store A is a low-volume account, and the order count is withheld along with every other absolute figure. The shares are quoted to one decimal because that’s the precision of the underlying counts, not because the estimate is that stable. No confidence interval is claimed, and on a base this small individual orders move the shares materially.
  5. Refunds and cancellations move the denominator. About a sixth of Store A’s orders were refunded inside the window and about a tenth were cancelled. The ad platform wasn’t sent restatements for any of them, so its purchase count includes orders the store no longer holds.
  6. One account’s journey data is absent in part. One Store A order arrived through a mobile shopping app with no customer journey summary at all. It’s counted in the order book and excluded from the attribution splits, so the paid share is measured against the orders that carried journey data rather than against the full book.
  7. Spend, revenue and order values aren’t published. They exist in a private working folder and stay there. Every published figure on this page is a count, a percentage or a ratio.

Figures you can quote.

Each line carries its scope, so it stays accurate when it’s copied on its own. Please link this page when you use one, so readers land on the N and the caveats.

  • On one online store’s ad account managed by Conner Crowe, three purchase tags counting the same purchases over their common live window, 17 May to 10 August 2026, disagreed by 30.1%, lowest against highest (N = 1).
  • On 2 of 3 online stores’ ad accounts managed by Conner Crowe, 16.6% to 17.2% of counted conversions were add-to-cart or begin-checkout events, 13 May to 10 August 2026 (N = 3).
  • On all 3 online stores’ ad accounts managed by Conner Crowe, 99.4% to 99.8% of the "All conversions" column wasn’t purchases, 13 May to 10 August 2026 (N = 3).
  • On one online store managed by Conner Crowe, the ad platform’s counted purchases equalled 58.5% of the store’s entire 90-day order book, 13 May to 10 August 2026, while the store attributed none of the orders it had journey data for to paid (N = 1).
  • Switching only the date basis from click date to conversion date moved reported conversions by up to 5.8% and conversion value by up to 7.4% across 3 online stores’ ad accounts managed by Conner Crowe, 13 May to 10 August 2026 (N = 3).

How to cite

Crowe, C. (2026). The Ecommerce Tracking Accuracy Benchmark. Measured 13 May to 10 August 2026, published 11 August 2026, updated 30 October 2026. https://connercrowe.com/benchmarks/ecommerce-tracking-accuracy/

The underlying records are client data and aren’t published.

Where this shows up in real accounts

I will tell you which
of your numbers are real.

Add me as a read-only user and I'll write the audit myself: your conversion actions, your biddable goals per campaign and how your order count lines up against the ad platform, 5 to 7 pages, back within 24 hours of access. No call needed. If you'd rather talk first, a call is open too.

Ask me anything about working together.

Every word here is from answers I wrote. If yours isn't covered, send it and I'll reply myself.

People usually ask

  • How much do you charge?
  • Is the audit really free?
  • How is this different from an agency?
  • Can you get my business mentioned in ChatGPT?