Online marketplaceClient work

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.

The brief

Context

A UK online marketplace on Shopify Plus, with a large daily Google Ads budget, tracks two core business actions — a listing submission and an offer — plus the purchase that follows. Its own words to me were that Tag Manager had double counted, someone had tried to fix it, and now it undercounted.

I was brought in at the end of August 2026 for a read-only audit, then asked to specify a repair that the client’s own developer implemented. I specified, verified and monitored; the developer wrote the code.

Sounds familiar?

Symptoms

The investigation

Diagnosis

The audit was read-only and delivered as one milestone: a 30-day reconciliation of the client’s own listing and offer records against GA4 and Google Ads, per event, with the gap and its cause. It produced 36 findings, each labelled by how well it was established rather than by how alarming it sounded.

The core finding was that double counting and undercounting are one problem, not two: both appear where the identity of an event breaks. The earlier fix had not removed the duplication, and a part of it had broken Google Ads delivery. I also confirmed that where a purchase event existed, the order id, date and value joined exactly — 120 of 120.
One reading artifact, not a defect: Google Ads keeps backfilling conversions for about 9 days, so the most recent week always reads low until it settles.

Handover

What I built

Delivery noteDelivered Aug 2026

A canonical event contract. One event_id per business action, with session and click identifiers carried server-side, so an event can be deduplicated on a key rather than on a hope.
A backend-truth contract. The definition of a real submission comes from the marketplace’s own records, so coverage is measured against the business, not against a platform.
Server-side dispatch with session stitching. Listing (sign-up) events are sent from the client’s edge functions with the GA4 session context attached, so a server event keeps the attribution a browser event would have had; the offer and purchase paths are specified in the same contract but were not yet deployed.
A dedup requirement. A unique dispatch claim per event, so a retry cannot create a second conversion.
A daily reconciliation monitor against the marketplace’s own records, with alerts, replacing the hand-run exports.
Change records and rollback. Every change from CH-004 to CH-019 carries its own undo, and there are pre-cutover gate runbooks and a withdrawn-claims log.

Before → after

Results

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

Conversions counted per real submission

Aug 2026 to Sep 2026

Before
about 2.9 in Google Ads (the duplicated signal)

After
one per sign-up action in the server-side measurement; Google Ads attribution of it still open (offers and purchase provisional)
Server-side sign-up events joined to a session

Sep 2026

48–58% to 85%

Before
48–58%

After
85%
Purchase events joining to the order (id, date, value)

Sep 2026

120/120

Before
not measured

After
120 of 120, where an event existed
Backfill lag before the latest week stops reading low

Sep 2026

Before
unknown — read as a loss

After
about 9 days, a reading artifact rather than a loss

The full results table

What changed	Before	After	Read on
Conversions per real submission	about 2.9 in Google Ads (the duplicated signal)	one per sign-up action in the server-side measurement; Google Ads attribution of it still open; offers and purchase provisional	Sep 2026
Server-side sign-up events joined to a session	48–58%	85%	Sep 2026
Purchase join to the order (id, date, value)	not measured	120 of 120, where an event existed	Sep 2026
Backfill lag understood	read as a loss	about 9 days, a reading artifact	Sep 2026

Notes on the numbers

Two things must be said plainly about the state of this work.

First, acceptance is provisional. The sign-up half is the part that is measured and working. A dedup defect on the server-marked identities was still open when this was written, offers had not yet been deployed, and purchase instrumentation had not started. I am not reporting a finished purchase pipeline.

Second, I misdiagnosed one thing and retracted it in writing the same day. Across the engagement, a review that assumed my claims were too generous caught five over-precise statements before they reached the client. I would rather show that process than pretend the first draft was clean.

A note from Daniilbefore you decide

What this means for a similar business

If your platform count swings between double and half, you do not have two bugs; you have one identity problem that shows up differently depending on which path fails first. Check the identity of the event, not the symptom.

Three habits follow. Define one canonical identity per business action and dispatch server-side with a dedup key. Reconcile against your own records — the listings, offers or orders your team already trusts — instead of platform against platform. And state acceptance honestly: say which events are measured, which are still provisional, and which have not started, because a carefully hedged claim is worth more than a clean-looking one.

— Daniil

Situations this case answers

All situations

Read another case

27 Changes, Each With Its Own Undo: Fixing Lead Tracking on a Site I Never Logged Into

Rebuilding lead tracking on a Webflow site I never logged into: 27 changes, each with its own undo, and 15 of 15 negative tests passing.

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