Conversions API setup: the practical 2026 guide

If you run paid Meta or Google ads in 2026 without server-side conversion tracking, you're flying blind on roughly 20-30% of your conversions. Apple's ATT framework and the broader privacy-protection wave have made browser-based pixel tracking unreliable for iOS users, and that's a substantial share of US traffic. Conversions API (CAPI) on Meta and Enhanced Conversions on Google are the server-side workarounds that recover most of what's lost.

The catch: setting them up wrong is worse than not setting them up at all. Duplicate events, mismatched user data, and stale signal can hurt account performance rather than help it. We've inherited dozens of accounts with broken CAPI implementations that the previous agency claimed were "working." This guide is the order we set things up, the gotchas we've hit, and the way to verify each layer before moving on. It's the supporting reference for the broader paid advertising pillar.

What CAPI and Enhanced Conversions actually do

Browser-side pixels (the Meta Pixel, the Google Ads tag) work by firing a JavaScript event from the user's browser when they convert. The browser sends that event back to Meta or Google. This was the standard for a decade. It started breaking in 2021 when iOS 14.5 introduced ATT.

The problem in 2026: roughly 65-75% of iOS users opt out of cross-app tracking. When that happens, the browser pixel can fire but Meta or Google receive degraded user data — enough to count the event, but not enough to deterministically attribute it back to the ad click that drove it. Cookie blockers, ad blockers, and the gradual deprecation of third-party cookies on Chrome have compounded the problem on desktop and Android too.

Server-side tracking solves this by routing the conversion event from your server (not the user's browser) directly to Meta's or Google's API. Your server has full, accurate user data — email, phone, IP, user agent, click ID — and isn't subject to browser-level privacy restrictions. Meta and Google receive better signal, which translates to better attribution, better algorithm learning, and better optimized delivery.

In practice, our accounts running both browser pixel and CAPI recover 18-28% more attributed conversions than browser-only accounts. The exact number depends on your traffic mix (iOS-heavy ecommerce recovers more; B2B desktop-heavy recovers less). It's the single highest-ROI technical implementation in paid advertising in 2026.

The setup order — and why it matters

A working server-side tracking stack has four components that need to be installed in the right order. Skip ahead and you'll waste time debugging issues caused by an earlier missing layer.

1. Browser pixel (Meta) and Google Ads tag (Google), still required. Server-side doesn't replace browser-side; it complements it. Meta uses event deduplication — when both pixel and CAPI fire for the same event with the same event ID, Meta keeps one and discards the duplicate. Without the browser pixel, you lose the events from users with good signal (the ones who didn't opt out of ATT).

2. Server-side event handler. This is the code that runs on your server when a conversion happens and sends the event to Meta/Google. Three viable paths:

• Stape.io or similar managed service — easiest, $20-50/mo, handles all the boilerplate. Right for most accounts.
• CAPI Gateway — Meta's own server-side relay. Free, more involved setup, requires a Cloudflare Worker or your own server.
• Direct implementation — write the API calls yourself in your backend. Most control, most engineering effort.

3. Event matching parameters (hashed user data). When you send a server-side event, you need to include hashed identifiers — email, phone, name, IP, user agent, Facebook click ID (fbc), Facebook browser ID (fbp). These are what Meta uses to match the event back to the user who clicked the ad. The more identifiers you can send, the better the match rate. Hashing must use SHA-256 — Meta and Google both require it.

4. Event Match Quality monitoring. Meta provides an Event Match Quality (EMQ) score 0-10 in Events Manager. Below 6.0 means the matching is weak and CAPI isn't recovering as much as it could. Above 8.0 is excellent. Most accounts we audit when we inherit them are at 4-6; we typically get them to 8+ inside the first month.

Meta CAPI — concrete setup with Stape

Stape is our default for small-to-mid clients because the setup is fastest. Here's the exact sequence:

Step 1. Sign up for Stape, create a "container" for your domain.

