Tracking bookings on a hotel website: the events to measure in Google Analytics

Measure four steps on the hotel website: a room search, a room view, a booking started and a booking confirmed, and connect the website and the booking engine as one property so the guest is not counted twice. GA4, the current version of Google Analytics, calls these recorded actions events, and its recommended ones are not sent automatically (Google Analytics Help, accessed 24.09.2026 (opens in a new tab)).

The monthly report says how many people visited the hotel website. Nobody in the room can say how many bookings those visits produced, because the booking engine sits on another address and is counted as a separate visitor. This article sets out a minimum hotel Google Analytics measurement plan: the steps to record from room search to confirmation, how the visit follows into the engine, how to match reported bookings to real reservations, and which one-page report an owner should see each month.

What should an owner be able to answer from the hotel website each month?#

Three questions: how many people visited, how many started a booking, and how many bookings were confirmed and still stand. Everything else on the report is detail under one of those three.

Visits should be broken down by source: the channel that brought the person, whether a search result, an advertisement, a link on another site, a message, or the address typed directly. Booking starts show how many people entered the booking flow, whether or not they finished. That number tells you whether the site persuades. Confirmed bookings are reported with their value after cancellations are removed, because a booking that was cancelled is not revenue.

The distance between starts and confirmations is where the money leaks. The report should show that gap as a number, not hide it inside an average. For example, if 300 people start a booking and 40 confirm, the fix is in the booking flow; if 40 people start and 38 confirm, the fix is on the pages before it, for example in how rooms and rates are presented.

Each row needs one written definition that never changes. Otherwise two months cannot be compared and the report becomes decoration. The report exists to support a decision: which source to feed, which page to fix, which rate to look at. If no decision follows from a row, either the row is missing or it should be removed. For the wider picture, see how to increase direct bookings on your hotel website.

Which events should a hotel website record?#

Four steps carry almost all the value: a room search, a room view, a booking started and a booking confirmed. Google Analytics calls a recorded action an event, meaning one action with a name and a few details attached, and its recommended events are not sent automatically (Google Analytics Help, 7 November 2026 (opens in a new tab)).

The search event records the dates, the number of guests and whether a rate was chosen. Without it you cannot tell a visitor who left from one who never found availability. The room view records the specific room or rate that was opened, which shows which pages and which prices attract attention.

The booking started event fires when the guest enters the booking flow. The payment step is a separate, optional event and should not be confused with the confirmation. The booking confirmed event is the only one that should be marked as the key event, the single conversion the reports count. Marking several makes the count meaningless.

Google's list also includes an information request event for forms and a refund event. The refund event matters if the booking engine reports cancellations back to Analytics. Every event should carry its details: room, value, currency and the booking reference. Without them the reports show counts and nothing else.

Google states that recommended events need their prescribed details to give the most detail in reports, which is why they are not switched on by default (Google Analytics Help, 7 November 2026 (opens in a new tab)). Before committing to an engine, ask for the list of events it sends, using the questions in our booking engine guide.

Why does the booking engine appear as referral traffic?#

Because the guest moves to another address, and without cross-domain measurement Google Analytics counts that move as a new visitor arriving from another site. Referral traffic simply means a visit that arrived by clicking a link on a different website.

Google's help page states that without cross-domain measurement a user who visits two different root domains on the same device is counted as two users and two sessions (Google Analytics Help, 7 November 2026 (opens in a new tab)). With the setting on, Analytics passes the same identifiers from one domain to the next in a short code added to the link address, so one guest stays one user and one session.

The setup sits in the GA4 property settings: Admin, Data streams, the web stream, Configure tag settings, Configure your domains. It needs the Editor role or above and allows up to 100 conditions. Every page on every domain must use the same Google tag ID from the same data stream, or the handover fails silently.

The check is simple: make a test booking and look at the address of the booking engine page. The identifier should be visible in it. Skipping the setting has three costs: the engine's own address fills the referral report, direct bookings look smaller than they are, and the campaign that brought the guest is lost at the handover.

A guest who arrives from an AI assistant and then moves on to the booking engine still has to be carried across as one user, so the same handover check applies. We cover that case separately in measuring visits and bookings from AI assistants.

What has to be settled before any of this is recorded?#

Consent. A tag that records a booking before the guest has agreed to analytics cookies turns a marketing report into a legal question.

Decide what is recorded before consent and what waits for it, and make the consent banner and the tag settings say the same thing. Otherwise some events fire and others do not, and the funnel has holes nobody can explain. When a guest refuses, the visit is often still counted without the identifier, so the booking may appear in totals but cannot be tied to a person or a campaign.

Never compare a period before a banner change with a period after it as if nothing happened. Write the change date on the report. Keep the consent record: what the guest was shown, when, and what they chose. It is the only way to explain a shift in the numbers later.

The banner wording, the retention periods and the lawful basis are questions for the hotel's legal adviser; this article does not settle them. The booking engine usually sets its own cookies on its own domain, so its consent behavior has to be checked separately from the hotel site's.

How do you check reported bookings against the hotel's own records?#

Once a month, place the number of confirmed bookings from the report next to the number of reservations created in the hotel system for the same dates, and explain the difference line by line. The report counts what happened in a browser. The hotel system counts what the hotel must honor. They answer different questions and will never be identical.

Cancellations come first: a confirmation recorded in January and cancelled in February must come out of January's value, or the report keeps claiming money that never arrived. Modifications are next: a changed date or room is one booking, not two, and the booking reference is what ties the versions together.

The usual gaps have names: a guest who refused cookies, an ad blocker, a guest who closed the page before the confirmation loaded, a duplicate send after a refresh, a booking a staff member made on the guest's behalf. A small, stable gap is normal. A gap that grows is a fault, usually a broken tag or a redirect that no longer carries the guest across. Never present the analytics figure as the hotel's revenue; the hotel system is the record, and the report is the explanation.

What goes on the one-page monthly report?#

One page, the same rows every month, with the definitions printed at the bottom: visits by source, booking starts, confirmed bookings, cancellations and the value that remains.

The full row list: visits by source, room searches, booking starts, confirmed bookings, cancellations and no-shows, net value, the five most visited landing pages, and the split between phone and desktop. Keep raw counts beside every percentage. A percentage on a small base misleads, and hotel websites often have small bases per source.

One line of commentary: what changed this month and what the hotel will do about it. Two lines is already too many. Note every measurement change with its date: a new banner, a new tag, a new booking engine. The reader needs to know when a line broke.

One person signs the page. A number with two owners has none. The page must be readable by someone who was not in the meeting, which is the real test of whether the definitions were written down.

What to do next#

Ask the booking engine provider for the list of events it already sends and whether it supports cross-domain measurement, then make one test booking and follow it from the first search to the confirmation in the report. The measurement plan, the consent decision and the monthly reconciliation only work in that order, and the test booking is what proves all three.