Facebook Ads Manager shows 47 purchases. WooCommerce shows 23 orders. That gap is not just attribution modeling—it’s your pixel and Conversions API counting the same purchase twice. Meta deduplicates events by matching event_id between browser and server, but most WooCommerce plugin setups generate mismatched IDs that Facebook cannot reconcile. The result: inflated conversions, corrupted optimization, and ad spend chasing audiences that already bought.
Here’s exactly how to check whether your store has this problem—and the architectural reason it keeps happening.
Why Facebook Shows More Conversions Than WooCommerce
Meta’s deduplication system is straightforward in theory. When you run both a browser pixel and Conversions API, Meta receives two signals for every conversion. It uses two fields—event_name and event_id—to determine whether those signals represent one purchase or two (Meta Conversions API documentation, 2025).
If the event_id values match, Meta merges them into one conversion. If they don’t match, Meta counts them as two separate purchases.
The problem? Running multiple plugins that each inject their own Meta pixel alongside a separate CAPI tool creates duplicate events with different event_id values—the most common cause of inflated Facebook conversions (SweetCode, 2026). Your pixel generates one ID format. Your CAPI plugin generates another. Meta sees two unrelated Purchase events and counts both.
You may be interested in: Pixel Manager vs PixelYourSite vs Conversios
The Three Ways WooCommerce Setups Break Deduplication
1. Mismatched Plugin event_id Formats
Each WooCommerce tracking plugin generates event_id differently. PixelYourSite might use a timestamp-based hash. Pixel Manager might use the WooCommerce order number. A GTM-based CAPI setup might generate a UUID. When your pixel comes from one system and your CAPI comes from another, the IDs never match.
68% of multi-touch attribution models over-credited digital channels in 2025 (MarTech Series)—and duplicate event counting is a primary driver of that inflation.
2. Pixel Fires on Page Load, Not Payment Confirmation
The Facebook browser pixel fires when a customer reaches the order confirmation page. But reaching the page doesn’t guarantee payment succeeded. If payment fails after the page loads, the pixel has already sent a Purchase event that WooCommerce will never count as an order (SweetCode, 2026).
CAPI, when properly implemented, fires only after confirmed payment. So you get a pixel Purchase event for a failed order, plus a CAPI Purchase event for a different successful order—and Facebook now has two conversions that look real but represent completely different transactions.
3. Multiple Pixel Injections
This one’s subtle. Some WooCommerce stores run a tracking plugin that injects the Meta pixel, then separately add the Meta pixel through their theme header, then have a CAPI tool running on top. That’s three potential event sources for one conversion. Even if deduplication works between pixel and CAPI, the extra pixel injection creates an event that has no CAPI counterpart to match against.
You may be interested in: The Marketing Pixel Death Spiral
How to Check Your Deduplication Status Right Now
You don’t need to guess whether your store has this problem. Meta Events Manager shows you exactly what’s happening.
Step 1: Open Meta Events Manager and select your pixel.
Step 2: Click the “Test Events” tab and enter your website URL.
Step 3: Open your store in a new tab and complete a test purchase.
Step 4: Return to Events Manager and look at the test events that arrived.
What you’re looking for: a single Purchase event, or two Purchase events with the same event_id. What signals a problem: two Purchase events with different event_id values, or two Purchase events where one shows “Browser” as the source and the other shows “Server” with no dedup indicator.
If you see two Purchase events from one order with different event_id values, your deduplication is broken. Every real customer purchase is being counted twice.
Why Plugin-Based Fixes Don’t Solve the Root Problem
Some plugins claim built-in deduplication. Pixel Manager, for example, claims to recover up to 30% more conversions via server-side tracking for Meta CAPI (Pixel Manager WordPress.org listing, 2026). But that recovery only works when deduplication is properly configured—and “properly configured” means the same plugin controls both the browser pixel and the server event.
The moment you introduce a second tracking tool, a theme-injected pixel, or a GTM container handling one side of the equation, the ID-matching chain breaks. No single plugin can control what another plugin generates.
Here’s the architectural problem: browser pixels and server APIs are fundamentally different systems. One runs in the visitor’s browser—subject to ad blockers, page load timing, and JavaScript execution order. The other runs on a server—triggered by webhooks, API calls, or database events. Keeping these two independent systems synchronized on a per-event basis requires them to share a generation mechanism for event_id. Most WooCommerce plugin combinations don’t.
You may be interested in: The WordPress Hook Priority System Is Why Your Tracking Plugins Fight
The Single-Pipeline Alternative
The cleanest architectural solution to deduplication is eliminating it entirely. When a single server-side pipeline sends one verified event per conversion directly to Meta’s Conversions API—without a browser pixel running simultaneously—there’s nothing to deduplicate. One event in, one conversion counted.
Transmute Engine™ takes this approach. It’s a dedicated Node.js server running first-party on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures WooCommerce purchase events and sends them via API to the Transmute Engine server, which validates the order, formats the event to Meta’s CAPI specification, hashes PII with SHA256 per Meta’s requirements, and delivers it—all from your own domain. No browser pixel. No event_id matching problem. No duplicate conversions.
When there’s only one system sending one event per conversion, the deduplication problem cannot exist.
Key Takeaways
- Meta deduplicates by matching
event_idbetween pixel and CAPI—mismatched IDs from different plugins cause every purchase to count twice - Browser pixels fire on page load, not payment confirmation—failed payments can register as conversions that inflate your numbers
- Multiple pixel injections compound the problem—theme headers, plugins, and GTM can each fire separate unmatched events
- Use Meta Events Manager Test Events to diagnose—complete a test purchase and check whether you see one event or two with different IDs
- A single server-side pipeline eliminates deduplication entirely—one event per conversion means nothing to match, nothing to inflate
Meta matches two fields—event_name and event_id—to identify duplicate events. When a browser pixel fires a Purchase event and CAPI sends the same Purchase event, Meta checks if both share the same event_id. If they match, Meta merges them into one conversion. If the IDs differ, Meta counts them as two separate purchases.
Open Meta Events Manager, select your pixel, and use the Test Events tab. Complete a test purchase on your store, then check whether a single Purchase event appears or whether you see two separate events with different event_id values. If you see two events from the same purchase, your deduplication is broken.
Most WooCommerce tracking plugins generate their own event_id format. If you’re running one plugin for the browser pixel and a different tool for CAPI, their event_id values almost certainly won’t match. The only way to verify is to run a test event in Meta Events Manager and compare the IDs from both sources.
Three common causes: broken deduplication between pixel and CAPI (mismatched event_id values), the pixel firing on page load before payment is confirmed (counting failed payments), and multiple pixel injections from different sources (theme, plugin, GTM). Use Meta Events Manager Test Events to identify which issue affects your store.
Stop counting every purchase twice. See how Seresa’s single-pipeline approach eliminates duplicate conversions entirely.
