# The booking happens on an external platform that carries none of your tags

- Page: https://attribution-lab.nexusnode.ru/cases/booking-platform/
- Status: in the demo
- Services: GA4, GTM, sGTM, Google Ads
- Updated: 2026-09-22
- In Russian: https://attribution-lab.nexusnode.ru/ru/cases/booking-platform.md

## What is wrong

The ad leads to your website, and the booking is completed on an external booking platform – a separate service where you have no tags and cannot place them. In the reports that booking shows up as "direct" (the visitor came on their own) or as a referral from a site, and the ad that brought it gets no credit.

Example. In a month, ads brought 100 bookings, but 40 of them were completed on the booking platform. Google Ads sees 60. The ads learn from 60, the report shows a result almost twice as bad as the real one, and the budget gets cut in the campaign that brings bookings. The bookings that disappear are exactly the ones that reached payment, that is, the most valuable ones.

**The legend in this demo:** a network of travel agencies in Vietnam. The city site brings the customer, and the booking is completed on an external platform that carries none of our tags. All the businesses are fictional.

## What the business loses

- **The ad identifier is lost on the way to the platform.** Google Ads and Meta optimise towards the conversions they can see. A booking that never makes it back to the ad platform does not exist for bidding.
- **In analytics the sale is "direct".** The booking shows up as direct or as a referral from the site. In the reports the ads look useless, and their budget is the first one cut.
- **The ads learn on incomplete data.** Without the bookings from the platform, the algorithm sees less than half of the result and steers the budget away from what actually brings payment.

## Ways to close the gap

| Option | Pros | Cons | In the demo |
| --- | --- | --- | --- |
| **A traffic-source reference stored on the booking**, returned by the platform's webhook (an automatic notification to your server) | Reliable: the confirmed booking comes back with the journey code on it. | The platform needs a field for it. Checkfront, Regiondo and Bokun have one; FareHarbor states that no tracking information can be passed through parameters or cookies. Checked per platform; the option is not always there. | in the demo |
| **Redirect back to a thank-you page** | Simple. The thank-you page, which has our cookie, attaches the booking. | Only if the platform can send the visitor back to your domain with the booking id. The visitor may never reach that page. | in the demo |
| **The platform's widget on your own domain** (the platform's window inside your page, which emits an event) | The visitor stays on your domain, but the booking form is still drawn by the platform: you embed its widget and receive a "booking created" message from it. | Breaks where the widget sits in a window inside another window, or where the consent state does not reach it. The event arrives only if the platform emits one. | in the demo |
| **Booking through the platform's API** from your own site | The form is yours and the platform only receives the data: your site creates the booking through the platform's programming interface, and the visitor never sees the platform. Unlike the widget, you control both the form and what data goes to the platform. | Development on your side. Not every platform exposes such an interface. | in the demo |
| **Matching by time, tour and price** when the platform returns nothing | Works when the platform gives nothing. | It is a guess, and the demo labels it as a guess: status INFERRED, confidence below 1.00, one click matched to at most one booking. | in the demo |

## What the demo does

The demo keeps one journey record on its own server. The city site carries the journey code into the booking platform as a reference; the platform posts a webhook with that reference, and the booking is joined to the journey: method `booking_reference`, confidence 1.00, status LINKED. The other four platform behaviours are one switch away, above the tours, so you can compare them on the same journey. Some of them honestly lose: with no signal from the platform, what is left is matching by time (a guess) or a lost link. The Data tab also shows the other side: the server container sets `FPID` and `FPLC` on the parent domain, so the browser carries them to the booking platform host as well, which neither reads nor sets them, and the demo shows this in the table as it is.

Consent decides whether any of this happens. In the opt-out regime (US and most of the world) the journey is created at once. In the opt-in regime (EU, UK, CH) nothing is stored and no code is issued until the visitor accepts.

The demo shows the mechanics, not a finished integration. Whether your platform accepts a reference and returns it by webhook is checked against its documentation and settings, vendor by vendor. The demo click id (a click marker) is never sent to Google Ads – validating a real `gclid` needs a live campaign. The demo sets its identifier from the server, which makes it more durable than a script-written one; testing for weeks in every browser is a separate step.

## Open the demo

It opens already set up for this case, with server-side transport. Use a private window for a clean run, because the consent regime and the transport stick in the browser.

- [Auto – the regime follows your location](https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_booking_platform&demo_click_id=GADS-11111&al_case=booking-platform&al_lang=en&al_transport=server&al_regime=auto)
- [Force US – opt-out](https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_booking_platform&demo_click_id=GADS-11111&al_case=booking-platform&al_lang=en&al_transport=server&al_regime=us)
- [Force EU – opt-in](https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_booking_platform&demo_click_id=GADS-11111&al_case=booking-platform&al_lang=en&al_transport=server&al_regime=eu)

The demo shows that a booking completed on an external platform, with none of our tags, comes back to the journey: the platform posts a webhook with the source reference, and the booking is joined with status LINKED and confidence 1.00. Above the tours you switch the way it is attached – compare the reliable reference match with a guess (probabilistic 0.80 INFERRED) and with a lost link (UNKNOWN) on the Journey tab. Where to click and what happens is prompted by the demo itself.

## About the author

Anton Kozhanov – marketing data and attribution engineer. Own server-side Tag Manager on own infrastructure, a first-party loader and cookies, a journey vault with export and deletion. Four years on a theatre's measurement (revenue ×2.3 on his watch, ad spend held near 7% of revenue) and a call-tracking → CRM → ads feedback pipeline for a manufacturer (cost per lead −25%, a 2.5-year low).

## Book a call

Bring your website, booking platform or CRM. We trace the same journey on your systems and decide what is worth fixing first. If you walked through the demo, I open your journey record on the call: what was recorded, what was linked, what was lost.

Form: calendar slot · your website or booking platform · where you notice the gap · how to reach you.