Connecting HotelRunner to Meta Conversions API

Architecture

How HotelRunner and Meta actually connect

Two systems that know nothing about each other. Everything below exists to give them one shared reference.

1. Step 1

   HotelRunner holds the truth

   Currency matters here more than in most markets. A booking quoted in one currency and settled in another can move materially between booking and arrival.

2. Step 2

   Meta Conversions API needs a click to match

   Meta matches server events to people using whatever identifiers you send, hashed with SHA-256 where required. There is no single mandatory key, which is why quality varies so much between implementations — a poorly matched event is accepted, reported, and worth much less than it appears.

3. Step 3

   The identifier is the bridge

   The fbc and fbp values, captured at the visit and carried into the HotelRunner booking. Without it there is nothing to join on and no tool fixes that.

4. Step 4

   The event source decides reliability

   Send direct bookings at settlement value in a single reporting currency.

5. Step 5

   Deduplication at the destination

   Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.

Diagnose it honestly

Working vs. broken, side by side

Both states look identical from the Meta dashboard, which is why this runs for months before anyone notices.

Diagnostic sequence

Diagnostic order

Each step rules out a class of cause. Run them in order and the last one usually has a single explanation standing.

1. 1

   Count bookings carrying the fbc and fbp values

   The ceiling on everything else. Do this before debugging anything downstream.

2. 2

   Follow one real conversion end to end

   From the ad click through HotelRunner and into Meta.

3. 3

   Fix a reporting currency and state the conversion basis

   Without it, month-on-month comparisons partly measure the exchange rate.

4. 4

   Read Event Match Quality and the deduplication indicator

   In Events Manager, open the event and check both. A low match quality means weak identifiers; a missing deduplication indicator means your event_id pairing is broken.

5. 5

   Read the match rate, not the success message

   Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.

Source-of-truth validation

How it gets proven

Against HotelRunner's own records, not against either platform's dashboard.

• The fbc and fbp values confirmed present on a live booking.
• A real conversion followed from click through HotelRunner to Meta.
• Deduplication confirmed in Events Manager on a real purchase, with the browser and server events visibly paired rather than counted twice.
• Direct bookings reconciled at settled value in the reporting currency.
• Reconciled over a fully closed window, matched per record rather than on totals.
• Re-checked 30 days later.

Straight talk

When you don't need this

Worth reading before paying anyone, including us.

• If Meta already reports conversions that reconcile against HotelRunner's records within a few percent, this join is working and there is nothing to buy.
• Measure identifier coverage yourself first — pull your last hundred bookings and count how many carry the fbc and fbp values. Ten minutes, free, and it tells you whether any of this is worth doing.
• Single-currency properties can report booking value directly and skip the conversion question.
• If you are not running Meta ads at meaningful spend, the Conversions API is effort without payoff. It earns its cost when the optimization signal is worth improving.