The Ads Kept Running on Four Platforms. The Conversions Stopped Arriving on All of Them.
When a beach resort switched booking engines mid-campaign, the ad money kept flowing — but the signals telling the platforms what was working went dark.
The ads never stopped running. The data did.
Divi Aruba is a beach resort running ad campaigns on Google Ads, Facebook, and TikTok. Guests browse the resort’s website. When they’re ready to book, they’re sent to a booking engine on a separate domain. This is normal for hotels — the actual purchase happens on a system the resort doesn’t control.
Then the resort switched booking engines — from ReservHotel to SynXis. A normal business decision.
But the moment the switch went live, every conversion tag pointed at pages that no longer existed. The confirmation page — the moment a browsing guest becomes a paying guest — now lived on a different domain. None of the tracking knew it existed.
Campaigns kept spending on Google Ads and TikTok. Conversion data stopped arriving. The platforms were optimizing blind, and nobody could answer the only question that matters when you’re paying for ads:
Which of our campaigns are actually producing bookings?
That was the brief: reconnect the tracking to the new booking engine.
But when the GTM container was opened up, the broken connection turned out to be only the newest layer of the problem.
Why booking engines break tracking
Most hotel booking engines live on a third-party domain. The guest starts on your website and pays on someone else’s.
Browsers treat that jump as leaving your site. The session splits. Attribution resets. The booking engine starts showing up in your analytics as a “traffic source” — as if it were a marketing channel instead of your own cash register.
Without the right setup, every guest who crosses from the website to the booking engine starts a new session. The booking gets credited to the booking engine’s domain — not to the campaign that actually drove it.
It’s like the cash register taking commission on every sale the sales team closed.
And when you swap booking engines, every tag and trigger built for the old one dies silently. No error messages. No alerts. The dashboards just go quiet — while the ad platforms keep spending.
What the audit found underneath
Before rebuilding anything, the full GTM container needed an audit. Reconnecting tracking to a foundation you haven’t inspected just moves the problem.
The audit showed the migration hadn’t simply broken the tracking. It had exposed years of mess underneath.
Seven Universal Analytics tags were still in the container — tags for a platform Google shut down completely. Next to them: triggers and variables still wired to ReservHotel, the booking engine the resort no longer used. Old code firing at nothing, making it impossible to tell what was alive and what was dead.
The container was a house where every previous tenant had left their furniture behind. Before anything new could be built, the old booking engine’s ghosts had to be cleared out.
And there was something else in the audit — a finding that changed the whole project. It comes later in this story, the same way it came later in the work.
Rebuilding for the handoff
The approach wasn’t to patch the old tags onto the new booking engine. It was to rebuild the whole stack around one simple fact: conversions happen on a domain the resort doesn’t control. The tracking has to be built to survive that handoff — this migration, and the next one.
The order mattered.
First, the cleanup. All seven dead tags came out, along with every old ReservHotel trigger and variable. Everything that stayed was renamed so anyone could understand it at a glance. You can’t maintain or debug a container full of dead code.
Then, the two domains had to learn to speak to each other. Cross-domain tracking was set up between the resort’s website and SynXis, and SynXis was added to the referral exclusion list. Now a guest crossing from the website to the booking engine stays one session, one journey, one attribution path. The cash register stops taking commission.
Then, tracking had to exist where the money actually changes hands. GTM was installed on the SynXis booking engine itself. That took two extra steps: security whitelisting so the tags could load at all, and a custom delayed trigger for the confirmation pages — because SynXis confirmation pages don’t fire standard triggers reliably. The most valuable page in the whole funnel was also the hardest one to track. Standard triggers would have silently missed it.
With the foundation in place, each platform’s conversion signal was rebuilt: GA4 purchase events with transaction IDs and revenue, Google Ads conversions with values, TikTok Purchase events restored.
Finally, everything was routed server-side through a Stape endpoint on a first-party subdomain — with deduplication checked on every platform. Server-side delivery keeps the tracking alive despite browser privacy restrictions. And it means the next booking engine migration becomes a small configuration change instead of a crisis.
On April 9, the full booking flow was tested end-to-end in GTM Preview Mode. For the first time since the migration, a booking on SynXis registered as a conversion — with its transaction ID and revenue attached.
The finding that changed the scope
The project started with a reasonable assumption: the booking engine switch broke all the conversion tracking.
For Google Ads, GA4, and TikTok, that was true. The migration killed working signals.
Facebook was different. When it came time to restore the Facebook tracking, there was nothing to restore. No pixel. No Purchase event. No conversion signal — ever.
The resort had been running Facebook conversion campaigns against tracking that never existed. Facebook’s algorithm — the machinery that decides who sees the ads — had been running from day one without a single booking signal to learn from.
The migration that “broke everything” had actually revealed a gap that was there all along. Facebook tracking wasn’t rebuilt for Divi Aruba. It was built for the first time — base pixel and Purchase event, on both domains, validated in Facebook Events Manager.
This is why the audit comes before the rebuild. The visible problem is rarely the whole problem. Sometimes it’s just the first thing that finally made someone look.
Four platforms, one reliable signal
All four platforms — GA4, Google Ads, Facebook, and TikTok — now receive booking conversions with transaction IDs and revenue, delivered server-side, with deduplication verified everywhere.
The resort’s team can now optimize campaigns against real booking data on every platform they advertise on — including Facebook, for the first time ever. Documentation and a video walkthrough sit alongside the build, with a support period so the setup stays easy to maintain after handoff.
The project grew beyond its original timeline — because building Facebook tracking from scratch wasn’t in a brief that assumed it existed. That’s what audits do: they find what the brief couldn’t know to ask for.
Three questions worth asking about your own booking funnel
If your customers pay on a booking engine, checkout platform, or any domain that isn’t yours, check these:
01
Open your GA4 traffic sources report and search for your booking engine’s domain.
If it shows up as a traffic source, your cross-domain tracking is leaking — and your booking engine is taking credit for bookings your ad campaigns drove.
02
Open your GTM container and count the tags pointing at platforms or domains you no longer use.
Dead tags aren’t just clutter. They tell you nobody has audited the tracking since the last migration — which means the live tags probably haven’t been checked either.
03
For each platform you run ads on, open its Events Manager and confirm a Purchase event fired in the last 48 hours.
If any platform shows silence, you may be paying for optimization against a signal that doesn’t exist. One of Divi Aruba’s four platforms was — and nobody knew.
Booking engine migrations don’t break tracking by accident. They break it by design — because tracking built around one vendor’s confirmation page was never going to survive the switch to another’s.
The question a migration really asks is the one nobody wants to hear mid-campaign: was the tracking ever built to survive anything?