An AI-issued booking link isn't a campaign link. Here's exactly how hotel booking link tracking works across every channel, and where it honestly still breaks.
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.
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.
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.
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.
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.
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.
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.
The most important honest fact in all of this isn't any single gap above, it's how a broken install behaves. Left to itself, a broken tag is silent in the worst possible way: zero conversions get recorded, and on a dashboard that looks identical to a channel that genuinely isn't converting anyone. "This channel isn't working" and "this channel isn't being measured" produce the same zero.
That specific trap is why the install reports its own state rather than leaving you to infer it. Every ping the endpoint receives is logged with its outcome, not only the ones that succeed, so the settings panel can tell three genuinely different situations apart: nothing has ever arrived, something is arriving and being rejected, or it is healthy. The rejecting case is the dangerous one, because it is the one that most resembles an honest zero, and it is shown as rejecting, with the reason, the count over the last 24 hours and the origin the fires came from. There is also a no-booking self-test: load any page with ?gm_verify=1 and the install fires once on purpose, so the path can be confirmed without waiting for a real reservation.
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, and then reading the install's reported 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.
Thirty minutes, your real properties, no generic demo environment.
Most hotel chatbots escalate every question they can't perfectly answer. This one only escalates when staff actually have to do something specific about it.
A hotel inbox built to be helpful about everything ends up drafting replies to shipping notices. This one triages first, in four explicit paths, not one AI guess.
A hotel's Instagram DM and the public comment under its own post carry very different risks, and GuestMaker's inbox treats them differently, not the same.
