First-party data · 3 accounts, 90 days · headline finding measured on one
Three purchase tags, one store, a 30% spread.
I pulled 90 days of read-only data from four ecommerce advertiser accounts. Three carried enough volume to report. On one of them the store's own order table was readable too, so I could compare all three systems on the same purchases.
Measured window to · Published · Read-only. Anonymised and aggregated.
Every tracking vendor publishes a loss rate measured from inside its own pipe. Those are real numbers and this is not one of them. What a vendor cannot show you is how far apart the instruments already installed on your account sit from each other, because that reading needs the account's full conversion-action list rather than the vendor's own tag. I have that on the accounts I run, so I pulled it. The method and every caveat sit at the bottom of this page.
All four accounts sell physical products direct to consumer. Findings that come from a single account are labelled.
- 30.1% Spread between three purchase tags on one account (N = 1)
- 16.6-17.2% Of counted conversions that were cart events, on 2 of 3 accounts
- 99.4-99.8% Of "All conversions" that was not a purchase, on all 3
- 58.5-65.9% Of one account’s order book the ad platform claimed (N = 1)
Read the N on each tile. The noise ratio and the conversion-action sprawl held across all three accounts. The cart-event finding is 2 of 3. The headline 30.1% spread and the order-book comparison are each a single account, and the order-book comparison is N = 1 because Store A is the one account whose store platform's order table I could read. Every figure below carries the N it was measured on.
01 The lead finding · Store B only · N = 1
Three purchase tags,
one event.
Store B has three separate purchase-category conversion actions live at once: the store sales-channel tag, a tag-manager deployment, and an analytics-imported purchase event. Same store. Same window. Same event. This is the sharpest finding in the set and it is one account, 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 section 06.
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 counts only the highest of the three in its bidding metric. The optimisation target is the most generous of three disagreeing instruments, 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.
02 The column that lies quietly · 2 of 3 accounts
On two of three accounts,
"Conversions" was not a purchase count.
Between 16.6% and 17.2% of the conversions those two accounts reported, and between 19.8% and 25.8% of the conversion value, came from add-to-cart and begin-checkout events. Nothing in the interface labels this. The column reads "Conversions". The value column reads "Conv. value". Nothing about this lives in the storefront. It is 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 was not 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% |
A ROAS calculated from those two fields on either account is wrong by a fifth to a quarter, and wrong in the flattering direction, which is why nobody catches it. One account in three had a clean purchase-only definition, 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.
03 The purest case · Store C only · N = 1
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 is no purchase goal on it. This is one campaign on one account, 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 do not. If you audit only at account level you will never see it.
04 The column beside it · all 3 accounts
"All conversions" was
99.4% to 99.8% noise.
Every account had analytics-imported engagement events registered as conversion actions: page views, session starts, scroll depth, search-results views. They are excluded from the bidding metric, and they dominate the secondary column that sits right beside it. This finding held on all three accounts, and so did the sprawl behind it: every account had at least three enabled purchase actions and counted exactly one.
| 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 do not 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 section 01 measures, seen from a different angle.
Anyone who exports "All conversions" into a spreadsheet, or wires it into a dashboard because it sounds more complete, is reporting a number that is between 99.4% and 99.8% engagement noise. I have seen it wired into client dashboards for exactly that reason. It is the least useful number in the account.
05 Store A only · N = 1
The ad platform claimed most
of the store's entire order book.
This is the three-way comparison, and it runs on one account, because Store A is the one account whose store platform's order table 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 expressed as a share of that book.
The ad platform's counted purchases, the number its bidding optimised toward, equalled 58.5% of the store's entire 90-day order book. Measured on the all-conversions basis, which sums every purchase-category action on the account whether counted or not, the figure rises to 65.9%. Treat 58.5% as the claim and 65.9% as the upper bound.
| Measurement | Share of the order book | What 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 cannot 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 cannot 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 am 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 cannot explain the whole-number return further from the API, so I am 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.
06 Three smaller effects
The reporting convention
moved the total.
Changing only the date basis moved the reported total by up to 7.4%, on Store C. Same account, same window, same conversion actions, with conversions attributed to the day the conversion happened rather than the day the ad was clicked.
| Store | Count moves by | Value moves by |
|---|---|---|
| Store A | 0.0% | 0.0% |
| Store B | +2.1% | +2.2% |
| Store C | +5.8% | +7.4% |
Lookback windows are inconsistent inside single accounts
Store C mixes 30, 60 and 90-day click-through windows across its enabled conversion actions. Stores A and B each mix 30 and 90. Every account has at least three enabled purchase actions, and every account 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 section 01.
| 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 account's reporting day did not match its store's day
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 cannot 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.
07 Method, honestly
What I measured,
and what I did not.
The window
2026-05-13 through 2026-08-10 inclusive. 90 days. The window ends on the last complete day before the pull on 2026-08-11, 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 is 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 reconciliation in section 05 does, and the mechanism is named in caveat 03.
N = 3 is the ceiling, not the typical case. Several findings below 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.
Only stores where I hold the direct client relationship were eligible. Every account managed on behalf of another firm, and every account belonging to a former employer, was excluded from the sample and never queried. 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 is buying the clients their anonymity, and that trade is not 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. |
Definitions that matter
- Conversions. The column that contains only the conversion actions an account or campaign has elected to count. This is what bidding optimises toward. It is not a purchase count unless every counted action is a purchase, which sections 02 and 03 above show is often false.
- All conversions. Every conversion action, counted or not, including page views and scroll depth imported from analytics.
- 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.
- 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.
- 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.
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 did not compare ad-platform conversions against store revenue as if they measured the same thing, because they do not. I did not compare Store B's ads figures against Store B's order count, because the order data was not readable. I did not average across stores, because with N = 3 an average would imply precision that does not exist.
Not measured
- Direct analytics-platform session and channel data. No analytics API credential was reachable. Where an analytics measurement appears here it is that platform’s own purchase event as the ad platform received it, and it is 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 was not 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 does not 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
- 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 am reporting that two systems disagree, not that one of them is lying.
- 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.
- 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 cannot 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.
- 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 is 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.
- 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 was not sent restatements for any of them, so its purchase count includes orders the store no longer holds.
- 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 is 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.
- Spend, revenue and order values are not 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.
08 What to do about it
Six checks I would run
on your account tomorrow.
- 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.
- 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.
- 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.
- Stop reporting "All conversions". It was 99.4% to 99.8% non-purchase on every account here.
- Confirm the ad account reporting time base matches the store platform’s. One of the two verifiable pairs was two hours out of phase.
- 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 public account data and comes back within 72 hours. It cannot see your conversion-action list, but it catches the visible symptoms. The six checks above need read access to the account, and a thirty-minute diagnostic call is where that starts. Either way you end up with your numbers, not mine.
Want this run on your account?
I will tell you which
of your numbers are real.
Thirty minutes on the phone. I look at your conversion actions, your biddable goals per campaign, and how your store order count lines up against what the ad platform claims. You leave knowing which numbers to trust and what to fix first.