The Hole iOS 14.5 Punched in Your Funnel
Until 2021 the Facebook Pixel was reliable: a snippet of JavaScript on your checkout page fired a Purchase event, Meta saw it, and your ad reports showed an honest cost per acquisition. Then Apple shipped App Tracking Transparency, iOS users opted out by default, and the browser pixel stopped firing for a large chunk of your real customers. The same thing happens with Brave, Safari ITP, uBlock Origin, and corporate ad-blockers — the pixel JS never executes, so the conversion is invisible to Meta.
The result: Meta's optimisation algorithm trains on a biased sample. It thinks your ads are converting worse than they actually are, bids more conservatively, and your real CPA climbs. For most delivery chains the gap between observed and actual conversions is 20–40%. That's the size of the budget Meta is misallocating because it doesn't know what's really happening.
The Fix: Send the Event Twice
Meta's official answer is the Conversions API (CAPI). Instead of relying only on the browser pixel, you also send the same event from your server, server-to-server, where no ad-blocker can interfere. Toster now does this for every order automatically — no integration work on your side.
The interesting engineering challenge is deduplication. If both the browser pixel and the server CAPI fire a Purchase event for the same order, Meta would count it twice and your ROAS reports would look amazing for the wrong reason. The trick is to attach the same event_id to both versions of the event. Meta matches them by event_id + event_name within a 7-day window and keeps only one. We use the order ID as the event_id, so dedup is deterministic.
What Toster Captures (and Why It Matters for Match Quality)
Meta scores every server event on "match quality" — how many user identifiers you sent so Meta can match the event back to a Facebook account. More identifiers = better match = better optimisation. Toster captures and forwards every one of these on every order:
- _fbp cookie — first-party browser ID set by the pixel itself
- _fbc cookie — fbclid from the ad click, persisted for 90 days
- Hashed customer email and phone (SHA-256, never raw)
- Client IP and User-Agent from the original session
- First-touch and last-touch UTMs stored 30 days in the browser
Together these typically push match quality from "Fair" (1–2 identifiers) to "Great" (5+). Meta gives a measurable optimisation boost above the "Good" threshold — chains that move from Fair to Great typically see CPA drop another 8–15% even before recovering the iOS 14.5 events.
First-Touch + Last-Touch Attribution, Not Just Last-Click
Every Toster session captures attribution twice: first-touch (the very first UTM that brought the visitor, sticky for 30 days) and last-touch (the most recent UTM that brought them back). Both are attached to every order. This matters because food delivery is rarely a single-session purchase — a customer sees an Instagram ad on Monday, comes back via Google on Friday, and orders. Last-click attribution credits Google. First-touch credits Instagram. The truth is they both contributed and a real marketer wants to see both.
The data lives in two columns on each order — attr_first_source, attr_first_campaign, … and attr_last_source, attr_last_campaign, … — plus click IDs (gclid, fbclid, ttclid, msclkid, yclid) for matching against ad platforms' own reports.
What This Looks Like in Practice
The customer scans a QR code from a flyer (utm_source=flyer&utm_campaign=spring). 12 days later they click a Meta retargeting ad (fbclid=…) and order. The order record now contains:
- First touch: flyer / spring
- Last touch: Meta retargeting
- fbclid + _fbp + _fbc all captured
- Server-side Purchase event sent to Meta with event_id = order ID, hashed PII, full UTM payload
A few seconds later Meta CAPI confirms receipt. The browser pixel, if it fired, used the same event_id — Meta sees both and dedupes. The conversion appears in Ads Manager with full attribution within minutes.
Beyond Meta: GA4 and TikTok
The same eventID mechanism works for Google Analytics 4 (Measurement Protocol) and TikTok Events API. Toster's pixel bridge initialises all three SDKs on the storefront and fires one set of standard events — view_content, add_to_cart, initiate_checkout, purchase — with a shared event ID. Each platform receives the client-side version from the browser and a server-side mirror from our backend, and dedupes against the same ID. You configure one pixel ID per network in Settings, and the same conversion is reported correctly across all three.
What You Should Do Now
- Add your Meta Pixel ID in Settings → Marketing → Pixels. Toster will start firing both client-side and server-side events on the next order.
- Generate a CAPI access token in Meta Events Manager, paste it next to the Pixel ID. The server-side leg starts within minutes.
- Verify in Events Manager → Test Events. You should see "Server" events appearing within seconds of a test order, and "Browser" events appearing with the same event ID being deduplicated.
- Wait 7 days, then compare CPA in Ads Manager before/after. The gap you'll see is the part of your funnel that was invisible until now.
The Quiet Compliance Win
Server-side tracking has a side benefit most operators don't realise: it's much easier to make GDPR-compliant. The pixel JS in the browser captures whatever's there, including PII you may not have wanted to send. Server-side, you decide exactly what to send and you hash everything personal before it leaves your network. Toster never sends raw email or phone to ad platforms — only SHA-256 hashes, which Meta and Google can match against their own hashed records without ever seeing the underlying values.
If your DPA includes ad platforms, the server-side path is the one your privacy officer will sign off on.