Your Facebook CAPI is probably missing 30-50% of your WooCommerce purchases. Even with server-side tracking properly configured, simplified plugin implementations, external payment redirects, and iOS privacy restrictions are causing conversions to vanish from your Meta Ads Manager.
The problem isn’t whether you have CAPI set up. It’s how it’s set up—and what happens to customer data before it reaches Meta’s servers.
Here’s what’s actually breaking your tracking and how to fix it.
Why CAPI Still Loses WooCommerce Purchases
Facebook Conversions API was supposed to solve the tracking apocalypse. Server-side data that bypasses ad blockers, cookie restrictions, and browser crashes. Meta’s own recommendation for every advertiser.
So why are purchases still disappearing?
Three tracking killers are working against you:
- External payment gateways break the data chain
- iOS privacy restrictions limit what Meta can see
- Plugin implementations are too basic to capture complete data
Let’s break down each one.
External Payment Redirects Kill Your Attribution
When a customer pays with PayPal, iDeal, Klarna, or any gateway that redirects off your site, the tracking chain breaks.
Here’s what happens:
- Customer clicks your Facebook ad (Meta stores the fbclid click ID)
- Customer browses your WooCommerce store
- Customer chooses PayPal at checkout
- Customer leaves your site to complete payment on PayPal
- Customer returns to your thank-you page
The problem? That return from PayPal often loses the Facebook click ID. The thank-you page fires the purchase event, but without the fbclid, Meta can’t connect the conversion back to your ad.
The Facebook for WooCommerce plugin has documented issues with external payment gateways. WordPress.org support forums show consistent complaints about CAPI events not tracking properly when LiteSpeed Cache is active or when customers use redirect-based payments.
Your WooCommerce order has all the data—customer email, phone, purchase value, products. But if your CAPI implementation only relies on thank-you page scripts, it never reaches Meta.
iOS 14+ Gutted Your Attribution Window
Apple’s App Tracking Transparency didn’t just affect mobile apps. It fundamentally changed how Meta tracks all conversions.
Before iOS 14.5:
- 28-day click attribution
- 7-day view attribution
- Real-time reporting
After iOS 14.5:
- 7-day click only (default)
- 1-day view
- Reporting delayed up to 72 hours
- Statistical modeling instead of actual data
Meta estimates roughly 15% underreporting in aggregated web conversions from iOS-optimized campaigns. But the real-world impact is often worse.
Only 5% of iOS users opt in to tracking. That means 95% of your Apple customers are invisible to traditional pixel tracking. CAPI can help recover some of this data—but only if it sends the right user identifiers.
Your Plugin Implementation Is Too Basic
Most WooCommerce CAPI plugins do the bare minimum. They fire events, but they don’t send enough data for Meta to actually match those events to users.
Event Match Quality (EMQ) is Meta’s scoring system for how well your event data matches their user database. It’s based on identifiers like:
- Email (hashed)
- Phone number (hashed)
- First name, last name
- City, state, zip code
- Facebook click ID (fbc)
- Facebook browser ID (fbp)
- IP address
- User agent
The more identifiers you send, the higher your EMQ. Higher EMQ means better attribution.
Here’s the thing: logged-out visitors have almost no identifiers. The only data available is browser-based cookies (fbp, fbc), IP address, and user agent. If those cookies expire or get blocked, Meta has nothing to work with.
WooCommerce purchases should have great EMQ because order data includes email, phone, and address. But if your plugin only sends basic parameters, you’re leaving matching data on the table.
Cache Plugins Break Event Deduplication
CAPI works alongside the Facebook Pixel. Both track the same events. Meta uses event IDs to deduplicate—when it receives the same purchase from both pixel and CAPI, it only counts it once.
When deduplication fails, two things happen:
- Your conversions get double-counted (inflated metrics)
- OR your CAPI events get dropped entirely (missing conversions)
Cache plugins are notorious for breaking this. LiteSpeed Cache, WP Super Cache, and others can serve cached pages with stale event IDs. When five customers see the same cached thank-you page, they all send the same event ID. Meta sees this as duplicate spam and discards legitimate conversions.
The Facebook for WooCommerce plugin documentation specifically warns about cache-related issues. Their recommendation? Exclude conversion pages from caching. But that’s a band-aid, not a solution.
What’s Actually Required to Track All Purchases
Fixing Facebook CAPI for WooCommerce requires addressing each failure point:
1. Capture purchase data at order completion, not page load
Your CAPI should fire when WooCommerce processes the order—not when the customer loads the thank-you page. This captures purchases regardless of payment gateway redirects, browser crashes, or page caching.
2. Send complete customer identifiers
Every purchase event should include:
- Hashed email from order data
- Hashed phone from order data
- First name, last name
- City, state, country, zip
- Order value and currency
- Product content IDs
3. Preserve Facebook click IDs through external payments
The fbclid and fbp values need to survive the payment redirect. Store them in the WooCommerce session before checkout, then retrieve them when the order completes.
4. Generate unique event IDs per transaction
Each order needs a unique event_id that matches between pixel and CAPI. Use the WooCommerce order ID—it’s guaranteed unique per transaction.
How Server-Side Tracking Solves This
The fundamental problem with plugin-based CAPI is that it still depends on browser events. It fires JavaScript on page load, which means:
- Cache can corrupt it
- Redirects can break it
- Browser crashes can kill it
- Ad blockers can stop the pixel half of deduplication
True server-side tracking captures data at the server level—when WooCommerce actually records the order. No browser required. No thank-you page dependencies. No cache issues.
This is how Transmute Engine™ approaches WooCommerce tracking. Rather than bolting server-side onto client-side, it captures events directly from WordPress when they happen. Purchase data goes to Meta from your server the moment WooCommerce marks the order complete.
External payment redirect? Doesn’t matter—the order data is already captured.
Browser crash after payment? Doesn’t matter—the purchase already fired.
Page cached for a thousand visitors? Doesn’t matter—each order triggers independently.
How to Check If Your CAPI Is Actually Working
Before fixing anything, diagnose the actual problem:
1. Check Meta Events Manager
Go to Events Manager > Data Sources > Your Pixel > Test Events. Browse your store and complete a test purchase. You should see:
- Server events labeled with the CAPI icon
- Browser events from the pixel
- Both events with matching event_id values
2. Compare Event Match Quality
In Events Manager > Overview, check the EMQ score for each event type. Purchase events should score higher than PageView because they have more customer data. If your Purchase EMQ is “Poor” or “OK,” you’re not sending enough identifiers.
3. Audit actual vs. reported purchases
Compare WooCommerce order counts to Meta Ads Manager conversions over 7 days. Significant gaps indicate tracking failures.
If you’re seeing 30%+ fewer conversions in Meta than actual orders, your CAPI isn’t capturing what it should.
Key Takeaways
- 30-50% of WooCommerce purchases go unreported even with Facebook CAPI due to external payment redirects, iOS restrictions, and basic plugin implementations
- External payment gateways like PayPal lose the Facebook click ID when customers redirect off your site to complete payment
- iOS 14.5 ATT cut attribution windows from 28 days to 7 days and only 5% of Apple users opt in to tracking
- Event Match Quality determines whether Meta can attribute purchases—send hashed email, phone, and address with every conversion
- Cache plugins break event deduplication by serving identical event IDs to multiple customers
- True server-side tracking fires at order completion, not page load, capturing purchases regardless of browser state or payment flow
Facebook’s attribution window, external payment redirects, and Event Match Quality all cause gaps between actual sales and reported conversions. If your CAPI implementation only fires on thank-you page loads, you’re missing purchases from customers who used redirect-based payments or had browser issues.
Yes. Meta recommends using both together. The pixel captures browser-side data like demographic information and browsing behavior. CAPI provides reliable server-side conversion data. They work together through deduplication using matching event IDs.
Send more customer identifiers with each event. For purchases, include hashed email, phone number, first name, last name, city, state, zip code, and country from the WooCommerce order. Higher EMQ means Meta can better match conversions to users who saw your ads.
Only if your implementation captures the Facebook click ID before the customer leaves your site and associates it with the order when payment completes. Basic thank-you page scripts lose this data during the redirect.
Cache plugins often serve the same page with identical event IDs to multiple customers. Disable caching on checkout and thank-you pages, or use a server-side tracking solution that generates event IDs based on unique order data.
Stop guessing which purchases Facebook can actually see. Transmute Engine captures WooCommerce conversions at the server level—before browser issues, payment redirects, or cache can break them.
