How do you track a tourism accommodation, from GA4 to the booking engine? A question every tourism professional with responsibility in management, sales, revenue management or marketing has asked at some point. An essential process that any boutique hotel, hotel chain, campsite or holiday apartment needs, in order to know where the guest who books comes from, what convinced them, and at what point in the conversion funnel the ones who never confirm slip away.
Below we explain in detail what data is actually collected on a website with a booking engine, and why that data can never match up between the two platforms.
Why don’t hosting stats, GA4 and the booking engine match?
When someone visits a website, two completely different types of trace are generated. The first lives on the server: every HTTP request leaves a line in a log with the IP, the user-agent, the URL requested, the exact time and the response code. It’s an objective piece of data, with no consent involved, but also a poor one: it doesn’t identify sessions reliably, nor does it allow a journey to be reconstructed, because each request is an isolated event with no memory of the ones before it, which is why the statistics offered by the hosting server itself bear no resemblance to what GA4 reports. The second trace is the one that carries real analytical value, and it depends on cookies or local storage that do require consent under GDPR. A first-party cookie, such as the client ID that GA4 generates, links several visits from the same browser into one continuous session; a third-party cookie, increasingly residual after the restrictions imposed by Safari, Firefox, Edge and Chrome’s own drift, was mainly used for advertising and cross-domain attribution. On top of this come complementary techniques such as device fingerprinting or the conversion pixels from Meta and Google Ads, which try to compensate for the loss of cookies with probabilistic models instead of direct records.
This is where the first serious problem appears for any tourism accommodation trying to measure its full funnel: the website and the booking engine almost never share a domain, and that technical border breaks the continuity of the trace. Ten years ago, comparing Google Analytics sessions with the engine’s bookings was already methodologically questionable, but it at least had an interpretable logic if you accounted for the obvious limitations, because cookies operated without needing consent and tracking covered the vast majority of traffic; the discrepancy between both sources existed, but the figures were more or less manageable. The engine, loaded in a subdomain or an iframe, cut off the Analytics session, which lost track of the conversion, and the tracking ended up showing mistaken conclusions about which channel or campaign was actually working.
Cookie consent, the biggest barrier for GA4
In today’s landscape, collecting visitor data has become structurally and permanently more complicated, largely because of cookie consent, though there are other reasons too. With the rise of countless tools designed to avoid tracking, a significant share of visitors automatically reject tracking, and to make up for that gap, GA4 applies statistical modelling that fills the holes with estimates, not with real behavioural records. The booking engine, by contrast, doesn’t estimate anything: it counts confirmed transactions using server-side data, with no sampling and no model involved. Comparing both sources to draw conclusions about conversion or channel attribution is no longer an analysis with an acceptable margin of error, it’s comparing two systems that measure different realities with different methodologies, and any commercial decision built on that comparison rests on a foundation far more fragile than it appears.
On top of that structural opacity there’s an extra layer growing faster than most analytics dashboards can reflect: the anti-tracking software users install voluntarily. Extensions and programs such as Malwarebytes Browser Guard, Ghostery or Privacy Badger, together with the native blockers already built into browsers like Brave, Safari with its Intelligent Tracking Prevention, or Firefox with Enhanced Tracking Protection, intercept the GA4 script or the conversion pixel before it ever fires, so the visit doesn’t even show up as a lost session, it simply doesn’t exist for the measurement tool. VPNs add a different kind of distortion: they don’t block tracking as such, but they mask the visitor’s real IP and often alter their apparent geolocation, which throws off geographic origin reports and can cause the same person to register as two separate sessions if they switch VPN servers mid-browsing. The combined result is that a portion of traffic, and precisely the portion most sensitive to privacy, ends up systematically invisible or misattributed in any tool that relies on client-side JavaScript, which only reinforces the idea that the booking engine’s server-side data should be the anchor for any serious conversion analysis, not a complement to the Analytics data.
That said, it is possible to follow a traveller’s journey from the website visit through to the booking on the engine, though it requires deliberate configuration rather than whatever comes “out of the box” in most installations, which in most cases means bringing in a company that specialises in Google Tag Manager and is able to work with code. The first requirement is cross-domain tracking: if the engine lives on a different domain or subdomain from the website, GA4’s cross-domain measurement needs to be configured so the client ID travels between both without breaking, something many third-party booking engines don’t support natively and which often forces you to work with URL parameters or with the engine provider itself. The second requirement is instrumenting the engine with the same standard events used by any e-commerce site: booking process started, room selected, guest details entered, payment started and purchase confirmed, each with its own timestamp and transaction ID. Without those intermediate events, the engine only reports completed or abandoned bookings as a block, with no visibility into exactly where the lead is lost. The third requirement, increasingly relevant given the impact of consent on data quality, is to consider a server-side Google Tag Manager container, which allows events to be sent from the hotel’s own server rather than relying exclusively on the user’s browser, improving measurement reliability even when the visitor has restricted client-side tracking, all without breaking whatever data protection law applies.
Your booking engine and its legal responsibility
Precisely because all this instrumentation involves processing personal data, the technical room for manoeuvre is shaped by a legal framework that deserves to be taken seriously, not treated as a formality tucked into a cookie banner. In the European Union, GDPR requires an explicit legal basis for any non-strictly-necessary cookie, which in practice means prior, informed and revocable consent, managed through a consent management platform (CMP) that must record and be able to prove what each user accepted and when; in Spain, the LSSI-CE adds the obligation to clearly inform users before any third-party script runs. Non-compliance isn’t a theoretical issue: Spain’s data protection authority, the AEPD, has sanctioned tourism companies for activating Google Analytics or advertising pixels without valid consent, following a trend already set by regulators such as France’s CNIL or Austria’s Datenschutzbehörde, both of which declared certain configurations of Google Analytics to be in breach of GDPR. Fines under GDPR can reach twenty million euros or four percent of global annual turnover, which is especially relevant for a consultancy or operator with a presence in several countries, where alongside GDPR other regimes also demand attention, such as the CCPA and its successor CPRA in California, LGPD in Brazil, or the specific data protection laws of each Latin American country.
It’s also worth keeping in mind that much of this risk doesn’t depend solely on how the accommodation itself configures things: not every booking engine on the market complies with current legislation on the collection and processing of this data, and some inject third-party scripts, store guest information outside the European Union, or manage consent poorly without the hotel even knowing until an inspection arrives. Signing up with an engine without first auditing how it handles consent, where it stores the data, and whether it complies with GDPR shifts that risk directly onto the accommodation, which remains responsible for the processing even when the failure lies in a third-party provider’s tool, so before signing with any engine it’s worth demanding those guarantees in writing rather than assuming them just because the provider is well known in the industry. On top of this comes the security dimension: the booking engine handles payment data that falls under the PCI-DSS standard, and any server-side tracking architecture needs to be designed so it doesn’t expose or retain sensitive guest information beyond what’s strictly necessary, nor turn the server itself into an additional point of risk in the event of a security breach.
How do you build a conversion funnel that supports your revenue management strategy?
Setting up a useful conversion funnel is about defining the right steps, not stacking up tools. A minimally informative funnel should track, as distinct steps, arrival at the availability page, date and room type selection, the rates and extras screen, the guest details form, the payment screen and final confirmation, each with its own event and its own drop-off rate calculated against the previous step, not against total website visitors. That distinction matters because mixing website traffic with engine steps in a single funnel, without marking the transition between the two systems, is exactly the mistake that leads to false attribution. GA4’s funnel exploration, combined with the confirmed transaction data reported by the booking engine itself and, for those who want to go further, behavioural analysis tools such as Hotjar or Microsoft Clarity to see where users hesitate on each screen, gives a reasonably complete picture of where conversion is being lost.
For a revenue manager, this level of detail isn’t an analytical indulgence, it’s the basis for decisions that move RevPAR directly. A poorly instrumented funnel tends to hide the real reason behind low conversion behind convenient explanations about price or competition, when the actual problem is that the engine loses guests at the rates-and-extras step because the final rate doesn’t match what was advertised, or at the payment screen because the preferred method in the guest’s home market isn’t available. Without that step-by-step breakdown, any decision about channel mix, campaign spend, or adjusting commission against the OTA is made on an aggregate conversion figure that doesn’t distinguish between technical friction and a genuine guest decision, and that leads to fixing price when the problem is checkout, or increasing spend on a channel whose apparent ROAS is inflated by attribution we already know is unreliable. Revenue management as a discipline requires precisely separating how much of a conversion drop is down to commercial strategy, meaning rate, availability or restrictions, and how much is down to digital product friction, because these are different levers managed with different tools.
The truth about data collection
Booking engine data should be treated as the source of truth for anything related to booking volume and revenue, while web behaviour data should be used to understand intent and friction, not to reconcile sales figures or chase absolute certainty. Treating both sources as if they measured the same thing is the underlying mistake dragging down many executives chasing absolute certainty in big data, and also one of the most common smokescreens in the sales pitch of booking engine providers themselves, who sell dashboards and promises of perfect attribution on top of a data foundation that, by design, can never be perfect. Avoiding that trap doesn’t call for more technology, it calls for genuinely understanding how this data ecosystem works and building, from the outset, a measurement architecture designed for the two realities that coexist in any online booking process, always within a compliance framework that protects both the guest and the business itself. For the revenue manager, the final takeaway is that no decision about channel mix, marketing spend or rate parity strategy should ever rest on digital attribution that we already know is partial by design; the data that should truly drive those decisions is the one that confirms the booking, and the rest of the instrumentation only serves to explain why a given booking never happened.
Do you need to audit your measurement setup to know whether you have the right data to make the right decisions? Shall we grab a coffee and talk it through? wecandoit@thenetrevenue.com
