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.

Get a Quote
ÇB

Author

Çağdaş BayramDirect Booking Revenue Architect

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.

Related

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.

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 Quote

Last updated: 30 August 2026