Automotive repairClient work

16 Days Before Shopify's Deadline: Rebuilding Measurement for a Headless Store

How a headless US Shopify retailer won back source attribution, cut duplicate purchases to zero and finally subtracted refunds.

The brief

Context

A US automotive-repair retailer sells parts through a headless Shopify setup: the storefront is a Next.js app on its own domain, while checkout runs on Shopify’s separate domain. It advertises on Google, and it needed measurement it could trust.

I was brought in in July 2026 to rebuild the measurement end to end before Shopify retired the mechanism its checkout tracking depended on. The new purchase tracking went live on 10 August, sixteen days before the 26 August cutoff; the storefront half was merged and deployed on 18 August.

Client details anonymised. Figures read from live platform APIs in August 2026.

Sounds familiar?

Symptoms

The situation Automotive repair

The client’s reports looked healthy and were close to empty. Sales clearly happened — orders arrived, shipped and were paid for — but the reports could not say which ad produced them.

In the 29 days before the work, 612 sales reached analytics and only 39 carried any session source at all (6%). The rest were recorded as if they had arrived from nowhere.
In the 28 days from 12 July to 8 August, across 605 orders, the number credited to Google — paid or organic — was zero.
Purchases were reported twice: two separate producers sent the same sale into the same property, showing roughly double the sales the store had made.
Refunds were invisible. The property had recorded no refund in its history while the store returned money across 211 refunds in 90 days, so the reported revenue was overstated and the ad platforms were bidding as though it had been earned.
The lead events that matter to a repair business — phone clicks, phone-number reveals, email clicks, contact-form submissions — had been wired into a Google product that shut down in 2023, so none of them had counted for two years.

Tick the lines that describe your case.

Describe my task

The investigation

Diagnosis

I audited the web and server Tag Manager containers through the live API, so the exported configuration matched production with no drift, then confirmed each finding by capturing the real network requests leaving a live checkout and storefront.

Two root causes carried the damage.

A server-side rule was discarding purchase events

One rule inside the client’s own server container was dropping every purchase that carried a session and a source before it reached analytics. What did get through came from Shopify’s Google app, sent blind, with no session attached — which is exactly the pattern the reports showed.
The storefront and the checkout identified different visitors

The checkout was using Shopify’s internal visitor token rather than Google’s client id. Every checkout event was therefore attached to a different user than the storefront visit that produced it, so a sale and its source could never be joined. On a headless store this is the fundamental fault: the sale and the visit that produced it are recorded as two unrelated strangers.

The audit also found: a rule that silently discarded orders above a hard value threshold; HubSpot loading twice on every page; fourteen dead Universal Analytics tags; and a Meta access token issued by a third-party app that neither side could rotate.

After delivery, checking a flattering claim, I found automated traffic — about 100,120 sessions from one country over twelve months, roughly a sixth of everything the property recorded, six seconds each, one page each, zero sales and zero leads. It had been running since August 2025. I told the client with no charge.

Handover

What I built

Delivery noteDelivered Aug 2026

An identity bridge. The Google client id and the ad click id are now carried onto the Shopify order as cart attributes, and a checkout-side custom pixel reports with session context. This is what made a sale traceable back to the ad that produced it.
One producer per destination. The old page-based purchase tags for Google Ads, Analytics, Meta and Bing were retired, and the duplicate from Shopify’s app was switched off, so two systems can never report the same sale.
A server-side leg in named, versioned workspaces: GA4 with a server-set first-party cookie, Meta CAPI, Bing, and confirmed-after-before evidence for each.
Refunds. Rather than relying on a webhook, the setup fetches successful refunds from Shopify on a schedule and sends them to analytics, each checked against Google’s validation service and recorded so none can be sent twice.
Lead measurement. Phone clicks, phone reveals, email clicks and contact-form submissions became key events, counted once per session rather than once per click, so one customer tapping a phone number three times is one lead, not three.
US privacy controls. Opt-out, not opt-in, sized to US state law: no cookie wall, a reachable “Your Privacy Choices” link, and the Global Privacy Control signal honoured before any tag loads. Handed to the client’s developer as a paste-ready package.
A place to see it. A client-facing report, a health dashboard, a knowledge base and a daily monitor that reads the figures and flags deviations.

Before → after

Results

Client work Done for real clients. Client details are anonymised.

Sales traceable to their source

Aug 2026

6% to 76%

Before
6% (39 of 612 sales in 29 days)

After
76% (settled-day reading, 19 Aug 2026)
Duplicate purchase reporting

Aug 2026

+100% to 0%

Before
+100%

After
0%
Sales credited to a Google ad, per day

Aug 2026

0.1 to 10.5

Before
0.1

After
10.5
Refunds subtracted from reported revenue

Aug 2026

Before
none ever recorded (211 refunds returned money in 90 days)

After
every refund, from 15 Aug 2026
Event types measured

Aug 2026

6 to 13

Before
6

After
13

The full results table

What changed	Before	After	Read on
Sales traceable to their source	6% (39 of 612)	76%	settled days, Aug 2026
Sales invisible to every report	573 of 612, in 29 days	24% still without a source (the complement of the 76% reading)	Aug 2026
Duplicate purchase reporting	+100%	0%	from 15 Aug 2026
Sales credited to a Google ad, per day	0.1	10.5	Aug 2026
Refunds subtracted	none, ever	every refund	from 15 Aug 2026
Event types measured	6	13	Aug 2026

...rebuilt Meta tracking for my funnel with browser + server deduplication, set up the tracking Worker to run on my own Cloudfare account (for full ownership)...

Eve S., Balance Works SL Upwork · 2026

Notes on the numbers

The duplication stopped mid-morning on 14 August and did not return: read hour by hour from the property, eight consecutive hours showed exactly one purchase event per order after the change, against +100% for the preceding days. The whole-day ratio was back to zero on every day from 15 August.

Reading these numbers honestly: the post-fix share is a settled-day figure, and the first days after a fix are noisy. On 19 August it read 76%, and the same measure ranged 73–83% that week and sat higher once the month settled.

I also disclosed, unprompted, six synthetic refund records that had briefly reached the live property while the refund path was being built, and had them removed by the synthetic visitor identity they were sent under.

A note from Daniilbefore you decide

What this means for a similar business

If your storefront and your checkout are on different domains and nothing carries the visitor across the hop, your ad platforms learn from the fraction of sales they happen to see. Their budgets follow that fraction. The fix is not a better dashboard; it is identity that survives the hop and refuses to be invented.

Two numbers change what the platforms actually learn: the share of sales carrying a real source, and refunds. Most stacks never subtract refunds, so every bid is set against revenue that has already come back.

And a fix nobody can see is not a delivery. A live report, a monitor and plain documentation are part of the work, not extras.

— Daniil

Situations this case answers

All situations

Read another case

2.9 Conversions per Real Submission: An Event Contract for a Marketplace

How a UK marketplace cut Google Ads from about 2.9 conversions per real submission to one event per action, reconciled against its own records.

Hi, I’m Daniil.

I work with you from defining the problem to implementation and handover. You talk to the person who does the work. I work in English and Russian.

My story My work

Have a similar task?

Describe your task

The first answer is free, within one working day. Or write directly: next@taskfordaniel.com