Alongside, not instead
Every event carries the same event ID your Meta pixel uses, so Meta's own deduplication treats the pair as one conversion. Browser and server together, never double-counted.
The problem
A browser pixel has to survive an ad blocker, a cookie policy, a consent banner and an OS privacy prompt before it reports a single booking. Plenty don't survive all four — and the ones that don't are invisible to you, not flagged as missing.
The bigger problem
A reservation isn't one moment, it's four. The browser is present for exactly one of them — the click. Everything that tells you whether that booking was worth anything happens hours or days later, on OpenTable's servers, long after the browser tab is closed.
Day 0 · 14:02
Booked
Table for six, Saturday 7pm
Day 3 · 19:04
Arrived
Seated — or never showed
Day 3 · 19:06
Covers confirmed
Six became eight
Day 3 · 21:40
Spent $480
The number that matters
So your campaigns optimise toward bookings, not diners. A no-show and the best table of the month look identical to Meta — same event, same value, same signal to go find more people like them.
The fix
OpenTable's servers tell ours about every reservation as it happens, and again as it changes. We match the guest, hash the details, and send the event straight into each platform's conversion API — including Meta's, alongside the pixel you already run.
Every event carries the same event ID your Meta pixel uses, so Meta's own deduplication treats the pair as one conversion. Browser and server together, never double-counted.
There's no script on a page, so there's no ad blocker to dodge, no cookie to expire and no tracking prompt to lose. The reservation is already confirmed when we send it.
Booking, arrival, final covers, real spend — each becomes its own event, so you can optimise toward the guests who actually show up and order.
Signal depth
Two conversions can both say "booking" and be worth completely different amounts to the algorithm trying to find your next customer.
Where it goes
OpenTable's built-in tags cover two destinations, in the browser. The same reservation data, sent server-side, reaches every platform you spend on — with the depth the browser could never carry.
Built into OpenTable — browser side
Two destinations, one event each, subject to everything above.
With OpenJug — server side
Every one of them gets the full event — party size, covers seated, real spend — not just the click.
What it takes from you
Nothing changes inside your OpenTable account. There's nothing to install on your website, no tag manager to open, and no new dashboard for your team to learn. We set it up against your venues and your ad accounts, confirm the events are landing, and from then on it simply runs.
For OpenTable partner managers
OpenJug is built on OpenTable's own documented reservation APIs — no scraping, no unofficial endpoints, nothing bolted onto the booking flow.
Next step
Twenty minutes, your restaurant's OpenTable ID, and we'll walk through exactly which bookings your ad accounts are seeing today and which ones they aren't.