Get a Free Profit Growth Plan
← Blog

Meta CAPI Setup Guide: Recovering Lost Conversions After iOS 18

iOS 18 made browser-side tracking even less reliable. Meta's Conversion API is how you give the algorithm the data it needs to find your best customers again.

· Boris · 4 min read

The problem CAPI solves

Since iOS 14, every release has tightened the screws on browser-side tracking. iOS 18 went further - tighter cookie lifetimes, more aggressive private relay routing, and stricter cross-site script restrictions. The result is that the Meta Pixel, on its own, now misses 25-45% of conversions for the average ecommerce brand.

The Conversion API (CAPI) is Meta’s official server-to-server solution. Instead of relying on a browser pixel, your server sends the event directly to Meta’s API, bypassing browser-level restrictions. Done correctly, it restores match quality, recovers attribution, and gives Meta’s algorithm the cleaner data it needs to scale your campaigns.

This guide walks through a complete CAPI implementation that works in 2026.

What CAPI actually does

Three things, in order of importance:

  1. Recovers events that the browser pixel never fired (ad blockers, tracking prevention, fast back-button users).
  2. Enriches events with first-party data (hashed email, phone, FBP, FBC, click ID, IP) that improves Meta’s matching.
  3. Deduplicates against the browser pixel so the same purchase is not counted twice.

The third one is critical. A bad CAPI setup that double-counts conversions is worse than no CAPI at all.

The implementation paths

You have three realistic options in 2026:

  • Shopify or WooCommerce native CAPI integration. Easiest, weakest. Sends basic events. Skips most enrichment. Use this only if you are under €10k/month spend.
  • GTM Server-Side (sGTM) with the Facebook tag template. Best balance of control and effort. Requires server container setup.
  • Managed service like TAGGRS or Stape. Fastest to live. Monthly cost. Less control.

For most brands spending €15k-€200k a month on Meta, sGTM or a managed service is the right answer. The native integrations leave too much match quality on the table.

The eight events to ship

Send all of these server-side, not just Purchase:

  1. PageView
  2. ViewContent (product page views with content IDs)
  3. AddToCart
  4. InitiateCheckout
  5. AddPaymentInfo
  6. Purchase (with order ID for deduplication)
  7. Lead (for lead-gen brands)
  8. CompleteRegistration (for accounts that capture signups)

Each event needs the user data block: hashed email, hashed phone, first name, last name, city, country, IP, user agent, FBP cookie, FBC cookie, and the original click ID when available.

Deduplication: the step everyone gets wrong

Meta deduplicates browser and server events by matching event_id and event_name within a 48-hour window. If your browser Purchase event has event_id: "ORDER-123" and your server Purchase event has event_id: "ORDER-123", Meta counts it once. Different IDs, counted twice.

Two non-negotiables:

  • Generate the event_id on the browser, pass it to your server, and send the same value from both sides.
  • Use the order ID (or a unique transaction ID) as the basis, not a timestamp.

Test this in Events Manager. The deduplication report shows your match rate. Anything under 90% means events are being counted twice somewhere.

Hashing user data correctly

Meta requires SHA-256 hashing for PII before it leaves your server. Common mistakes:

  • Trimming whitespace differently on the two sides.
  • Lowercasing on one side but not the other.
  • Hashing already-hashed data.
  • Sending hashed email but unhashed phone.

The reference implementation: lowercase, trim, remove formatting (no spaces in phone numbers, no dots in emails), then SHA-256. Apply this consistently to every PII field.

Setting up first-party cookies properly

Meta uses two cookies for matching: _fbp (browser ID) and _fbc (click ID from the fbclid URL parameter). The CAPI event must include the current value of both whenever they exist.

If you are using sGTM with a custom subdomain like metrics.yourbrand.com, set the cookies as first-party. They survive iOS 18’s tracking prevention much longer than third-party cookies set by Meta directly.

Measuring match quality

After launch, go to Events Manager > Data Sources > your pixel > Event Match Quality. You want:

  • Overall score: 7+ out of 10
  • Purchase score: 8+ out of 10
  • Customer Information Parameters: 6+ fields per event on average

Below those numbers, your CAPI setup is technically working but operationally underperforming. Usually the fix is sending more PII fields or hashing them correctly.

What changes after a clean CAPI setup

The brands we have rolled this out for see, on average:

  • 20-35% more conversions reported in Meta Ads Manager (real conversions that were happening but invisible).
  • 15-25% lower CPA on Advantage+ campaigns within 2-3 weeks as the algorithm relearns on cleaner data.
  • Higher match quality scores translating directly into better audience targeting.
  • ROAS numbers that finally line up with what the bookkeeping shows.

The campaigns do not magically improve. They just start being judged on data that reflects reality.

Start here

If you have not implemented CAPI yet, this is the highest-ROI technical project in your account right now. If you have implemented it but never audited match quality, that audit is the second-highest. iOS will keep tightening. The brands that own their measurement stack will keep widening the gap.