Stop Guessing Where Your Bookings Come From: The Attribution Problem Inside FareHarbor, Bokun & Peek Pro

If you're running Google Ads for tour operators or Meta Ads for your tour operation, there's a high probability your conversion data is wrong. Not slightly off — potentially missing 20 to 40 percent of actual bookings, depending on your audience's device mix and browser preferences.

This isn't a configuration error you can fix in Google Ads. It's a structural problem built into how FareHarbor's Lightframe and Peek Pro's booking widget handle data — and it predates any campaign setup mistakes you may or may not have made.

Here's exactly what's happening, why it matters, and what server-side tracking actually does to fix it.

What is the FareHarbor conversion tracking problem?

This means the standard Google Ads or Meta pixel tag on your website never fires on a completed booking. The conversion event lives inside an environment your tracking scripts can't reach through normal means.

FareHarbor's workaround is to add pixels directly to the FareHarbor Dashboard — meaning Google and Meta receive the signal from FareHarbor's servers, inside an iframe, after the booking completes. This works for desktop Chrome in a clean session. It doesn't work reliably in several common scenarios that represent a significant portion of your actual booking traffic.

Why does iOS kill so many booking conversions?

For your tour business, the consequence is this: Safari on iPhone and iPad actively blocks third-party cookies. When your traveller loads FareHarbor's Lightframe inside your website, Safari sees fareharbor.com as a third-party domain relative to your website. It blocks the cookies and tracking scripts that FareHarbor uses to pass conversion data.

In 2026, Safari represents approximately 17 percent of global browser market share. Among mobile users specifically, iPhone Safari is consistently between 25 and 35 percent of traffic for UK and US travel audiences — the exact demographics booking your experiences.

If between a quarter and a third of your mobile visitors are on Safari, and Safari systematically blocks cross-domain iframe tracking, your conversion data has a structural hole that no amount of Google Ads optimisation can see through.

Does Peek Pro have the same tracking problem?

The specific technical implementation differs between the two platforms — Peek Pro offers a tracking configuration panel under Configuration > Analytics — but the fundamental problem is identical. Any time a booking checkout crosses domains (your website to a third-party booking platform), the cookies and client-side scripts that advertising platforms rely on are at risk from ITP and ad blockers.

Roller, WeTravel, and Redzy present variants of the same challenge. The degree of tracking degradation varies by platform and implementation method, but none are immune to the iOS/Safari attribution gap.

The platforms with the cleanest native tracking are those where the checkout stays on your own domain — either through a white-labelled checkout or a server-to-server integration. Most tour operators aren't in this position.

FareHarbor vs Bokun vs Peek Pro: how the tracking compares

The takeaway: the platform you use barely changes the size of the problem. What matters is whether the booking confirmation is captured server-side and sent directly to Google and Meta — the only approach that survives iOS restrictions and ad blockers across all three platforms.

How much conversion data are tour operators actually losing?

That figure compounds across several sources of loss:

iOS/Safari ITP blocking: Safari's cross-domain iframe restriction systematically removes a predictable percentage of bookings from any device running iOS or macOS Safari. For travel businesses with a high mobile booking rate or a UK/US/Australian audience demographic, this is the largest single source.

Ad blockers: Browser extensions like uBlock Origin and Ghostery, and privacy-focused browsers like Brave and Firefox Enhanced Tracking Protection, block advertising pixels entirely. Ad blocker usage among tech-savvy travellers — a disproportionately likely demographic for independent tour operators and experience-based travel — runs at 30 to 40 percent in some audience segments.

Consent mode and cookie banners: GDPR-compliant consent management, if not implemented correctly with Google Consent Mode v2, can block conversion tags for users who decline analytics cookies. A declined consent does not mean a booking didn't happen.

The optimisation problem this creates: Google's Smart Bidding and Meta's delivery algorithm both optimise toward the conversions they can see. If your tracking only captures 65 percent of actual bookings, your campaigns are training on incomplete data — bidding as if certain ad groups, devices, or audiences are underperforming when the reality is simply that their conversions are invisible.

A campaign that appears to be delivering £45 cost per booking may actually be delivering £29 cost per booking once recovered data is in the picture. Or it may be £60. Without complete data, you cannot know which.

What is server-side tracking and how does it fix the problem?

This matters for tour operators in two specific ways:

