Same Setup, New Brand. Every Test Purchase Went Through — Not One Was Tracked.
A proven server-side setup, copied from one event brand to another, and the weeks spent debugging a problem no one could see from the outside.
The brief was about as clean as they come: take what works, move it somewhere new.
Pamela Vallejo, Strategy Director at SocialPOP / MyGuestList Digital, runs tracking infrastructure across multiple event brands under Whet Travel. Groove Cruise already had a full server-side setup built and proven — GA4, Meta CAPI, TikTok Events API, Google Ads Enhanced Conversions, all running through GTM with a Stape server endpoint.
Shattered Shores, another event brand under Whet Travel, needed the same stack. Same platforms. Same architecture. And critically, the same booking system. Both brands use RezMagic to handle bookings. Customers browse the marketing site, and when they’re ready to buy, they’re redirected to Rezmagic on a separate domain to complete the purchase.
The Groove Cruise setup was already proven on Rezmagic. The containers were portable. The configuration could be templated. On paper, this was a straightforward copy.
It wasn’t.
Weeks of silence
The Shattered Shores marketing site ran on Webflow. GTM was installed correctly there, tags were firing, and the marketing side was clean. No issues.
But the conversions happen on Rezmagic — the booking system on a separate domain. The team tried to get me direct access to Rezmagic so I could handle the installation myself, but it didn’t work out. So the team’s developer stepped in to install the GTM snippets and data layer code on the booking system instead.
Everyone was doing the right thing. Access was attempted. When it didn’t work, someone capable picked it up. The plan was straightforward: install the GTM snippets, add the data layer code, and the server-side stack would pick up the purchase events just like it did for Groove Cruise.
2 weeks went by. Test purchases were made. Nothing fired.
Zero purchase events
No events in GA4. Nothing in Meta Events Manager. Nothing in TikTok diagnostics. Nothing in Google Ads conversion tracking. The entire server-side stack was configured and waiting — and receiving nothing.
I was troubleshooting from my side. Checking the GTM containers, reviewing the server endpoint, and verifying the tag configurations. Everything I could see looked right. The architecture was sound. But without visibility into what was happening in the Rezmagic booking system itself, I couldn’t pinpoint where the signal was breaking down.
This is the nature of tracking work — it crosses systems, and when the problem lives on a system you can’t inspect, even the right debugging process comes up empty. Not because anyone is doing anything wrong, but because tracking installation is sufficiently specialized that a small misstep can cause failures that are completely invisible from the outside.
What direct access revealed
After weeks of troubleshooting from the outside, I asked if we could try getting me into Rezmagic directly. This time it worked.
The problem was visible within minutes.
The developer who installed GTM on Rezmagic had pasted both the header and body snippets into the same installation area. It’s one of the most common GTM installation mistakes — and easy to understand why it happens. If you’re not working with GTM regularly, the two-part installation looks redundant. Both snippets go into custom code areas. Putting them together feels logical. But it causes tags to misfire silently. No error message. No warning. Everything looks installed. Nothing works correctly.
It’s not a developer failure — it’s what happens when tracking is treated as a general development task rather than a specialization. A developer who builds beautiful Webflow sites or manages complex booking systems isn’t expected to know the quirks of GTM snippet placement. The mistake is common precisely because it’s invisible.
But the bigger problem was underneath that: there was no purchase data layer on the booking system at all.
In Groove Cruise’s Rezmagic setup, the purchase data layer pushes transaction data into GTM when a booking is completed — including the amount, order ID, and customer details. That’s the signal the server container needs to forward events to every connected platform.
On Shattered Shores’ Rezmagic setup, that data layer code was never added. Every test purchase was completed successfully from the customer’s perspective. The confirmation page loaded. The booking went through. But behind the scenes, the most important event on the entire site fired nothing.
Zero purchase events. Across every platform. For weeks.
The booking system processed every sale. The tracking infrastructure never knew they happened.
The fix
Once I could see the problem, the solution was straightforward.
First, the GTM installation on Rezmagic was corrected — header snippet in the head, body snippet in the body, properly separated. Then, a purchase data layer was built and installed on the booking system’s confirmation page, so that when a customer completes a booking, the transaction data is pushed to GTM the same way it does on Groove Cruise.
With those two fixes in place, the server-side infrastructure could finally do its job.
The Stape server endpoint was configured with a first-party subdomain for Shattered Shores — routing events through a first-party domain so that tracking cookies survive Safari ITP and iOS restrictions, rather than being capped at 7 days. All four key tracking cookies — _fbp, _fbc, _ga, and _gcl_aw — are managed server-side with extended expiry windows.
Because the booking system only collects first name, last name, and email at purchase, the Stape geographic add-on was activated to enrich the user data sent to platforms. It’s partial enrichment, but meaningful — it improves match rates on Meta CAPI and Google Ads Enhanced Conversions without requiring additional form fields from the customer.
The first test purchase after the fix fired cleanly across all four platforms simultaneously.
What the build revealed
With the tracking operational, something else became visible — not a bug, but a constraint worth understanding.
The Groove Cruise setup tracks a full funnel: PageView, ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase. Six stages from browsing to buying, all visible across every platform.
Shattered Shores’ setup — because of how the Webflow marketing site and the Rezmagic booking system are structured as separate domains — exposes only two trackable moments. PageView on the Webflow site. Purchase on Rezmagic. Everything between those two moments happens inside the booking system’s flow, which doesn’t surface mid-funnel events to the data layer.
Six funnel stages possible. Two are currently visible.
Not constrained by the tracking infrastructure, but by what the booking system makes available.
Pamela now knows exactly where visibility exists and where it doesn’t. If Shattered Shores grows and the booking flow evolves, the tracking architecture is ready to expand into those stages without being rebuilt. The foundation is there. The system just needs to start exposing more moments.
What Shattered Shores runs on now
A correctly installed GTM web container on the Rezmagic booking system. A Stape server endpoint with a first-party subdomain. Server-side cookie management for all four key cookies. Validated purchase events flowing to GA4, Meta CAPI, TikTok Events API, and Google Ads Enhanced Conversions.
Pamela and the SocialPOP team can run paid campaigns on Meta, TikTok, and Google with server-side purchase signals feeding platform optimization — with first-party cookies that survive iOS restrictions.
The tracking that was invisible at the point of conversion — for weeks — now works end-to-end. The architecture proven on Groove Cruise is operational on Shattered Shores, adapted to the realities of a two-domain setup where the marketing site and the booking system live in different worlds.
Three questions worth asking if your customers convert on a separate system
If your visitors move from one domain to another before they buy — a marketing site to a booking engine, a landing page to a checkout platform, a Webflow front end to a separate payment system — these are worth checking:
01
Make a test purchase and check whether a purchase event fires in GTM Preview mode.
If nothing fires, or if GTM loads but no purchase tag triggers on the booking or checkout system, you likely have a missing or broken data layer push — not on your marketing site, but on the system where money actually changes hands.
02
Check whether GTM is correctly installed on every domain the customer touches.
Head snippet in the head. Body snippet in the body. On every system, not just the primary site. If both snippets are in the same field on any domain, your tags may be misfiring silently — no error message, just missing data.
03
Check the match rate on your purchase events in Meta Events Manager or TikTok diagnostics.
A match rate under 60% usually means your tracking is client-side only, your cookies are being capped by Safari ITP, or you’re sending minimal user data. All three are solvable with server-side infrastructure.
The tracking on your marketing site can be perfect. Every tag firing, every pixel loading, every dashboard showing activity.
But if the place where your customers actually pay runs on a separate system — and the tracking installation on that system was handled as a general development task rather than a specialized one — you might be measuring everything except what matters.