Tracking Issues with Rezdy Booking Platform Integration – GA4 & Google Ads
Hello,
I’m currently facing a tracking issue with one of our clients who sells weekly event tickets through the Rezdy booking platform. These are events they organize themselves.
The core problem is in conversion tracking via Google Ads: on desktop, ticket purchases occur within an iframe, but on mobile devices, the user is redirected to a Rezdy-hosted domain. Since Rezdy does not allow the implementation of custom Google Ads tracking scripts on their checkout pages, we’re unable to track conversions on mobile effectively.
Although GA4 does offer an integration with Rezdy, we’re still encountering issues. Despite configuring the Measurement ID and linking the domain as per Rezdy’s documentation, and also linking the domain in GA4, over 95% of traffic is still attributed to “direct,” even for paid channels such as Google Ads and Meta. Meta is still able to track conversions more effectively via its own cross-domain methods, though these conversions do not appear in GA4.
This issue is severely limiting our ability to track ticket sales and optimize ad performance within Google Ads.
Has anyone else experienced a similar issue with Rezdy? Are there any proven workarounds, either through GA4, Google Ads, or Rezdy itself? I’m open to paying for a working solution, but it must work.
The short answer is:
This is a classic and very common tracking issue with third-party booking platforms like Rezdy, caused by a breakdown in the Google Click ID (gclid
) and cross-domain communication between your website, the Rezdy iframe on desktop, and the Rezdy redirect on mobile.
The solution isn’t a front-end fix, but an authoritative, server-side integration.
The most reliable and future-proof approach is to completely bypass the iframe/mobile redirection problem by using Rezdy’s own data combined with server-side Google Ads conversion uploading.
You can achieve this affordably by leveraging RezdyConnect API/webhooks to capture the final purchase data, extract the gclid
(if available), and send it via a cloud-hosted solution like Google Tag Manager (GTM) Server Container on a platform like Stape or Google Cloud Platform (GCP) to the Google Ads API as an offline conversion.
This setup will give you accurate, attributable conversion data, fixing both the Google Ads and the “direct” traffic issue in GA4.
The long answer is:
Your experience is frustratingly normal.
The iframe on desktop and the mobile redirect to a separate Rezdy domain break the standard gclid
passage and cookie persistence required for the Google Ads conversion tag to fire correctly and for GA4 to accurately stitch sessions across domains.
Even with GA4’s cross-domain setting configured, redirects and iFrames often interfere with the automatic appending of the _gl
linker parameter, which is why 95% of your traffic is dumping into “direct.”
Meta’s cross-domain tracking is often more robust because it relies on a different identification methodology than Google’s gclid
/cookie-based method.
The issue is that the front-end Rezdy environment is a black box where you cannot manually inject the necessary code to preserve the tracking identifiers or fire the conversion tag accurately on the final thank-you page.
The mobile redirect problem – where the gclid
is lost in the redirect chain before hitting the Rezdy-hosted checkout – is a separate but equally crippling challenge.
The definitive solution is to shift your conversion tracking from the unreliable front-end to a reliable server-side connection.
This is where a RezdyConnect API or Webhooks approach, combined with modern server-side tagging, provides an excellent and cheap solution.
You can configure Rezdy’s webhooks (or use a service like Zapier if you prefer) to fire a server-to-server request every single time a purchase is successfully completed.
This request will contain all the necessary purchase details – order ID
, revenue
, currency
, and crucially, any parameters Rezdy captured from the initial click, including the
if it was passed to the initial landing page.gclid
The data from Rezdy is then routed to a GTM Server Container hosted on a low-cost, high-performance platform like Stape or GCP.
Within the GTM Server Container, you use this incoming data, including the
, to construct a server-side conversion payload.gclid
This payload is then sent directly to the Google Ads API’s offline conversion endpoint, effectively performing a conversion upload from your server environment.
This server-side conversion process, often referred to as Enhanced Conversions or Offline Conversion Import, is highly accurate because it relies on a stable server connection and the authoritative data from Rezdy’s system.
It fixes the iframe/redirect issue because the conversion is recorded after the fact, independent of browser restrictions, and is attributed using the gclid
that you capture and pass through.
Furthermore, for GA4, you can also use the same server-side setup to send a reliable purchase event (a GA4 Standard Event) using the Google Analytics Data API instead of relying on the faulty front-end GA4 tag.
By having a server-side “source of truth” event sent directly to both Google Ads and GA4, you solve the main attribution problem, move traffic out of “direct,” and gain full confidence in your optimization data, often for a very low hosting cost on platforms like Stape, which offers accessible pricing tiers.