Your booking button opens a FareHarbor Lightframe. The confirmation page loads on fareharbor.com, not your site. That single detail is why most FareHarbor conversion tracking setups under-report bookings — and why the fix is not another tracking tag.
If you run paid media and take bookings through FareHarbor, there is a good chance your ad platforms are crediting fewer bookings than you actually took. Not because the tags are broken, but because of where the booking completes.
This guide covers what breaks, why, and the setup FareHarbor itself recommends — plus how to verify it is working rather than assuming.
Why does FareHarbor conversion tracking under-report?
Because the booking finishes on a different domain. FareHarbor’s Lightframe opens as an embedded iframe hosted on fareharbor.com, and the confirmation step happens inside that iframe rather than on your website. A conversion tag sitting on your own pages never sees it.
This is documented behaviour, not a bug. FareHarbor’s Analytics Integrations documentation describes the Lightframe and the integration path it requires.
Two things compound it:
- Cross-domain session loss. Without an integration that deliberately carries the session across the boundary, the traveller arrives at fareharbor.com looking like a brand-new visitor from an unknown source. The booking gets attributed to nothing, or to direct traffic.
- Browser restrictions on top. Safari’s Intelligent Tracking Prevention limits first-party cookie lifetime and strips click identifiers from URLs. On a booking journey that often runs weeks between first click and payment, that shortens attribution memory well below the length of the actual decision.
The result is an account where paid campaigns look mediocre, brand and direct look excellent, and nobody can explain why the booking platform shows more revenue than the ad platforms claim credit for.
What setup does FareHarbor actually recommend?
Use GA4 as the source of truth and import those conversions into Google Ads. FareHarbor has a native GA4 integration that keeps the session alive as the traveller moves from your site into the Lightframe, and forwards booking events — including purchase with revenue — into GA4. Importing from GA4 is FareHarbor’s documented best practice, rather than adding separate conversion tags.
That ordering matters, and it is the opposite of what most people try first. The instinct is to add a Google Ads conversion tag and get it firing on the confirmation page. You cannot — the confirmation page is not yours. So the integration has to happen at the platform level.
The setup, in order
- 1. Add your GA4 measurement ID inside FareHarbor. In the FareHarbor Dashboard, go to Settings → Analytics & Tracking, choose to add an analytics service, and enter your GA4 measurement ID. This is what activates the native integration.
- 2. Confirm booking events are arriving in GA4. Make a genuine test booking and watch GA4 realtime. You are looking for the purchase event with a revenue value attached, not just a page view on the confirmation step.
- 3. Import the GA4 conversion into Google Ads. Rather than creating a new tag, import the GA4 purchase event as a conversion action. FareHarbor documents this as the recommended route.
- 4. Set it as your primary conversion action. An imported conversion that exists but is marked secondary will not be used for bidding. This is the step most often missed — the tracking works, and Smart Bidding ignores it.
- 5. Verify against the booking platform. Compare confirmed bookings in FareHarbor against Google Ads conversions for the same window. They will not match exactly — attribution windows and models differ — but the gap should be explainable rather than mysterious.
Why does the number still not match after setup?
Because platform figures are measuring different things, and some of the difference is correct. Google Ads reports conversions against the date of the click; GA4 reports against the date of the conversion. Meta and Google both claim credit for journeys the other also touched. A persistent, unexplained gap is a problem — a consistent, understood one is not.
| Symptom | Usual cause | What to check first |
|---|---|---|
| Zero conversions recorded | Integration not activated, or conversion left secondary | GA4 measurement ID in FareHarbor; primary action in Google Ads |
| Conversions but no revenue | Purchase event arriving without value | GA4 realtime on a test booking — is value populated? |
| Bookings credited to direct | Session not carried across the Lightframe boundary | Whether the native integration is genuinely live, not just tags present |
| Double counting | Native integration plus a manual tag both firing | Remove the duplicate; keep one path only |
| Deposits counted as full bookings | Partial payments recorded as separate purchases | Whether deposit and balance both create purchase events |
When is GA4 import not enough?
When a meaningful share of your revenue closes away from the checkout, or when booking values vary enough that counting bookings equally distorts bidding. GA4 import fixes the domain problem. It does not fix offline closes, and it inherits every client-side limitation GA4 has.
Three situations where operators outgrow it:
- Enquiry-led sales. Private charters, multi-day itineraries and DMC contracts often start with a form and close on a call. Unless those closes are fed back as conversions, the platform optimises toward whichever cheap action it can see.
- Wide value spread. If your range runs from a low-ticket walking tour to a five-figure private itinerary, counting every booking as one conversion teaches the algorithm to buy the cheapest one.
- Heavy iOS traffic. Published 2026 industry reporting puts client-side conversion loss in the 20–40% range, weighted toward iOS. Server-side measurement is how operators recover the part GA4 alone never sees.
That is the point at which server-side tracking for tour operators becomes worth the setup cost rather than an optimisation for its own sake.
How do I know whether mine is working?
Make a real booking and follow it end to end. If a genuine test booking produces a purchase event with the correct revenue in GA4, an imported conversion in Google Ads set as primary, and a number that reconciles with FareHarbor within an explainable margin, it is working. If any of those four is missing, it is not.
There is a longer version of this check — seven tests covering consent, deduplication and offline outcomes — in is your tracking losing you bookings? If you want the underlying reason attribution drifts on long booking journeys, this piece on booking attribution covers the mechanism.
Frequently asked questions
Can I put a Google Ads conversion tag on the FareHarbor confirmation page?
No. The confirmation step loads inside the Lightframe on fareharbor.com, which you do not control and cannot add tags to. This is why FareHarbor documents the GA4 integration and conversion import as the supported route rather than direct tagging.
Do I need Google Tag Manager for this?
Not for the core setup. The FareHarbor integration is configured in the FareHarbor Dashboard with your GA4 measurement ID, and the import happens in Google Ads. Tag Manager becomes useful for everything around it — consent handling, enquiry-form events and later server-side work.
Why do FareHarbor and Google Ads show different booking numbers?
Partly by design. Google Ads attributes to the date of the ad click, while your booking platform records the date of the booking, so any lag between click and purchase shifts figures between periods. Attribution windows and modelling add more. What matters is whether the gap is stable and explainable, not whether it is zero.
Will this track bookings that started on mobile and finished on desktop?
Partially. Cross-device journeys rely on signed-in Google data and modelling, so some are matched and some are not. This is one of the gaps server-side measurement combined with offline conversion feedback closes more reliably than GA4 alone.
Does the same approach work for Bokun, Peek Pro or Rezdy?
The principle does — capture the booking where it is confirmed rather than where you hope the traveller landed — but the mechanics differ per platform. Each has its own integration path, and some are considerably less documented than FareHarbor’s.
Not sure your booking tracking is telling the truth?
We’ll compare what FareHarbor confirmed against what your ad accounts reported, and show you the size of the gap. No pitch, no obligation.
Request a tracking audit →