Step 2. In your Stape container, add the "Facebook Conversion API" tag. Connect it to your Meta Pixel (you'll need the pixel ID and the CAPI access token from Events Manager → your pixel → Settings → Conversions API).

Step 3. Configure server-side event triggers. The events you care about: Purchase, Lead, CompleteRegistration, AddToCart, InitiateCheckout. The exact set depends on your funnel. Critical: every server-side event must have the same event_id as the matching browser-side event for Meta's deduplication to work.

Step 4. Set up event matching parameters. At minimum: em (hashed email), ph (hashed phone — if you collect it), fn (hashed first name), ln (hashed last name), ct (hashed city — coarsely matched), country, ip (client IP), client_user_agent, fbc (Facebook click ID), fbp (Facebook browser ID).

Step 5. Test in Meta Events Manager → Test Events. Send a test conversion through both the pixel and CAPI. You should see two events in the test events feed with the same event_id, and Meta should report "deduplicated" on one of them. If they appear as separate events, your event_id matching is broken — fix this before deploying.

Step 6. Deploy to production. Watch Event Match Quality for the first 7 days. If it's not climbing toward 7+, you have a hashing or parameter issue.

That's the full setup for a typical implementation. About 4-6 hours of engineering work for a developer who hasn't done it before; 1-2 hours for someone who has.

The most common CAPI mistakes we see

We've audited dozens of CAPI implementations. The top failure modes:

Sending events without event_id. Without it, Meta can't deduplicate. You end up double-counting conversions, which inflates your platform-reported ROAS until Meta's own data hygiene catches up. The pattern looks great for 2-3 weeks and then collapses when Meta cleans the data.

Hashing inconsistently. Hashing the email but not lowercasing it first means "Scott@example.com" and "scott@example.com" produce different hashes. Meta's matching can't tie them together. The fix: always .toLowerCase().trim() before SHA-256 hashing email and phone.

Sending plaintext PII. Sending em: "scott@example.com" instead of em: "<sha256 hash>" is a violation of Meta's terms and a privacy issue. The Meta CAPI library handles hashing automatically in most cases, but custom implementations need to do it manually.

Missing fbc and fbp cookies. These are the Facebook-set cookies that contain the click ID and browser ID. Meta uses them as primary matching identifiers — they're typically the strongest signal in the stack. If your server-side handler doesn't have access to these cookies (because the conversion happens server-side at a moment when the cookies aren't available), match quality drops. The fix: capture these cookies at the moment of conversion submission and persist them in your form data or session.

Sending events for non-conversion users. Some accounts ship server-side events for every page view, not just conversion events. This produces noisy data that confuses Meta's optimization. Keep server-side events lean — only the conversion-relevant ones.

Google Enhanced Conversions

Google's equivalent is Enhanced Conversions. Conceptually identical: hashed user data sent server-side to recover conversions lost to privacy restrictions. Implementation is slightly different.

Path A — Enhanced Conversions for the web (via gtag). The Google Ads tag captures user data from your conversion form and hashes it client-side before sending. Easiest implementation; works for most accounts.

Path B — Enhanced Conversions for leads. Used when conversions happen offline (a phone call, a CRM-tracked deal closure). You upload conversion data via Google Ads UI or API after the conversion happens. Critical for B2B and service businesses with long sales cycles.

Path C — Google's API for Server-Side Conversion Tracking. True server-side equivalent of Meta CAPI. Less commonly used because Enhanced Conversions via gtag is sufficient for most cases.

The setup pattern for Path A:

1. Enable Enhanced Conversions in Google Ads → Tools → Conversions → [your conversion] → Enhanced Conversions section
2. Choose "Google tag" as the method
3. Update your conversion event JavaScript to pass user data as parameters
4. Test using Google Tag Assistant
5. Wait 14 days; check the "Enhanced Conversions" status column in Google Ads to confirm it's reporting "Recording"

Most agencies stop at Path A. For B2B and service businesses with long sales cycles, Path B is just as important — uploading your closed-deal data back to Google Ads lets the platform optimize toward your actual revenue events, not just form fills.

Verifying it's actually working

After setup, the question is: how do we know it's working? Three checks:

Meta side:

• Event Match Quality score 7.0+ in Events Manager (typically reachable in 7-14 days post-setup)
• "Server" events visible alongside "Browser" events in the Events Manager events feed
• Deduplication rate above 25% (this means CAPI is catching events the browser missed)
• No "duplicate event" warnings in Diagnostics

Google side:

• Enhanced Conversions status "Recording" in conversions table
• Match rate above 50% in the Enhanced Conversions report
• No "missing user data" warnings

Account performance side:

• 14-21 days after CAPI go-live, you should see attributed conversions climb 15-30% with no change in actual conversion volume on the website. That's the recovered attribution showing up in the dashboard.
• Cost per attributed conversion typically drops by a similar margin, because the same spend is now credited with more conversions.
• Algorithm should optimize more efficiently within 4-6 weeks of better signal.

If the numbers don't move after 21 days, something is broken in the implementation. Most commonly: event_id mismatch causing deduplication to fail in a hidden way.

When to call in an engineer

CAPI is technical implementation work. The honest answer: if your marketing team includes someone who can write Node or Python and is comfortable with cookie handling and HTTP requests, they can set this up in a day. If not, you need an engineer for it.

We handle CAPI setup as a standard part of any paid Meta retainer above $10k/mo in spend. Below that, we recommend Stape.io and walk the client through the setup themselves — the management fee can't absorb a 4-6 hour engineering project.

If you're trying to set this up in-house and getting stuck, the resources we point clients to:

• Meta's CAPI documentation — the primary reference, dense but accurate
• Stape's setup guides — well-written, more practical than Meta's
• Meta's Event Match Quality reference — explains every parameter and how it affects match rate

What's next after CAPI is live

CAPI is the foundation. Once it's in place:

• Post-purchase survey. Best ground-truth attribution layer; covered in the paid advertising pillar.
• First-party data activation. Now that your matching is strong, you can build better audiences from your customer list and email subscribers.
• Marketing mix modeling. Once you have 6-12 months of reliable conversion data plus channel spend data, MMM becomes feasible for accounts above $30k/mo spend.

Each of these builds on the foundation. None of them work properly without CAPI underneath.

CAPI isn't optional for serious paid accounts in 2026. The accounts running without it are leaving 20-30% of attribution on the table — which translates to worse algorithm learning, suboptimal budget allocation, and conversion numbers that don't match reality. Set this up first, before any other paid optimization. Everything else compounds from accurate measurement.