As advertising platforms lean more heavily on first-party data for campaign optimization, Conversions API (CAPI) integrations have become essential. Triple Whale’s Sonar product simplifies this process by sending high-fidelity server-side events to platforms like Meta, Google Ads, TikTok, and others. But with power comes complexity—and that’s where event deduplication becomes critical.
In this article, we’ll break down standard deduplication mechanisms used across major platforms, the unique challenges Sonar faces—especially in standard Shopify setups—and why most merchants should consider a dual-pixel strategy for clean attribution.
Why Deduplication Matters for CAPI
Nearly all modern ad platforms—Meta, Google, TikTok, Pinterest, and Snap—support dual-ingestion of events via browser-side pixels and server-side APIs. This ensures greater coverage and resilience.
However, it also introduces the risk of duplicate event reporting, where the same event is received twice: once from the pixel and once from the server.
To prevent this, every platform supports a common deduplication scheme:
event_name — The type of event (e.g. Purchase, AddToCart)
event_id — A shared unique identifier for that event, passed from client to server
When both browser and server versions of the event include the same event_id, the platform knows to deduplicate them.
Without this, platforms may:
Inflate conversion counts
Misattribute conversions
Undermine campaign optimization models
Standard Deduplication Approaches
There are two main approaches to align event_id values across browser and server:
1. Client-Generated Event ID
The event is first triggered in the browser (e.g. via a platform pixel or analytics library).
A unique event_id is generated client-side and attached to the pixel event.
The same ID is propagated to your server and then attached to the CAPI event.
This approach is most common, especially in traditional web environments where JavaScript and network payloads can flow freely.
2. Server-Generated Event ID
The server (or an analytics middleware like Triple Whale Sonar) generates the event independently.
This server event includes its own event_id, which typically cannot match the browser event unless a shared mechanism exists.
This is where things get tricky—especially for Sonar users.
🧩 The Pixel Isolation Problem — Why Sonar Can’t Always Deduplicate
The core challenge with deduplication in Sonar comes down to how you manage your various ad tags.
🔒 Triple Whale doesn’t manage or control the other ad platform pixels on your site.
Ad platforms like Meta, Google Ads, TikTok, and others each inject their own client-side tags, often through Shopify integrations, GTM, or native apps. These tags generate their own unique event_ids at runtime—but because Triple Whale didn’t create those IDs, we can’t replicate them in our server-side CAPI calls.
This breaks the basic deduplication model, which requires that both client and server versions of an event include the same event_id. Without that match, the ad platform treats them as two separate events—leading to inflated reporting and degraded optimization.
🕳️ The Meta Loophole: Listening for Event IDs
Meta is a rare exception.
Through careful inspection of how the Meta Pixel queues its events (fbq), Triple Whale has developed a method to intercept and extract the eventID before the pixel sends the event. This allows Sonar to capture the ID and include it in the server-side version of the same event—achieving clean deduplication without requiring any changes from the merchant.
Unfortunately, this technique doesn’t work with other platforms:
TikTok, Google Ads, Snap, and Pinterest use minified, obfuscated, or encapsulated logic to dispatch events.
These platforms do not expose or broadcast their event_ids in any detectable way.
As a result, Sonar cannot extract or reuse these IDs for deduplication on non-Meta platforms.
🛠️ The Real Solution: Advertiser-Managed Event IDs
To support deduplication across all ad platforms, the only universal solution is:
🎯 The advertiser must generate a shared event_id and pass it to both the client-side pixel and Sonar.
This is typically feasible in headless commerce environments, where developers control the event lifecycle and pixel logic. In those cases:
A single event_id can be generated per interaction (e.g., a purchase).
That ID can be passed to both:
The platform pixel (gtag, ttq, snaptr, etc.)
The Triple Whale endpoint powering Sonar’s server-side events
This coordination enables platforms to correctly deduplicate the browser and server versions of the same event.
In traditional Shopify storefronts, however, where ad pixels are injected automatically via apps or Shopify settings, the merchant usually has no control over the event_id. That makes this kind of synchronization impractical.
✅ Recommended Approach for Most Sonar Users
Given these constraints, we recommend:
Create a separate pixel or dataset for Sonar’s server-side events, particularly for platforms where deduplication isn’t possible.
This ensures:
Clean conversion streams
No double-counting
Accurate attribution and optimization
Meta is the exception—Sonar handles deduplication out-of-the-box for Meta Pixel users.
Conclusion
Event deduplication is non-negotiable when sending CAPI events. While most platforms use a simple event ID-based strategy, implementation details matter—a lot. With Sonar, the inability to control third-party pixel behavior means deduplication is only possible under specific conditions.
For Meta, we’ve engineered a solution to extract the needed eventID. For all other platforms, the best path forward is advertiser-managed event coordination—or separating server and browser signals into distinct datasets.
When set up intentionally, Sonar gives advertisers a clean, trustworthy signal stream that powers smarter targeting and more accurate reporting—without the noise.