Meta Conversions API (CAPI): Rather than relying solely on the Meta Pixel in the browser, CAPI sends purchase events from the server after a confirmed booking. It bypasses ad blockers and iOS cookie restrictions entirely, because the signal never travels through the user's browser at all. Meta matches the event to a user via hashed customer data (email, phone, name) rather than browser cookies.

Google Ads enhanced conversions: Server-side enhanced conversions send hashed first-party data (email address from the booking confirmation) to Google's API, allowing Google to match the conversion to a logged-in Google user even when browser tracking failed. This recovers a meaningful proportion of the iOS gap.

At Tourify, we implement server-side tracking using Taggrs — a managed server-side Google Tag Manager infrastructure — alongside platform-specific integrations for FareHarbor, Peek Pro, Roller, WeTravel, and Redzy. The result is a complete, deduplicated view of booking conversions — the standard across every travel marketing agency engagement across all channels, including the bookings that client-side tracking was silently discarding.

What does a tracking audit for a tour operator actually look like?

1. Booking platform implementation: How is your platform (FareHarbor, Peek Pro, Roller, etc.) currently configured to fire conversion events? Is the pixel added inside the platform dashboard, on your website, or both? Are there duplicate events creating false inflation?

2. Cross-domain journey mapping: Where does the booking flow transfer between domains? Every domain transition is a potential tracking break point.

3. GA4 purchase event verification: Are purchase events (with revenue values) firing in GA4's Realtime view when a test booking is made? GA4 is the source of truth most platforms recommend — but it also sits behind the iframe problem.

4. Google Ads conversion import: Is Google Ads importing conversions from GA4, from a direct tag, or from both? Duplicate conversion actions are one of the most common causes of inflated conversion counts.

5. Meta pixel + CAPI event match quality: Inside Meta Events Manager, what is the Event Match Quality (EMQ) score for purchase events? An EMQ below 6 out of 10 indicates significant attribution loss. A properly configured server-side CAPI setup typically achieves 7 to 9.

6. iOS vs non-iOS booking split: Cross-referencing booking platform data against GA4 sessions by device and browser reveals the exact scale of the iOS gap before any fix is applied.

7. Consent mode configuration: Is Google Consent Mode v2 implemented? Does declining analytics consent in your cookie banner suppress conversion tags that should still fire (or fire via modelling)?

8. Attribution window alignment: Are the attribution windows in Google Ads, Meta, and GA4 aligned with your actual booking lead times? Tour operators with 4–8 week consideration windows frequently under-attribute the campaigns responsible for initial awareness.

Will FareHarbor or Peek Pro fix this automatically?

The problems are:

These integrations still route through GA4, which becomes the attribution intermediary for Google Ads. If GA4 itself has implementation gaps — and in most tour operator setups it does — the problem persists upstream.

Neither platform provides a native Meta CAPI integration. Meta attribution for FareHarbor and Peek Pro bookings remains browser-dependent unless you implement CAPI independently.

Neither platform gives you a unified view of booking attribution across both Google and Meta. You need your own data layer for that.

Server-side tracking isn't a workaround for platform limitations — it's the industry standard for accurate attribution in 2026. The platforms are not going to solve the iOS ITP problem on your behalf, because it's not a problem they can solve: it's a design choice Apple made that affects all cross-domain data transfer.

How does inaccurate tracking actually affect campaign performance day to day?

Smart Bidding is only as good as the data it learns from. Google's Target CPA and Target ROAS bidding strategies optimise toward the conversion events they can observe. If iOS bookings are systematically invisible, the algorithm develops a distorted model: it learns that certain campaigns, ad groups, keywords, or device types are underperforming and reduces bids accordingly. You end up deprioritising your iPhone traffic — often some of your highest-intent bookers — not because the strategy is wrong, but because the data that informs it is incomplete.

The same dynamic applies on Meta. If your CAPI isn't implemented, Meta's delivery algorithm is optimising campaigns toward a subset of your actual converters. It builds lookalike audiences from an incomplete seed. It under-delivers to demographics that would book but whose bookings aren't reported back.

The compounding effect: an account running on broken tracking for 6 to 12 months has trained its algorithms on bad data. Fixing the tracking is step one. Rebuilding algorithmic confidence in the correct signals takes additional time and budget.

This is why we always audit tracking before making any campaign recommendations. Optimising spend on top of broken measurement is, at best, wasted effort.

Frequently Asked Questions