Hotel booking engine tracking: how to test your GA4 handover

Start with the route guests actually take

A booking button can work perfectly while the measurement handover fails. Before using booking reports to judge your marketing, establish which parts of that journey you can actually observe.

This guide applies to hotels whose booking journey moves to a separate domain. Embedded booking widgets and providers that restrict tracking access may need a different implementation.

Open your website on a phone and record where each booking button leads.

Include the main navigation, room pages and promotional offers. A room button might open a different destination from the homepage button. If your site offers more than one language, include each version.

Give each booking route its own row in the test log:

This inventory gives your developer and booking provider something specific to investigate.

Before completing a reservation, agree how to make and remove a test booking. Prefer a provider-supported test process that avoids charges and unintended inventory changes.

Establish whether the standard setup is possible

Google’s standard cross-domain configuration requires the same GA4 tag ID from the same web data stream on the participating pages. It passes identifiers between domains using the _gl URL parameter, helping preserve the measured journey when consent permits.

Ask your booking provider:

• Can our GA4 measurement ID run on the booking pages?
• Which stages and completion events can we inspect?
• Who maintains the integration when the booking interface changes?

If the provider cannot support this setup, document the boundary. Measuring a departure from your website can still be useful, but your reporting should distinguish it from a completed reservation.

Sources: Google Analytics: Set up cross-domain measurement

Run a test with recorded conditions

Record the date, browser, device, starting page and consent choice. Ask your implementer to enable debugging for the test device.

GA4 DebugView displays collected events and their parameters after debug mode is enabled. Google notes that privacy controls or a lack of Analytics-cookie consent can prevent events appearing there. An empty DebugView therefore needs investigation before you conclude that the tag is broken.

Follow one booking route and inspect three things:

1. The destination loads. Check that dates, room selections and language behave as expected.
2. The handover survives. Google recommends checking for _gl on the destination URL. Redirects can remove it too quickly to notice, so a developer may need to inspect network requests.
3. The expected events arrive. Check the booking stages your provider says it supports. A successful page load alone does not demonstrate that the measurement is complete.

Keep debugging evidence separate from campaign attribution checks. Use DebugView to inspect the test events. For campaign attribution, consult GA4’s Acquisition reports, as Google advises.

Sources: Google Analytics: Set up cross-domain measurement, Google Analytics: Monitor events in DebugView

Avoid two misleading fixes

Do not assume a missing outbound-click event means the button stopped working.

GA4’s enhanced measurement ignores outbound clicks to domains included in cross-domain measurement. If your dashboard relies on that automatic event, review its definition after configuring the handover.

Do not treat referral exclusion as proof that the journey is connected.

Google’s unwanted-referral setting tells Analytics to ignore specified referrers as traffic sources. Payment processors are one documented use case. That function differs from passing identifiers between domains, so removing a referral label does not, by itself, demonstrate continuity. This distinction follows from Google’s descriptions of the two mechanisms.

Sources: Google Analytics: Set up cross-domain measurement, Google Analytics: Identify unwanted referrals

Hypothetical example: one hotel, three different findings

The following is an invented diagnostic example, not a client audit or an industry benchmark.

A South African hotel tests three entry points using an agreed consent state and a provider-supported test process.

The useful finding is that the routes require different actions. A homepage test cannot establish that every room and offer page works correctly.

Nor can this small test estimate how much revenue was misattributed. That would require additional evidence.

Finish with an evidence log

For every route, retain:

• The conditions and steps tested.
• The expected and observed behaviour.
• Supporting screenshots or debugging notes without guest details.
• The unresolved issue and responsible person.
• The date and outcome of the repeat test.

Treat the test as evidence about one route under recorded conditions. Repeat relevant checks after changes to booking links, redirects or the provider integration.

If access restrictions leave part of the journey unverified, name that gap in your reporting. You can still make decisions using the evidence available, provided its limits are visible.

Bring your website address, booking-provider name and the routes you want reviewed so the scope can be defined.