Connecting Olo to Meta Conversions API
Olo sits between a multi-location brand and every channel it sells through, which makes it the only place where a direct order and a marketplace order can be compared on the same terms. Meta's pixel loses a large share of conversions to Safari, ad blockers and iOS, and the Conversions API exists because of it. The join between them succeeds or fails on one thing: whether the fbc and fbp values reaches the Olo order before the conversion happens, because Meta can only match a conversion it can tie back to a click it recognizes.
Free30 minutesNo obligation
Specific to this pair
Olo to Meta: direct orders only, tagged with the location
Send Meta Purchase from direct Olo web orders only, filtered by channel at the webhook, since Rails orders carry names or phones Meta would falsely match. Set _fbc and _fbp on your parent domain or carry fbclid to Olo ordering, use the Olo order ID as event_id on server and pixel, add location to custom_data, and send catering at placement.
For an Olo brand, Meta's Purchase should come from direct web orders only, filtered by the order's channel before anything is sent. Rails orders from DoorDash, Uber Eats and Grubhub have no fbc, but they may carry a customer name or phone. Meta will match those to its users, and orders your ads never touched will look like ad conversions. Filter at the Olo order webhook, not in Events Manager.
Olo's ordering experience often runs on an Olo-hosted subdomain. If it is a subdomain of your own domain, set _fbc and _fbp on the parent domain so the ordering pages can read them. If it is not, capture fbclid on your site and carry it across in the link. Send the server Purchase with the Olo order ID as event_id, and use the same ID on any pixel event from the confirmation page.
Add the Olo location identifier to custom_data on every Purchase, so custom conversions and reporting can be split by restaurant. Catering orders are the timing edge case. They can be placed days before the pickup date, and an event sent at fulfillment may fall outside Meta's seven-day window for website events. Send at order placement and handle cancellations in your own reporting, because Meta cannot reverse a Purchase.
Olo → Meta · what breaks
Why this join usually fails — Olo → Meta
- 01
The fbc and fbp values never reaches Olo
Olo's ordering experience is frequently hosted on an Olo subdomain, and marketplace orders arrive through an API with no browser session behind them whatsoever.
- 02
Marketplace orders inflating the direct channel
Rails is designed to make marketplace demand look like your own order flow, which is excellent for operations and ruinous for measurement. Left unsplit, a good week on DoorDash reads as a good week for your ad account.
- 03
Double counting from broken deduplication
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
- 04
Nothing reconciles afterwards
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.
Olo → Meta · the fix
What working looks like — Olo → Meta
The fbc and fbp values on every order
Conversions arriving in Meta
Events appear in Events Manager with an Event Match Quality score, deduplicated against the pixel, and become usable for optimization and attribution.
Reconciled against the source
Olo → Meta · architecture
How Olo and Meta actually connect
- 1
Olo holds the truth
Rails pulls DoorDash, Uber Eats and Grubhub orders into the same order stream as your own website. They land in one feed and they are not the same thing: one carries a click you paid for, the other carries a marketplace commission and no identifier at all.
- 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
The identifier is the bridge
The fbc and fbp values, captured at the visit and carried into the Olo order.
- 4
The event source decides reliability
Send per-location. A brand with two hundred restaurants running one national campaign learns nothing from a single national conversion number.
- 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.
Olo → Meta · normal or broken
Working vs. broken, side by side — Olo → Meta
Normal, not a fault
The fbc and fbp values present on the order
Sent from the Olo order webhook
Deduplicated correctly
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.
Reconciles with the source
Actually broken
The fbc and fbp values missing on most records
Olo's ordering experience is frequently hosted on an Olo subdomain, and marketplace orders arrive through an API with no browser session behind them whatsoever.
Sent from the browser
Rails is designed to make marketplace demand look like your own order flow, which is excellent for operations and ruinous for measurement. Left unsplit, a good week on DoorDash reads as a good week for your ad account.
Counted twice, or not at all
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
Nobody has reconciled it
Olo → Meta · diagnose
Diagnostic order — Olo → Meta
- 01
Count orders carrying the fbc and fbp values
- 02
Follow one real conversion end to end
- 03
Separate direct from Rails at the source
Do this before any tracking work. The split is the measurement; everything after it is plumbing.
- 04
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.
- 05
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.
Olo → Meta · prove
How it gets proven — Olo → Meta
Source of truth
Olo orders by location and by channel, with direct and Rails-sourced marketplace orders held apart.
- The fbc and fbp values confirmed present on a live order.
- Deduplication confirmed in Events Manager on a real purchase, with the browser and server events visibly paired rather than counted twice.
- Direct-channel orders per location reconciled against imported conversions, with Rails volume reported as a named exclusion.
Olo → Meta · free audit
What we check in the free audit
- Count orders carrying the fbc and fbp values
- Follow one real conversion end to end
- Separate direct from Rails at the source
- Read Event Match Quality and the deduplication indicator
- Read the match rate, not the success message
Checked against
Olo orders by location and by channel, with direct and Rails-sourced marketplace orders held apart.
Free30 minutesNo obligation
Olo → Meta · when not to buy
When you don't need this — Olo → Meta
- Measure identifier coverage yourself first — pull your last hundred orders and count how many carry the fbc and fbp values.
- If your Olo volume is overwhelmingly Rails, the campaign question is about marketplace placement and commission, and no amount of conversion tracking will answer it.
- 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.
Olo → Meta · what we deliver
What gets built — Olo → Meta
Identifier capture into Olo
Persist the identifier on the direct-ordering path only, and mark Rails-sourced orders explicitly as unattributable rather than letting them dilute the figure.
Event source: the Olo order webhook
Send per-location. A brand with two hundred restaurants running one national campaign learns nothing from a single national conversion number.
Dispatch to Meta
Server-side events to the Conversions API with the event_id matched to the pixel, action_source set correctly, and customer data hashed before it leaves your infrastructure.
Reversals where they exist
Cancelled and refunded orders should reduce the figure, per location.
Written guarantee
95%+ tracking accuracy
Measured against Olo orders by location and by channel, with direct and Rails-sourced marketplace orders held apart.. Miss it and we keep working at no cost.
From $400 · See packages
FAQ
Olo → Meta questions, answered
No. Filter them out by channel before sending. They are marketplace demand with no Meta click behind them, and hashed customer data would still get them matched.
Include the Olo location identifier as a custom_data parameter on each Purchase, then build custom conversions or reports from it.
Almost always because the fbc and fbp values never reached the Olo order. Olo's ordering experience is frequently hosted on an Olo subdomain, and marketplace orders arrive through an API with no browser session behind them whatsoever. Measure coverage before debugging the dispatch.
Two things. The _fbc cookie, derived from the fbclid parameter on the landing URL in the format fb.1.<timestamp>.<fbclid>, is the click identifier. The _fbp cookie is the browser identifier. Beyond those, Meta matches on hashed customer information — email, phone, name, city, country — and every additional field raises the Event Match Quality score. Unlike Google, Meta does not need a click ID at all if the customer data is good, but match quality drops noticeably without it.
The Olo order webhook. Send per-location. A brand with two hundred restaurants running one national campaign learns nothing from a single national conversion number.
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.
More on Olo → Meta
- Stripe → MetaConnecting Stripe to Meta Conversions API
- Toast → MetaConnecting Toast to Meta Conversions API
- ChowNow → MetaConnecting ChowNow to Meta Conversions API
RELATED GUIDES
Where Olo → Meta fits in the rest of your tracking
- Meta · CateringMeta Ads conversion tracking for catering companies
- Meta · RestaurantsMeta Ads conversion tracking for restaurants
- Meta × POS SystemHow to reconcile Meta Ads against your point-of-sale system
- Meta · Reactivation → repeat purchaseHow to track lapsed customer reactivation to repeat purchase for Meta Ads
- Square Online → MetaConnecting Square Online to Meta Conversions API
- Olo → Amazon AdsConnecting Olo to Amazon Ads
- RestaurantsConversion tracking for restaurants, across reservations, orders and calls
- Uber Eats → MetaConnecting Uber Eats to Meta Conversions API
WhatsApp