Server-side deduplication
Server-side tagging and the Measurement Protocol let the server emit events alongside the browser. If a conversion fires from both the client tag and the server without coordination, it is counted twice. Deduplication on a shared event identifier prevents this, mirroring how ad platforms dedupe browser and server signals. This page explains the dual-send problem and the id-based dedup that solves it.
The dual-send problem
Modern setups often send the same event from two places: the browser (gtag/GTM) and the server (server-side GTM or the Measurement Protocol), for resilience against ad blockers and ITP. Without coordination, the platform sees two distinct events for one real action and counts both, inflating pageviews, conversions, or purchase revenue.
Deduplicating on an event id
The fix is a shared identifier. For purchases, GA4 already dedupes on transaction_id, so client and server purchase events for the same order collapse. For other events, you assign a common event_id (or equivalent) to both the client and server send, and the platform discards the duplicate. Meta and other ad platforms use the same browser/server dedup pattern with an event_id.
The id must be generated once for the logical event and shared between both senders; generating separate ids per sender defeats dedup entirely.
- Client + server can both send the same event
- Without dedup, one action is counted twice
- Purchases dedupe on transaction_id; others need a shared event_id
- The id must be one value shared by both senders
How it appears in analytics and logs
Conversions roughly doubling after a server-side rollout means client and server events are not being deduplicated against a common event id.
Diagnostic use case
Explain inflated conversions after adding server-side tracking, traced to the same event firing client-side and server-side without a shared dedup id.
What WebmasterID can help detect
WebmasterID records conversion events with a stable identifier first-party, so you can confirm a single logical event is not counted from two senders.
Common mistakes
- Sending client and server events without a shared id.
- Generating different event ids per sender for one action.
- Forgetting only purchases auto-dedupe on transaction_id.
Privacy and accuracy notes
Server-side events can carry more data; minimize and govern what you send, and never put personal data in a dedup id. This page is educational, not legal advice.
Related pages
- Transaction ID deduplication
Ecommerce purchases are deduplicated on transaction_id. If a confirmation page reloads or a user refreshes, the same purchase event can fire twice; GA4 collapses repeated transaction_ids so revenue is not double-counted. The flip side: a missing transaction_id, or one reused across different orders, breaks dedup and corrupts revenue. This page explains the mechanism and its failure modes.
- Duplicate transactions in ecommerce data
Duplicate transactions occur when one purchase is counted more than once — usually because the order-confirmation page is reloaded, bookmarked, or shared, or because a retry resends the same event. GA4 deduplicates ecommerce purchases on `transaction_id`, so an absent or unstable ID is the root cause. This page covers detection and the deduplication key.
- Double-counting pageviews
Double-counting happens when a single page load fires the analytics tag more than once. Two snippets on the page, a tag added in both the site and a tag manager, or an SPA that fires a virtual pageview on top of the full-load one all do it. The result inflates pageviews and drags engagement and bounce metrics. This page covers detection and the fixes.
- Event Explorer
Verify one logical event is not double-sent.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.