Measuring visits and bookings from AI assistants: an analytics setup for hotel websites

AI referral traffic is the share of a hotel website's visits that arrive with an AI assistant as the referring source. You can separate it with a custom channel group in Google Analytics 4, measure the booking engine across domains, and ask guests one fixed question at booking and at check-in. Many AI-assisted trips leave no referrer at all.

The owner opens the monthly report and sees the usual shape: direct, organic, referral, a little paid. Somewhere in those numbers are guests who found the hotel by asking an AI assistant. The report cannot say how many, and no setting will make it say so with certainty. After reading this you will be able to build the channel group that separates traced assistant traffic, connect the booking engine so confirmations keep their source, and ask guests the one question that covers the rest.

Why do AI assistant visits hide in direct and referral?#

Because the report sorts visits by the source the browser reports, and an assistant often reports nothing at all. What arrives without a source is filed as direct; what arrives with an assistant's domain is filed as referral, next to news sites and directories.

A referrer is the address of the page the visitor came from, sent along with the request. If it is missing, stripped or blocked, the visit has no source and the tool files it as direct. An assistant that answers inside an app and opens a link in an in-app browser may not pass the referrer, so the visit looks exactly like someone who typed the address by hand. An assistant that links out from a web page usually does pass a referrer, so those visits sit inside the referral bucket mixed with press mentions, directories and partner sites.

The default channel group has no category for assistants. Nothing in the standard setup separates them, which is why the question "do assistants send us guests" has no answer in the report. This matters more as asking replaces browsing, a shift covered in AI search and hotel websites: what changes when travelers ask instead of browse.

Remember that analytics counts visits, not people. One traveler may appear three times on three devices, and two of those visits may carry no source at all. The practical consequence: you can measure the traced part of assistant traffic, and you must say out loud that the untraced part exists.

Referrers in plain words#

How do you build a channel group for AI assistant referrers?#

Create a custom channel group that places an AI assistant channel above Referrals, then let the tool re-sort past traffic into it. The group is a set of rules, not a new tracking script.

