The Booking Link Your AI Hands a Guest Isn't Tracked Like an Email Click

Track a link in an email campaign and the hard part is basically done before you start measuring. The link is identical for every recipient, sent from one system, at one known moment, carrying one campaign ID. The email opens, the link gets clicked, and a reservation confirms a few days later: drawing a straight line between those events is mostly bookkeeping, the same straight line this blog has walked through before on the campaign side of things.

A booking link an AI hands a guest mid-conversation isn't that kind of link. It doesn't exist as a fixed asset waiting to be sent out. It gets generated in real time, inside a live exchange, wherever that exchange happens to be taking place: a website chat widget, a WhatsApp thread, a phone call, a Meta DM. There's no send list and no single version every guest received, only a guest asking a question and an AI answering with a link that came into existence at that exact moment.

That's a genuinely different tracking problem. This post is honest about exactly which parts of it are solved, and which parts, right now, are not.

The email click is a solved problem. The chatbot link isn't.

Campaign tracking works because of an assumption baked into it from the start: the system that sent the email is the same system counting the clicks. A journey step or a broadcast send stamps its own link with a campaign ID or a journey ID before it ever reaches an inbox, so every click that follows already knows where it came from.

An AI-issued link has no such stamp to inherit. It isn't the output of a scheduled journey step or a broadcast send. It's the output of a conversation deciding, mid-sentence, that a guest should have a booking link right now. Nothing queued it or scheduled it in advance; the AI produced the link because a guest asked a question that a link happened to answer.

That absence turns out to be the useful signal, not the obstacle. Internally, a link gets recognized as agent-issued specifically because it carries no campaign ID and no journey ID, rather than because it's tied to a send the system already knows about. The lack of a known parent is what marks it as coming from a live conversation instead of a scheduled channel.

How hotel booking link tracking actually works when an AI hands over the link

The mechanism is simpler than it sounds, and the timing detail is the part worth understanding. The tracking token isn't added after the fact, once the AI has already composed its reply and is about to show the guest a link. It's attached at the moment the link is created, inside the conversation itself, before the guest ever sees it.

That ordering closes off an entire category of failure. A token added after a link is already composed depends on nothing dropping it somewhere between generation and delivery. A token that's part of the link from the instant it's created has nowhere to get lost, because there's no gap between the two for it to fall into.

From that point, the mechanism doesn't care which agent produced the link, what the guest was asking about, or which property the conversation belonged to. It only cares that the link came from a live conversation and not a scheduled send. Everything downstream, the conversion event, the attribution, the eventual match to a confirmed reservation, runs off that one distinction.

WhatsApp booking attribution, voice calls, and Meta DMs: one mechanism, four channels

The part worth calling out on its own: tracking an AI-issued link works the same way no matter which channel the conversation happened on. A link a guest gets from the site chat widget is tracked the same way as one sent over WhatsApp, one that surfaces during a phone call, or one dropped into a Meta DM. There's no separate tracking pipeline per channel, no WhatsApp-specific attribution logic sitting apart from whatever the site chatbot uses.

That's a meaningfully different starting point than most hotel tech stacks are built on, where email gets real attribution because it's the oldest channel and everything newer gets bolted on afterward, if at all. A hotel group running its AI across WhatsApp, voice, and social DMs doesn't end up with a separately built, separately tested, separately trusted WhatsApp booking attribution story sitting apart from what the site widget does. It's one mechanism wearing four different channel labels.

The one link we deliberately leave untracked

There's an exception, and it's intentional rather than a gap. Booking.com links never get this tracking treatment. Attaching a tracking token to a Booking.com link risks running into that platform's own rules against disintermediating its attribution, since Booking.com has a legitimate interest in knowing which of its own channels drove a booking made through its own engine.

So a Booking.com link an AI hands a guest stays exactly as Booking.com issued it, untouched. It's a narrower version of a discipline worth applying generally: not every mechanism that could technically be built should be, and a platform's own attribution rules are a real constraint, not an inconvenience to route around.

What this doesn't catch: an anonymous guest, or a guest who switches devices

Two gaps are worth naming plainly, because naming them is more useful than pretending they don't exist.

The first is anonymous traffic. A guest chatting with a site widget before they've been identified, before any lead capture has connected the conversation to a real contact, isn't tracked at all. In a recent 60-day measurement on one property's traffic, that gap accounted for roughly 0.1% of sessions. It's genuinely small, but it isn't zero, and a conversation that starts anonymous and never gets a name attached to it will never register as an attributed conversion, whatever happens afterward.

The second gap matters more in practice: there's no cross-device attribution. A guest who gets a booking link on their phone during a WhatsApp exchange, then finishes the booking later on a laptop, breaks the chain the moment they switch devices. The link and the eventual reservation are both real. The connection between them, from this system's point of view, isn't visible. That's not a bug waiting on a fix. It's an honest limit of cookie-and-token-based tracking generally, and it applies here the same way it applies to nearly every attribution system built the same way.

A "Forever" attribution window that's really about a week on Safari

The attribution window is internally described as Forever, meaning there's no hard cutoff coded in for how long after a click a booking can still be credited to it. In practice, that description only holds on browsers that let it. Safari expires the tracking cookie on its own schedule, well before Forever, which brings the real, usable window down to something closer to seven days regardless of what the setting says. A booking made eight days after a Safari click on an AI-issued link won't get matched back to it, not because the tracking stopped looking, but because the browser already deleted the thing it needed to look at.

There's a second, more specific way tracking breaks: the cookie is host-only, scoped to the domain that set it. Some booking engines route a guest through a different subdomain partway through the booking flow. A host-only cookie doesn't survive that hop. The guest completes a real booking. The tracking simply never sees it happen, because it was watching a domain the guest had already left behind.

How to actually measure chatbot ROI for your hotel

The most important honest fact in all of this isn't any single gap above, it's how a broken install behaves. If the tracking installation itself is broken, it fails silently: zero conversions get recorded, with no error anywhere to flag it. That looks, on a dashboard, identical to a channel that genuinely isn't converting anyone. A hotel group staring at a WhatsApp or voice channel showing zero attributed bookings has no built-in way to tell "this channel isn't working" apart from "this channel isn't being measured."

Which means the real first step in measuring chatbot ROI for a hotel isn't reading the number. It's confirming the number is capable of being nonzero in the first place, checking the install's actual status rather than assuming it's fine because nothing complained. That's the same discipline worth applying to every number a hotel team is shown: an analytics view that's honest about what it doesn't yet know is worth more than one that quietly assumes the best case and never says so.

None of the gaps above make AI-issued link tracking useless. They make it a specific, bounded tool: channel-agnostic, attached at the moment of creation, and honest about exactly where it stops.