Fix attribution with server-side tracking. Trust the reports again.

What it is

Timeline

1. Week 1

   Diagnostic. Tag inventory, consent audit, reconciliation gap quantified.

2. Weeks 2 to 4

   Server-side stack built in staging. No live changes.

3. Week 5

   Cutover. Old and new running side-by-side for verification.

4. Weeks 6 to 8

   Consent reconfiguration, deduplication, reconciliation tightened.

5. Weeks 9 to 10

   Reporting layer, handover, playbook delivered.

Frequently asked

How much attributable revenue does the rebuild typically recover?

On most engagements we see Event Match Quality move from the 3.0 to 5.0 band into the 7.0 to 8.5 band over six to eight weeks. Combined with consent stack repairs and ad-blocker bypass, that's typically 8 to 18 percent of attributable revenue recovered in year one. At $40K monthly spend, 12 percent recovery is roughly $58K of incremental attributable revenue.

How long does an Attribution Fix take from kickoff to live?

Six to ten weeks. Week one is diagnostic. Weeks two to four are server-side build in staging. Week five is cutover with both old and new running side-by-side. Weeks six to ten are stabilisation, consent reconfiguration, and reporting handover.

Will it cause downtime to the existing tracking?

No. The new stack is built in staging and runs in parallel with the existing setup for at least seven days before the cutover. We only switch off the old setup once reconciliation is within five percent of the CRM. Most engagements need a second pass on deduplication to reach that threshold.

Do we need to be on a specific ecommerce or CRM platform?

No. We've shipped the rebuild on Shopify, BigCommerce, WooCommerce, headless commerce, custom Rails apps, and lead-gen funnels backed by HubSpot, Salesforce, Pipedrive, and Airtable. The architecture is the same; the implementation per platform varies.

What does reconciliation within five percent mean, and why five?

We take an agreed window, usually the parallel run, which is at least seven days of the old and new systems recording side by side and often longer, and compare what each ad platform counts against the system that takes the money or books the job. Within five percent means the platform sits inside that band in both directions, not just on average. Zero is not the target because some divergence is structural: attribution windows differ (Meta's seven-day click against your CRM's date of sale), modelled conversions fill gaps where consent is denied, time zones and currency conversion move totals at the boundaries, refunds and cancellations arrive late, and some browser-level blocking is not recoverable server-side. Chasing zero produces a fudge factor rather than accuracy. Under five percent, a spend decision made off the platform number is the decision you would also make off the CRM number.

What can break during a server-side cutover, and how do you manage that?

The common failures are known ones. Browser and server events double-count if they do not share an event ID. A custom subdomain for the server container with an invalid or unwarmed certificate drops events silently. Replacing a Google Ads conversion action rather than migrating it resets Smart Bidding's learning. Consent misclassification blocks server calls entirely. Client-set cookies shorten attribution windows compared with server-set ones. We manage it by leaving the old stack running untouched, sharing an event ID from the first day so deduplication is provable before the switch, cutting over in a low-traffic window, and keeping rollback to a single container publish because nothing was deleted. We also freeze bid strategy changes through the parallel run, so you can tell what moved the numbers.

What happens to our historical data?

Nothing is deleted. The rebuild adds a collection path, it does not overwrite the old one. GA4 history stays in the property as recorded, ad platform conversion history stays in the account, and if a new property or data stream is warranted we keep the old one alongside it. The real issue is comparability, not loss. After cutover the reported numbers move, and not always upward: recovering events that consent problems or blocking were losing pushes the count up, while removing double-counted events and conversions that were never really conversions pushes it down. Any comparison spanning the cutover date is comparing two different measurement systems. We mark the date in the reporting layer and use the parallel run to quantify the step change in both directions, so you can say how much of the movement is measurement and how much is real. If raw BigQuery export is off, we switch it on early so the history is yours.

Does the work survive a replatform or a CRM change?

The architecture does. The connections at each end do not. The server container, the event schema (what each event is called and which parameters it carries), the hashing and consent logic, the deduplication key, and the reconciliation method are all independent of your storefront and your CRM. What has to be redone is the source: a new storefront has to emit the same events with the same parameters, and a new CRM has to expose the same outcome statuses and IDs for offline import. With the documented schema in hand that is usually a few days of developer time, against several weeks to rebuild measurement from nothing. Two things protect you: the server container sits in your own cloud account under your billing, and the playbook contains the data layer spec you hand the next implementer.

How much of our team's time does the rebuild need?

It splits into two kinds of time. The working sessions are the larger part and they are the point: a 90-minute session each week with the owner and the operating team, which is nine to fifteen hours across the six to ten weeks. We do not run this around you. The technical time on top of that is small, six to eight hours in total. Week one carries most of it: access provisioning, and an hour with whoever can define the outcomes precisely, meaning which CRM status counts as a qualified lead and when revenue is recognised. The one dependency that genuinely moves timelines is your release process. If data layer changes have to ship through it, a developer needs about half a day and a slot in your deploy schedule. On cutover day someone should be reachable to confirm orders and leads are still landing. Nobody on your side needs to write tags.

What does our in-house team need to be able to do afterwards?

Five things. Read the GTM container and edit a tag without guessing. Run the daily reconciliation report and recognise a variance that is out of bounds. Add a new conversion event when a new offer launches, following the naming convention in the playbook. Check Event Match Quality and Google's conversion diagnostics monthly and know what a fall means. Enforce change management, which mostly means nobody drops a new pixel on the site outside the container. That is a competent marketing ops person, or a developer with about a day a month, not a specialist hire. If nobody there can do it, say so on the audit call. A measurement stack with no owner degrades within a couple of quarters, and the playbook and quarterly check-ins slow that down rather than replace the person.

Do you sign an NDA?

Yes. Mutual NDA is standard. We sign before the audit call if you'd prefer to share specifics on the call.

What happens after the engagement ends?

You get a written playbook your team can run, and a quarterly check-in for six months at no extra cost. If you would rather we keep running the account, ongoing management is quoted separately: a fixed fee for the agreed scope, never a percentage of your ad spend.

Do you do the media buying?

Yes, inside engagements where we also own the measurement underneath. The same senior operators who rebuild your measurement run the day-to-day media against it (Google, Meta, the lot). We won't run media on broken data, and we won't hand the buying to a generalist agency that can't see contribution margin. After the engagement closes, the in-house team operates the documented playbook.

Can we just do the diagnostic without committing further?

Yes. The Tracking Audit is a standalone engagement. About a third of clients run that first, then decide whether to take on the larger work.

Are you based in Australia?

Yes. Sydney HQ with a Brisbane office in Hamilton. Our clients are Australian operators turning over $2M to $20M a year.

How is the engagement billed?

Fixed-scope, billed in two or three instalments depending on the engagement length. First on engagement start, the rest against delivery milestones. We do not invoice retainers and we do not lock you into a multi-year commitment.