A channel group is a rule-based set of categories for a website's traffic sources. The default group is predefined; a custom group is one you define and name yourself. The limits are fixed: a standard property can have 2 custom channel groups and a 360 property 5, each with up to 50 channels, per [Google's Analytics Help Center, "[GA4] Custom channel groups" (4 Nov 2026)](https://support.google.com/analytics/answer/13051316?hl=en).

You create it under Admin, then Data display, then Channel groups. It needs the Editor role or above, and the usual route is to copy an existing group and edit the copy rather than start from an empty one. The rule itself is a "matches regex" condition on the source field against a list of assistant domains. Google's own help page uses an AI assistants example for exactly this.

Order decides the result. Traffic is included in the first channel whose definition it matches, so the assistant channel must be dragged above Referrals or it will never receive anything. Custom groups can be applied to reports retroactively, so the first month you build one is not a blank baseline: you can look back at last year with the new categories. The group then appears as a primary dimension in the Acquisition reports that support the default channel group, as a secondary dimension in default reports, and inside explorations and audience conditions.

One limit to know before you plan anything clever: the supported fields are source, medium, campaign name, campaign ID, manual ad content, source platform and the default channel group. You cannot build a rule on page content or on what the guest asked the assistant.

Keeping the list current#

Note that the domains on your list are vendor names, that they change, and that the hotel must verify them in its own reports rather than trust a published list. This article deliberately prints no list of its own.

How do you follow the visit into the booking engine?#

By telling the analytics tool that your website and the booking engine are one journey, so the confirmation page is credited to the source that started it. Without that setting, the click ends one visit and starts another with no source.

The usual break: the booking engine sits on another domain. The visit to your site ends at the click, a new visit begins on the engine's domain, and the confirmation carries whatever source the engine's own page reports, often none. Cross-domain measurement is a setting in the analytics data stream where you list the domains that belong to one journey. The tool then carries the visitor's identity across them, and the confirmation is attributed to the original source.

Verify three things: both domains are listed, the engine's confirmation page is reachable, and the whole path has been walked once with a real test booking. A setting that was never tested is a guess. The engine belongs to a third party, and some providers allow the configuration while some restrict where scripts may run. Ask the provider and read the contract before you promise a number to an owner.

Measure the step before the confirmation as well. Visits that reached the engine and did not book is the more actionable figure: it tells you whether the problem is reachability or price. That diagnosis feeds directly into the work described in how to increase direct bookings on your hotel website.

Keep a fallback. If cross-domain measurement cannot be configured, the guest question in the next section is the only source information you will have.

What should you ask guests at booking and at the desk?#

One question with a fixed list of answers, worded identically in the booking form and at check-in, so the two sets of answers can be added together. It catches the guest whose visit left no trace in analytics.

Why ask at all: the question reaches the guest who booked by phone, walked in, or arrived from an assistant that passed no referrer. Analytics cannot see any of them. Design the list short and fixed: a search engine, an AI assistant, a review site, a friend or colleague, a returning guest, other, plus one free-text line. If "AI assistant" is not an explicit option, almost nobody will type it.

Keep the options identical in both places. The desk may phrase the opening differently, but the choices offered must match, or the two sets cannot be merged. At the desk, use a one-line script and ask at check-in, not at checkout. In a group booking the person who booked is often not the person who arrives, so record the answer against the reservation, not the arrival.

Leave the question optional. A required field lowers completion and irritates guests; a skip is acceptable and still leaves you a usable sample. Treat the answers as a sample, not a census: a single hotel will see small monthly counts, so read them quarterly and resist turning four answers into a trend. Do not change the list mid-year without recording the date. A changed list breaks the comparison with earlier months, and the break is invisible six months later.

The answers also tell you how assistants describe you, which is worth checking against the advice in how AI assistants describe your hotel: keeping facts consistent.

What does a monthly view of enquiries and bookings by source look like?#

A single page, one row per source, showing the chain from visits to confirmed bookings, read month over month. The ratios between the columns carry the meaning, not any single cell.

The columns are visits, visits that reached the booking engine, confirmed bookings, room nights and revenue. A drop between visits and engine arrivals is a website problem; a drop between engine arrivals and bookings is a price or availability problem. The rows are the channels of your custom channel group, plus separate rows for the guest-question answers. Never merge the traced and the self-reported numbers into one row without labelling which is which.

Read month over month, and against the same month last year where you have it. Weekly readings on small counts are noise and invite decisions that will be reversed next week. Annotate the page: the date the referrer list was last checked, the date the question or its options changed, the date the booking engine changed. Without annotations the chart tells a story that is not there.

The decisions the page supports are modest and real: whether being described well by assistants is worth staff time, whether the direct channel needs work, and whether the booking engine is losing reachable guests. What the page must never become is a claim that assistants send a particular share of bookings. It shows what arrived with a trace, and the trace is incomplete by design. For what assistants can actually do with bookings today, see can AI assistants book hotels yet? What has been announced.

For example, the numbers above are illustrative: they show the shape of the page, not any hotel's results.

What can this setup never measure?#

The guest who reads an assistant's answer, remembers the hotel's name and types it into a browser later. That visit is direct, and no configuration recovers it.

Zero-click answers are the clearest case: the assistant replies and the traveler never opens a page. The hotel may gain the booking and see nothing at all in the report. Assistants that name the hotel without a link, or that summarize several hotels in one answer, leave no referrer because there was no click. Journeys also cross devices and people: one person researches, another books, a third arrives. Analytics counts visits, not households.

Consent matters too. Analytics cookies and identifiers involve personal data, and where consent is refused the visit may not be measured. Confirm your consent setup, your notice text and your retention periods with a lawyer; this article states no rules under Türkiye's personal data law. Ad blockers and restricted in-app browsers remove some visits before any script runs, and that loss is not evenly spread across sources.

The honest framing: the number is a floor, not a total. Report it as "traffic we could trace", never as "traffic from AI assistants".

What to do next#

Build the channel group this week and add the question to the booking form and the front desk script, then read the first month as a floor rather than a total. The three instruments fit together: the channel group catches visits that carried an assistant's address, cross-domain measurement carries them to the confirmation, and the guest question covers everything that arrived without a trace. Publish the result as traced traffic, with the date the list was last checked next to it.