Replatform without losing three months of attribution
Redesigns and replatforms break tracking almost every time, because tracking is almost never on the QA list. The container gets dropped from the new templates, URL-based triggers stop matching, the data layer is rebuilt with different key names, and forms move to a library nothing is listening for. It goes unnoticed for weeks because the site looks fine and the conversion decline reads as seasonality. We rebuild it — ideally before launch, and fast afterwards if you're already past that.
Free30 minutesNo obligation
Repair & migration · what breaks
When to bring us in — Repair & migration
- 01
A replatform or redesign is scheduled
The cheapest moment to involve anyone in this.
- 02
Conversions collapsed on a launch date
And your store's orders didn't.
- 03
A checkout migration is planned
The single most reliable way to break purchase tracking.
- 04
Tracking built by people who've left
Nobody knows what's live or why.
Repair & migration · the fix
What you get out of it — Repair & migration
Tracking live on day one
Verified on the new site before traffic hits it.
Money events off URLs
Fired from records, so the next redesign can't break them the same way.
A pre-launch checklist
So this stops being a recurring cost.
Attribution continuity
Click IDs and cookies surviving the migration.
Repair & migration · architecture
Why the numbers were wrong before you got here — Repair & migration
Worth understanding before buying anything, because it decides which tier you need — and for some readers the answer is that you don't need us yet.
- 1
The browser is the weakest link, and it is getting weaker on purpose
Every browser-side tag has to survive the page loading, the visitor staying, the script running and the request leaving. All four are now contested. The order in your database is certain; the browser event reporting it is not.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits JavaScript-set cookies to seven days whatever expiry you set, so a customer who takes longer than a week to decide returns as a stranger. A cookie your own server writes in an HTTP response is not capped — the single largest practical difference between browser-side and first-party server-side.
- 3
Ad blockers remove the tag with no error
A blocked pixel does not warn anyone. The customer buys, the order lands, and no platform hears about it. First-party events from your own subdomain are not a third-party request and are not filtered the same way.
- 4
Consent is enforced by hope, not by architecture
Client-side consent means trusting each vendor script to honour a flag. A server container decides at the container: a denied destination receives nothing. That is a materially stronger position, and it also stops the over-blocking that discards data no law required losing.
- 5
Checkout can end where your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. Sending the purchase from the order record means it arrives whether or not anyone came back.
Repair & migration · diagnose
How we scope tracking repair and migration
Before quoting. Each step narrows what the work actually is, so the price reflects your account rather than an average.
- 01
Compare backend orders to conversions across the launch dates
Measurement break or business change?
- 02
Confirm the container is on every key template
The most common redesign casualty.
- 03
Check every URL-based trigger against the new structure
Most will need rewriting.
- 04
Check data layer key names against what tags expect
A rename breaks values without breaking events.
- 05
Test every form and payment path on the new site
Live, on a real device.
- 06
Check cookie and click ID continuity
Especially where the domain changed.
Repair & migration · prove
How the work gets proven — Repair & migration
A dashboard turning green proves a dashboard turned green. These are what we hand over instead.
Source of truth
Your backend orders across the launch window
- Every key event verified on the new site with a live transaction.
- Backend orders reconciled against reported conversions across the launch window.
- Money events confirmed firing from records rather than URLs.
- Click ID and cookie continuity confirmed across the migration.
- Reconciled over a fully closed window, matched on ID rather than on totals — totals hide equal and opposite errors.
- Payload evidence captured from real transactions, saved to your own records.
- The same reconciliation repeated 30 days later, because a setup that works once and drifts is the harder failure.
Repair & migration · free audit
What we check in the free audit
- Compare backend orders to conversions across the launch dates
- Confirm the container is on every key template
- Check every URL-based trigger against the new structure
- Check data layer key names against what tags expect
- Test every form and payment path on the new site
- Check cookie and click ID continuity
Checked against
Your backend orders across the launch window
Free30 minutesNo obligation
Repair & migration · when not to buy
When you shouldn't buy this — Repair & migration
We would rather say it now than three weeks into an engagement.
- Your backend orders fell by the same amount. That's a business change and tracking work won't help.
- You know exactly which template lost the container and can restore it yourself.
- The migration is months away and nothing is decided yet. Come back when the new site is stable enough to build against.
- You have a staging environment and a developer who'll run the checks. Give them the checklist and keep the fee.
Repair & migration · what we deliver
What's included in tracking repair and migration
Pre-launch inventory
Every event mapped against the new templates before go-live.
Rebuilt triggers
Against the new URL structure and data layer.
Money events moved to records
Purchase and lead fired from backend and CRM, not pages.
Cookie and click ID continuity
So attribution survives the domain or structure change.
Launch-day verification
Live transactions on the new site, every payment path.
Release checklist
Added to your deployment process, which is the cheapest fix here.
Written guarantee
95%+ tracking accuracy
Measured against Your backend orders across the launch window. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
The correct browser-side build, done properly and verified on a live transaction. Honest about its ceiling: it will not survive Safari's cookie cap, an ad blocker, or a checkout that ends somewhere your tag isn't. If you spend $1K+/month on paid media, start one tier up.
- Correct events, correct parameters, correct values
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover you keep
1st-party server-side
Recommended$800One-time fee · most popular
The tier that changes the outcome rather than patching it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright, with no monthly SaaS.
- First-party server container on your own subdomain
- Money events sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, plus the offline loop that connects closed revenue back to the click. For advertisers whose spend makes an attribution leak more expensive than the build.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
Repair & migration questions, answered
Before launch, against staging. Fixing it afterwards costs more and you lose the conversions in between, which can't be recovered.
Only where click IDs were captured and the clicks are inside the import window. Otherwise those events were never recorded.
Usually two to four days including verification, assuming the new site is stable.
Put tracking verification on the pre-launch checklist and fire money events from records rather than page URLs. Those two changes remove most of the risk.
Free · 30 min
Migrate without losing your attribution
WhatsAppFree30 minutesNo obligation
