Your Meta ads finally see the order.
Browser Pixel and Conversions API, deduplicated, ATT-resilient, Match Quality in the 7-8 range out of the box. Built specifically for restaurant ordering flows.
- Every diner tap on a platform fires a custom PlatformClick event to both the browser Pixel and the Conversions API.
- The two events carry the same event_id, so Meta deduplicates and counts one conversion per click.
- iOS users post-ATT still resolve because the server event ships fbc, IP, UA, and (with consent) hashed PII directly from your domain.
iOS 14 broke restaurant ads. Link-click optimization is the bandaid Meta gave you.
Before Apple\'s App Tracking Transparency rolled out in 2021, the Meta Pixel was enough. A diner clicked your ad, the Pixel fired in their browser, Meta matched it to their Facebook profile, and your campaign learned which audience segments actually converted.
After ATT, two things broke. First, iOS users (roughly half of US smartphone traffic) stopped granting Meta the IDFA needed to match Pixel events back to their Facebook profile. Second, the browser-only Pixel became increasingly easy to block — Brave, DuckDuckGo, Safari\'s Intelligent Tracking Prevention, and every adblocker added on top all started stripping fbq calls.
Meta\'s recommended fix is the Conversions API — a server-to-server feed where your origin ships conversion events directly to Meta. CAPI events are not blockable by browser extensions, they include first-party IP + UA + hashed PII, and they survive ATT because they do not need the IDFA at all.
The catch: building CAPI yourself means standing up a server endpoint, generating UUIDs at click time, mirroring every browser Pixel call, hashing PII, handling rate limits, and monitoring Match Quality scores in Events Manager. That is two weeks of senior engineering work and forever-ongoing maintenance. DineRoute does the entire thing inside the smart link.
Browser + server fire together, deduplicated by event_id.
Three things happen the instant a diner taps DoorDash on your smart link.
Browser Pixel fires immediately
On every platform tap, we call fbq("trackCustom", "PlatformClick", payload, { eventID }) before the redirect resolves. The browser side captures the FBP/FBC cookies and current URL.
Server CAPI mirrors the event
A Cloudflare Worker simultaneously POSTs the same event to graph.facebook.com/v19.0/{pixel_id}/events with the identical event_id, hashed email/phone if available, IP, and user agent.
Meta dedupes by event_id
Both events land. Meta keeps one, discards the duplicate, and records the deduped match. Match Quality climbs because the server event has IP, UA, FBP, FBC, and (where consented) hashed PII.
{
"data": [{
"event_name": "PlatformClick",
"event_time": 1747836000,
"event_id": "c2c7e62a-9a4b-4f5a-b6f1-2b7e3a9a8c2d",
"event_source_url": "https://malai.dineroute.com/southlake",
"action_source": "website",
"user_data": {
"client_ip_address": "203.0.113.42",
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 ...)",
"fbp": "fb.1.1717545600000.123456789",
"fbc": "fb.1.1717545600000.IwAR0abc...",
"em": ["e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"]
},
"custom_data": {
"platform": "doordash",
"location": "southlake",
"currency": "USD"
}
}],
"test_event_code": "TEST12345"
}Match Quality: 7.6 / 10. Browser + Server-side. Last received: a few seconds ago.
What you do, once, when you wire up your Pixel.
DineRoute does the implementation. You do the credential-pasting.
Paste your Pixel ID
In settings, drop in your 15-digit Pixel ID (Meta Events Manager → Data Sources). We validate it against Meta's diagnostics endpoint before saving.
Generate a CAPI access token
Meta Events Manager → Settings → Conversions API → Generate Access Token. Token never leaves your DineRoute settings — we store it encrypted and only the relay reads it.
Map your conversion event
Pick which Meta event name to mirror — usually a custom event named PlatformClick, but you can map to a standard event like Lead or InitiateCheckout if your campaigns are already optimized around one.
Use Meta's Test Events tab to verify
Click your live link with ?utm_source=fb_test, watch the event appear in Test Events. Confirm both Browser and Server columns are populated for the same event_id.
Switch the campaign objective
In Ads Manager, change your campaign from Traffic to Sales (or Leads), and choose your new PlatformClick event as the optimization goal. Give it 7-14 days to learn.
Watch Match Quality climb
Days 1-3: 5.0+ as Meta backfills hashed identifiers. Days 4-7: 6.5-7.5. Day 7+: 7.5-8.5 steady state. Below 6.0 after a week means Test Events still has a duplicate or missing layer.
The same screen restaurant marketers screenshot to their agency.
In Meta Events Manager → Data Sources → your Pixel → Overview, every PlatformClick event shows up with two badges: Browser and Server-Side. Deduplication appears in the right rail as "Deduped: X events" — that number should match your platform-click count within 1-2%.
Match Quality, the score Meta gives you for how cleanly your events can be tied back to a person on Facebook, lives under the Diagnostics tab. New accounts start in the 4.0-5.0 range as Meta backfills identifiers. By the end of week 1, DineRoute customers typically hit 7.0+. By week 4, 8.0+ if hashed email/phone is flowing through.
The acceptance test that matters most is opening Test Events while you click your own live link from your phone. You should see the same event_id appear twice, once as Browser and once as Server-Side, deduplicated into a single counted conversion. That is the signal that the loop is closed.
Two paths to the same Match Quality score.
If your team has senior engineering hours to burn, you can absolutely build this. Most restaurants and agencies do not.
| Capability | DineRoute | Build it yourself |
|---|---|---|
| Browser Pixel fires | Auto on every platform tap | You install + maintain in GTM |
| Conversions API server endpoint | Cloudflare Worker we operate | You host + monitor |
| event_id deduplication | Automatic UUID per click | You generate, store, replay |
| FBP / FBC cookie handling | Auto + reconstructed from fbclid | GTM custom JS + cookie variable |
| Test Events validation | Built into onboarding | Manual QA |
| Match Quality (typical) | 7.0 – 8.5 | 4.0 – 6.0 |
| iOS ATT signal recovery | 30 – 45% recovered | Lost to Apple's privacy layer |
Ten questions a restaurant marketer or agency lead actually asks.
What Match Quality score will I see?
Our typical restaurant lands in the 7.0–8.0 range within 72 hours, scaling to ~8.5 once Meta has 1-2 weeks of consented hashed email/phone data flowing through. Below 6.0 means something is misconfigured — open Test Events and check that Server-Side is firing.
How do you avoid duplicate events on the browser + server?
Every fbq call and every CAPI call carries the same event_id (a UUIDv4 generated at the moment of the click). Meta deduplicates by (event_name, event_id) within 48 hours and keeps the higher-signal event — usually the server one because it includes IP + UA + hashed PII.
What about FBP and FBC cookies?
We read _fbp and _fbc from the browser, forward both to the CAPI payload as fbp and fbc parameters, and reconstruct fbc from fbclid in the URL when the cookie has not been set yet (first-touch attribution).
Can I build Custom Audiences from this?
Yes — once your PlatformClick custom event is firing, create a Custom Audience in Meta Events Manager filtered to PlatformClick in the last 30 / 90 / 180 days. You can also build by platform (people who tapped DoorDash vs Uber Eats).
What attribution windows do you recommend?
Restaurants do best with 7-day click + 1-day view at the default. Most diners convert within 30 minutes of the click, but some return to the smart link from a saved tab or browser history later in the week.
How do you handle deduplication failures?
If the browser event fails to fire (e.g. ad blocker), the server event still lands — that is exactly the point of CAPI. If the server event fails (rare, but Meta's API does have brief outages), we requeue with exponential backoff and a 5-minute SLO.
Will my signal strength drop with iOS users?
iOS users post-ATT lose granular browser-side attribution to Meta, but the CAPI server event still carries the click identifiers and IP. Restaurants on DineRoute typically recover 30-45% of iOS conversion signal that pure-Pixel setups lose.
Does Meta's Test Events tool show both layers?
Yes — Events Manager → Test Events → enter your test_event_code in the URL (?test_event_code=TEST123) and you will see both rows: one labeled Browser, one labeled Server-Side. Same event_id on both = deduplication working.
How does this work with iOS App Tracking Transparency (ATT)?
ATT only blocks the IDFA. It does not block CAPI, IP-based attribution, or fbc-from-fbclid reconstruction. Our setup is largely ATT-resilient by design — the server event does not need ATT consent because it is first-party data shipped from your domain.
Are you compliant with CCPA and GDPR?
Yes. We honor Limited Data Use flags (lduds + ldu in the CAPI payload), respect Do Not Track headers, and DineRoute is covered by a per-client Data Sharing Agreement at andersoncollaborative.com/data-sharing-agreement. PII is hashed (SHA-256) before it leaves your origin.
Match Quality 7+ in 72 hours.
Paste your Pixel ID, your CAPI token, fire a test click. The rest is automatic.
No credit card. 14-day trial. Cancel any time.