Advertising Guide
Meta API Setup for Hotels
The browser stopped reporting. The bookings did not stop happening.
For most of the last decade, measuring social advertising was a solved problem: a tracking script in the browser watched the visitor, saw the booking, and reported it back to the ad platform. The number in the dashboard was close enough to the truth to act on.
That arrangement has been steadily dismantled. Apple’s App Tracking Transparency framework requires an app to ask permission before tracking a user across other companies’ apps and websites, and most people decline. Browsers have independently restricted third-party cookies. None of this stopped the bookings — it stopped the reporting of them.
Under-reporting is not a neutral error.
A campaign whose bookings are invisible looks like a campaign that produces nothing. Managers pause it, and the algorithm optimising toward the visible conversions learns from a biased sample. The measurement failure becomes a budgeting failure.
In Short
Hotel social advertising became difficult to measure because the browser-based signal it relied on was progressively restricted. Apple’s App Tracking Transparency framework requires apps to request permission before tracking users across other companies’ apps and websites, and browsers separately limited third-party cookies; bookings continued to happen, but a growing share stopped being reported. A server-side conversions setup addresses this by sending the booking event from the hotel’s own systems directly to the advertising platform, independently of the visitor’s browser. Two implementation details decide whether it helps. Match quality determines whether a server-side event can be tied to the person who saw the advertisement, and depends on which first-party identifiers are sent with it. Deduplication prevents the same booking being counted twice when both the browser and the server report it. Configured without either, a server-side setup does not restore accuracy — it produces a different set of wrong numbers, and hotels frequently discover this only after acting on them.
Two mistakes that make it worse, not better
Sending events without the data that identifies the guest
A server-side event is only useful if the platform can connect it to a person who saw the advertisement. That connection is made with first-party identifiers the hotel already holds — typically a hashed email address or phone number captured during booking.
A setup that transmits the fact of a booking without those identifiers reports an event nobody can attribute. The dashboard shows activity; the attribution does not improve. Because something is clearly being sent, this failure is often mistaken for success.
This is also why the booking flow matters to measurement. If the confirmation step never captures a reliable identifier, no server-side configuration can recover one afterwards.
Counting the same booking twice
When both the browser and the server report the same booking, the platform must be told they are the same event. If it is not, one reservation is counted as two.
The consequence is worse than an inflated report. The optimisation algorithm now believes certain audiences convert at roughly double their real rate and shifts budget toward them. The hotel pays for a distortion it introduced itself.
Deduplication is not an advanced refinement. It is a condition of the setup being correct at all, and it should be verified before any budget decision is made on the resulting numbers.
What a correct setup actually requires
A server-side conversions setup is frequently treated as a one-off technical task. It is better understood as a data pipeline that has to keep agreeing with the booking system.
The booking system is the source of truth
Events should originate from confirmed reservations, not from a page view that resembles one. Anything else drifts away from reality over time.
Identifiers decide whether it works
Match quality depends on sending first-party identifiers with each event. Without them the event is recorded but not attributable.
Browser and server events must be reconciled
Both channels reporting the same booking is normal. Both being counted is a configuration error with direct budget consequences.
Cancellations should not stay counted
A reservation reported as a conversion and later cancelled inflates the record permanently unless the pipeline handles the reversal.
External Sources
The factual claims about platform behaviour in this guide come from the official documentation below.
- Apple Developer — App Tracking Transparency — the permission framework an app must use before tracking a user across other companies’ apps and websites
- Google Analytics Help — Measure activity across platforms with User-ID — how a first-party identifier joins sessions across devices, and the stated limits of doing so
Related
- Social Media Marketing for Hotels — the channel this measurement work exists to support
- Google Ads Management for Hotels — the same attribution gap on the search side
- Advanced Conversion Tracking for Hotels — how Convertels connects booking outcomes back to campaigns
Frequently Asked Questions
No, and any claim that it does should be treated sceptically. It recovers a meaningful part of the signal that browser restrictions removed, and the amount depends on how good the identifier matching is. The realistic goal is a materially more complete picture, not a return to pre-restriction reporting.
In most implementations both run together, with deduplication telling the platform when they describe the same booking. Removing the browser side entirely discards signal that is still useful for visitors whose events are reported normally.
It is a matter that has to be handled deliberately rather than incidentally. Identifiers are hashed before transmission, and the hotel remains responsible for the lawful basis on which it collects and uses guest data. This is a question for whoever owns data protection at the property, not one to settle inside an advertising account.
Two checks answer most of it. Compare the conversion count reported by the platform against confirmed reservations in the booking system for the same period, and confirm that a single test booking appears once rather than twice. Persistent disagreement in either direction indicates a configuration problem rather than normal variance.
Want to see what your direct channel is actually worth?
We set up the measurement layer on top of your existing systems — which channel brings what, and how much of it turns into revenue.
Get a QuoteOther advertising guides
All advertising guides →Last updated: 30 August 2026