What to check in a CAPI implementation before shipping

You shipped server events. Stape container is live, Events Manager shows traffic.

That is not the same as having a working CAPI implementation. A container that sends events can still be double-counting purchases, blocking match quality from getting above 5, and missing 30 to 40 percent of iOS conversions entirely. The traffic light is green and the data is broken simultaneously.

If you want the short version of where most implementations go wrong first, the six most common CAPI misconfigurations covers the top failure modes. This checklist goes deeper: all 14 checks, the reasoning behind each, and what a failed check costs in dollars.

These are the 14 checks that separate "events are firing" from "events are trustworthy."

The CAPI pre-launch checklist

Tracking layer

1. Client-side pixel present on all 4 pages. Homepage, product page, cart, and thank-you. Modern Shopify stores inject via GTM or the web-pixels-manager sandbox, so check the GTM container bundle if fbq( is absent from page source. A pixel missing on the thank-you page means zero purchase visibility on the browser side.

2. Server-side CAPI sending Purchase events within 24 hours. A container that exists but isn't receiving recent events is a container that broke at some point after launch. Pull the Stape logs or Events Manager event activity before you walk away.

3. event_id deduplication rate between 85 and 95 percent. Below 85 means double-counting. Above 95 means your server events are getting rejected because they look too similar to what the pixel already sent. Both fail. Check the Deduplication tab in Events Manager.

4. PII fields hashed before send. Email, phone, fbp, and fbc should all be SHA-256 hashed in the server container before they leave your infrastructure. Raw PII being sent to Meta creates GDPR exposure and causes event rejection.

5. Server-only events representing 20 to 35 percent of total iOS purchases. If that number is below 15 percent, your server-side implementation is not recovering what the iOS browser can't send. If it's 0 percent, CAPI is redundant, not a backstop.

Data quality

6. Match quality score above 8.5. Below 6.5, Meta's optimizer has poor signal and starts compensating with CPM increases. A score I brought from 4.2 to 9.1 on a DTC Shopify store corresponded to roughly 35 percent more conversions becoming visible to the algorithm. That is the ceiling this number sets.

7. All 9 standard events firing (or all relevant to your model). ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Search, Lead, CompleteRegistration, Subscribe. A missing Purchase event is a hard fail. Missing upper-funnel events means the algorithm has no signal for prospecting.

8. Advanced matching sending at least 5 parameters per event. em, ph, fn, ln, ct, st, zp, country, external_id. Below 2 parameters per event, match quality cannot get above 7 regardless of what else you do. external_id (hashed Shopify customer ID) is the single highest-leverage parameter if you're only going to add one.

Shopify integration

9. Checkout extensibility active, Purchase event fires server-side on thank-you. Shopify deprecated checkout.liquid in August 2024. Stores still on the old checkout template are missing events from a page that Shopify controls and that you can't instrument the normal way. Verify which checkout is running before you assume the thank-you page is covered.

10. Order value in Meta matches Shopify order data. Tax and shipping inflation is the most common mismatch I find. Shopify's total_price includes shipping; if your dataLayer is sending that field, Meta's reported purchase value is higher than actual revenue. Check your GTM variable against the order object fields.

11. Refund events configured. Not critical to conversion tracking, but a missing refund webhook means ROAS reporting is inflated by the gross figure. A WARN on this check, not a FAIL, but worth knowing before you optimize spend based on that number.

Consent and compliance

12. Consent Mode v2 configured for EU/UK traffic. All four signals need to be set: ad_storage, analytics_storage, ad_user_data, ad_personalization. Consent Mode v1 only is a WARN. No consent mode at all for a store serving EU/UK is a hard fail with GDPR fine exposure up to 4 percent of global revenue.

13. Single tag source per event (no double-fire conflicts). If Klaviyo, Triple Whale, or Northbeam is in your stack, check whether they have their own Meta pixel or CAPI tags firing alongside yours. Each of these platforms can trigger a secondary Purchase event that inflates your conversion count and destroys match quality in the process.

Attribution reconciliation

14. 30-day Shopify revenue vs. 30-day Meta-attributed revenue delta below 15 percent. This is the final sanity check. A delta above 30 percent means the tracking layer is fundamentally broken and Meta's algorithm is optimizing against numbers that don't reflect what's actually happening in the store. A delta of 15 to 30 percent warrants investigation. Below 15 is healthy for most DTC operations.

Why deduplication is the first thing to verify

The event_id has to be identical between the browser pixel event and the server CAPI event for the same user action. That means the GTM web container generates a unique ID when a purchase fires, that ID gets pushed to the dataLayer, and the server container reads that exact value and sends it alongside the server event.

When this breaks, both events reach Meta independently. Meta sees two Purchase events with different IDs and counts them both. Your conversion numbers look excellent for about 48 hours. Then Meta's backend deduplication runs, strips the duplicates, and your ROAS drops 30 to 40 percent at once. The advertiser panics, thinks the ads stopped working, and makes the wrong call.

The mechanism that causes this is almost always one of three things: the web container generates the event_id but doesn't pass it to a dataLayer variable the server container reads; the server container uses a different variable name; or the ID format differs between sides (one sends a UUID, the other sends a timestamp string). All three are fixable in GTM in under an hour if you know what to look for.

A dedup rate above 95 percent is also worth investigating. It usually means the server events and browser events are so similar that Meta is rejecting the server events as near-duplicates, which defeats the purpose of having server-side tracking for iOS recovery.

What your match quality score is actually telling you

The three parameters that move the score fastest are external_id (hashed Shopify customer ID), em (hashed email), and fbc (Meta click ID stored as a first-party cookie). Most stores send email on the Purchase event only. Getting em and external_id onto ViewContent, AddToCart, and InitiateCheckout too is the fastest path from a 5 to a 7.

fbc requires a custom loader domain for first-party cookie persistence. Without it, Safari ITP wipes the click ID after 7 days, and any purchase that happens more than a week after the click arrives at Meta without the attribution chain intact.

The Shopify-specific failure modes

Shopify's deprecation of checkout.liquid in August 2024 affected every store that had customized the checkout template. The replacement, checkout extensibility, has its own web pixel installation process and its own server-side event configuration. If a store migrated to the new checkout without updating the tracking setup, the thank-you page is firing purchase events through an entirely different mechanism than the one the server container was built around.

The tell is simple: pull the Events Manager real-time view, complete a test purchase, and watch whether the Purchase event shows both browser and server sources. If only browser fires, the server container isn't catching the thank-you page.

The other common Shopify mismatch involves what gets sent as the purchase value. Shopify exposes several order total fields. The one that includes shipping and tax is the total_price field. The one that reflects actual product revenue is subtotal_price. If the server container reads total_price and the brand measures performance against product revenue, the reported ROAS in Meta reflects a number that doesn't exist in the P&L. A $100 order with $12 shipping shows up as a $112 purchase, and optimized campaigns are chasing that inflated signal.

Consent and third-party conflicts

Consent Mode v2 is not optional for stores that serve European Union or UK traffic. The GDPR angle is one part of it. The other is that Meta stopped serving ads to EU users from accounts without Consent Mode properly configured, which means any tracking you have is useless if the ads aren't running.

The v2 configuration requires four signals in a specific initialization sequence before any tags fire. A common error is setting them after the GTM container loads rather than in the dataLayer push that precedes the container. The order matters because tags can fire before the consent signal arrives if the container initializes first.

Third-party tool conflicts are the category that surprises people most. Klaviyo's Attribution Tracking feature, Triple Whale's Pixel, and Northbeam's tag can each fire a separate Purchase event to the Meta pixel. On a store where all three are installed and the main pixel is also running, it's possible for one real purchase to generate four or five separate Purchase events in Events Manager. Match quality collapses, event counts look unrealistically high, and the optimizer gets confused. The fix is auditing every tag in the GTM container for any Meta event it fires and ensuring only one source per event reaches Meta.

What a failed check actually costs

The revenue impact varies by check, but three failure modes dominate in practice.

A Check 3 failure (no deduplication) means every conversion is double-counted. Meta's optimizer allocates budget toward what looks like high-performing placements, then the backend dedup corrects the numbers, and you're left with spend decisions made against fiction. The recovery after fixing dedup usually looks like a short performance dip as the algorithm recalibrates.

A Check 6 failure (match quality below 6.5) compounds over time. The CPM increase is real and measurable. At $30K/month in Meta spend, even a 20 percent CPM increase is $6,000/month in additional cost for the same reach. Over a quarter, that's $18,000 that could have gone toward a check that takes an afternoon to fix.

A Check 14 failure (revenue delta above 30 percent) is usually a symptom of multiple upstream failures rather than a standalone problem. Fix Check 2, Check 3, and Check 6, and the delta typically narrows. If it doesn't, there's a dataLayer misconfiguration somewhere that's systematically under-reporting or over-reporting purchase values.

The 14-check framework gives you a diagnostic before you go to production. Running it after you go to production means running it against live spend.

If the broader question is why agencies and tools often push server-side tracking as a set-and-forget solution rather than an ongoing verification problem, the services trap framing is relevant context - the incentive structure shapes what gets checked and what doesn't.

FAQ

If you want someone to run this entire checklist against your stack and document what they find, the CAPI Leak Report does exactly that. 14 checks, structured findings, and a prioritized fix list delivered within 72 hours.

The server-side tracking rebuild I did for a DTC Shopify store - building CAPI from scratch and taking match quality from 4.2 to 9.1 in 48 hours - is the grounding behind why these particular checks are in the list. That build is also the source of the revenue recovery ranges you see in the dollar-impact section above.

Sources and specifics

• Match quality improvement from 4.2 to 9.1 and 35 percent conversion recovery figure: from a production CAPI implementation at a DTC Shopify store, Q2 2024, 48-hour build.
• CPM increase of 20 to 40 percent for match quality below 6.5: documented in Meta Ads Manager benchmark data and corroborated across multiple audits.
• Revenue delta PASS threshold (below 15 percent): observed across DTC Shopify stores with healthy CAPI implementations; varies by AOV and ad attribution window.
• Shopify checkout.liquid deprecation: August 2024 (Shopify official deprecation notice).
• iOS/ATT server-only event range (20 to 35 percent of iOS purchases): consistent with published iOS 14.5+ impact data and observed in production server container logs.
• Consent Mode v2 signals (ad_storage, analytics_storage, ad_user_data, ad_personalization): Google/Meta Consent Mode v2 specification, effective March 2024.