Your WooCommerce Pixel Is Counting the Same Conversion Twice

Facebook shows 120 conversions this month. WooCommerce shows 78 orders. The extra 42 conversions don’t exist—they’re the same 42 purchases counted twice. One count from your browser pixel. One count from your server-side CAPI. Both firing on the same order, with no mechanism to tell the platform they’re the same event.

This is the deduplication problem. It’s invisible until you compare your platform numbers to your actual order count, and it gets worse the better your tracking setup becomes.

Why Running Both Pixel and Server-Side Creates This Problem

Until recently, most WooCommerce stores ran tracking one way: a browser pixel that fired when the thank-you page loaded. Simple. One event per purchase.

Then ad blockers blocked 31.5% of those pixels (Statista, 2024). Safari ITP capped cookies at 7 days. Browser-only tracking began losing 40–70% of conversion accuracy (Tracklution, 2025). The industry response—endorsed by Meta, TikTok, Pinterest, and Google—was to add server-side CAPI alongside the browser pixel. Run both. Cover the gap.

The advice is correct. Running both does recover the lost conversions. But it creates a new problem: every purchase now fires two events, from two different origins, and platforms can’t tell them apart unless you tell them.

The mechanism that tells them apart is called event_id. Most WooCommerce setups don’t implement it. And most WooCommerce store owners don’t know their ROAS is built on phantom conversions.

You may be interested in: Running 5 Ad Pixels at Once? The Hidden Performance Tax on Your WooCommerce Store

What event_id Is and How Deduplication Works

event_id is a unique identifier you generate at the moment of a conversion and attach to both the browser pixel event and the server-side CAPI event for the same purchase.

When Meta receives two Purchase events with the same event_id within 24 hours, it counts them as one conversion. It uses the server-side event as the primary signal—more reliable, less susceptible to browser interference—and discards the browser event as a duplicate. One purchase. One conversion. Correct.

Without matching event_ids, Meta has no way to know the two events are the same purchase. Both get counted. Your reported conversions run higher than your actual orders. Your ROAS looks better than it is. Your bidding algorithm optimises toward a signal that’s 30–60% inflated.

Meta requires this explicitly. According to Meta for Developers (2025): a matching event_id between browser Pixel and CAPI events is required for deduplication—without it, both events are counted as separate conversions.

TikTok’s requirement is nearly identical. TikTok deduplication requires a matching event_id within a 48-hour window between Pixel and Events API events (TikTok Events API Documentation, 2025). The window is longer, but the mechanic is the same: match on ID or count twice.

Three Places Deduplication Breaks in WooCommerce Setups

Failure 1: No event_id Generated at All

The most common failure. A WooCommerce store installs a Facebook Pixel plugin and a separate CAPI plugin—or enables the server-side feature inside an existing plugin—without configuring event_id generation. Both plugins fire their own Purchase events independently, with no shared identifier. The platform receives two events with two different (or absent) IDs and counts both.

This is the default state for most dual-tracking WooCommerce setups because the plugin documentation covers installation, not deduplication mechanics.

Failure 2: event_ids Generated Independently and Diverging

Some setups do generate event_ids—but the browser plugin generates its own and the server plugin generates its own, using different logic or different timing. If the browser event fires with ID evt_abc123 and the server event fires with ID evt_xyz789 for the same purchase, Meta sees two different events and counts both. The IDs need to be identical, not just present.

This happens when the browser-side ID is generated from a JavaScript timestamp and the server-side ID is generated from a PHP timestamp with a different seed. Millisecond differences create different IDs. Both platforms count twice.

Failure 3: event_id Present But Outside the Deduplication Window

Meta’s deduplication window is 24 hours. TikTok’s is 48 hours. If the server-side event fires more than 24 hours after the browser event—due to a delayed batch processing setup, a retry queue that held the event, or a manual upload of offline conversions that included the same purchase—the window has closed. The ID matches, but deduplication no longer applies. Both are counted.

Batch processing setups are particularly vulnerable here. If your server-side events process in daily batches rather than in real-time, any browser event that fires on a purchase near midnight may have its server-side pair arrive outside the deduplication window.

You may be interested in: What Is Facebook Event Match Quality and Why Your WooCommerce Score Controls Your ROAS

What Correct Deduplication Actually Looks Like

The clean implementation has three steps:

Step 1: Generate one event_id per purchase, server-side, at the moment of conversion. The server is the authority. It generates the ID from the WooCommerce order ID plus a timestamp hash—deterministic, unique, reproducible. The same order always produces the same event_id, which means retries and replays don’t create new duplicates.

Step 2: Pass the event_id to the browser before the pixel fires. The server includes the event_id in the page response for the thank-you page. The browser pixel reads it from the dataLayer or a cookie and attaches it to the Purchase event it fires. Both events—browser and server—now carry the same ID.

Step 3: Send both events in real-time. The server-side event fires immediately on order processing. The browser event fires when the thank-you page loads—within seconds. Both events arrive at the platform within the deduplication window. The platform matches on event_id, keeps the server-side event, discards the browser duplicate.

When implemented this way, TikTok Pixel + Events API delivers 19% more captured events and 15% better CPA than Pixel alone (TikTok Official Documentation, 2025)—because you’re recovering the conversions ad blockers would have hidden, without inflating your counts. Pinterest documents the same pattern: Tag + CAPI captures 20–30% more conversions than Tag alone, with deduplication keeping the count accurate (Pinterest CAPI Documentation, 2025).

Why a Centralized Server Handles This Better

The deduplication problem is a coordination problem. The browser pixel and the server-side CAPI need to agree on a single event_id for each purchase, generated from the same source, at the same moment. When browser plugins and server plugins operate independently, coordination fails.

Transmute Engine™ is a first-party Node.js server running on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures WooCommerce purchase events and routes them via API to your Transmute Engine server, which generates one event_id per order—deterministic, based on order ID—and embeds it in the dataLayer output returned to the browser before the thank-you page renders. The browser pixel reads the event_id from the dataLayer and fires its Purchase event with that ID attached. Transmute Engine fires the server-side CAPI event for Meta, TikTok, Pinterest, and Google Ads simultaneously, all carrying the same event_id. Every platform receives a matched pair. Every platform deduplicates correctly. One purchase. One conversion. Across all platforms. Handled once, at the source.

Key Takeaways

• Dual-tracking without deduplication inflates conversions by 30–60%: Every purchase fires two events. Without matching event_ids, both are counted independently.
• event_id is the deduplication mechanism: Meta matches within 24 hours. TikTok within 48 hours. The ID must be identical on both the browser and server event.
• Three common failure points: No event_id generated, IDs generated independently and diverging, or events arriving outside the deduplication window.
• The performance gains from dual-tracking only materialise with correct deduplication: TikTok’s documented 19% more events and 15% CPA improvement assume deduplication is working.
• A centralized server coordinates both events from one source: One event_id, generated once, passed to both browser and server events simultaneously—no coordination failure possible.

Better tracking should produce better data—not more data that looks better. Deduplication is the difference between the two. seresa.io