By Marc Alexander

Duplicate key events (what GA4 called conversions until 2024, as the key events guide explains) do quiet damage. The numbers look healthy, people trust them, decisions get made, and none of it matches reality.

If GA4 shows more leads, sign-ups or purchases than your CRM, payment processor or other system of record, something is firing more than once.

What duplicates look like.

The obvious sign is a key event count well above your real outcomes: more form submissions, purchases or sign-ups in GA4 than in your CRM, Shopify order count or payment processor.

Less obvious signs: conversion rates that look too good, GA4 revenue at a multiple of real revenue, or single users in the User explorer exploration with the same event firing two or three times within seconds.

First work out which key event is the problem. Check each one in Reports → Engagement → Key events. The duplicate is often limited to one event, which narrows the cause a lot.

Cause 1: Two tracking setups running at once.

The most common cause, and the first thing to check.

If the site has a GTM container and a hardcoded gtag.js snippet, or two GTM containers, GA4 may be getting every event twice. It often happens after a migration or rebuild, or when a developer adds a tag without knowing GTM already handles it.

How to check: Open the browser's developer tools, go to the Network tab and filter for google-analytics.com or analytics.google.com. Two identical requests for the same event at the same moment means double-tagging. Tag Assistant shows the same thing: the same Measurement ID loaded more than once, or two implementations sending to one property.

How to fix it: Remove one implementation completely. The cleanest setup is GA4 firing only through GTM. Take out any hardcoded gtag.js in the site's <head> that sends to the same Measurement ID. If there are two GTM containers, audit both and consolidate.

Cause 2: A GTM trigger firing more than once.

Even with one implementation, a trigger can fire more than once per action, especially on thank-you and confirmation pages.

Two common versions: the tag fires on page view and the thank-you page loads twice because of a redirect or a second page view; or the tag has two triggers attached (say Page View and Window Loaded) and both are true on the same page.

How to check: Walk through the journey in GTM Preview (Tag Assistant). On the confirmation page, look at Tags Fired. If the tag appears more than once for one page load, it's a trigger problem.

How to fix it: Remove redundant triggers. If the tag should fire on page view, use one trigger, not both. If a redirect causes a double page view, fix the redirect rather than working around it in GTM.

Cause 3: The purchase event has no transaction ID.

For ecommerce, GA4 deduplicates purchase events, but only if each one carries a unique transaction_id. If it's missing, empty or a fixed placeholder, GA4 counts every firing.

This bites when the confirmation page loads more than once: a refresh, the back button, or a link back to it from an order email.

How to check: In GTM Preview, make a test purchase and look at the purchase dataLayer push. Is transaction_id there, and is it the real order reference? In DebugView, expand the purchase event: if transaction_id is missing or undefined, that's the issue.

For historical data, build a free-form exploration with Transaction ID and the purchase event count. The same ID appearing more than once means deduplication isn't working.

How to fix it: Make the purchase dataLayer push always include a unique transaction_id matching the order ID from your platform. On Shopify, WooCommerce and most ecommerce platforms the order ID is available on the confirmation page. It must be a string, unique per order, and present every time the event fires.

Cause 4: A single page application re-firing on route changes.

Single page applications (built in React, Vue, Angular and similar) don't load a new page when the user moves between views. The URL changes through the History API while the same page stays loaded.

If a key event tag fires on a GTM History Change trigger, it can fire on every route change, including repeated changes around the confirmation screen, rather than once per sale or lead.

How to check: In GTM Preview, move through the site as a user would and count how often History Change fires around the confirmation step. If the tag fires on route changes that aren't the confirmation, it's a scoping problem.

How to fix it: Add a condition to the trigger so it only fires when the new path is the confirmation URL, for example Page Path contains /order-confirmation. Don't use History Change on its own without scoping it.

Cause 5: Server-side and client-side both sending the event.

If server-side GTM was added alongside an existing browser setup, the same event can reach GA4 twice: once from the browser and once from the server.

It usually happens when server-side is added without turning off the browser version of what the server now handles. The purchase event is most at risk, because it's often the first thing moved server-side.

How to check: In DebugView, trigger the event and count the instances. Two identical events within a second or two, with the same parameters, strongly suggests both routes are sending.

How to fix it: Decide which route owns each event and stop the other. If purchase is now handled server-side, change the browser tag's trigger so it no longer sends purchase to GA4 directly.

Cause 6: Cross-domain tracking breaking the session.

When a user goes from your site to a payment gateway on another domain and back, GA4 can lose the session and start a new one. This doesn't usually double the event itself, but it splits one journey into two sessions (and often two users), and credits the sale to Direct.

If the return also reloads the confirmation page, you can get a genuine duplicate too.

How to check: Look for a spike in Direct traffic to your confirmation or return URL. Direct on a post-checkout page is a classic sign the session was dropped. In GTM Preview, walk through checkout and see whether the client ID changes when you come back from the gateway.

How to fix it: Configure cross-domain measurement in Admin → Data Streams → your web stream → Configure tag settings → Configure your domains, listing every domain in the journey that you control. Add third-party gateways you return from to the unwanted referrals list. The cross-domain tracking guide has the full setup.

Cause 7: Form resubmission on refresh.

If the key event fires on form submission and the page doesn't redirect afterwards, a refresh brings up the browser's "resubmit form data?" prompt. If the user confirms, the event fires again.

How to check: Submit the form, stay on the same URL and refresh. Check in GTM Preview whether the tag fires again.

How to fix it: Use the Post/Redirect/Get pattern: after a successful submission, redirect to a thank-you page. A refresh then reloads the thank-you page with no form data to resend. It's a development change rather than a GA4 change, and it removes a whole class of duplicates.

If a redirect isn't possible, a GTM condition that blocks the tag on a reload is a fallback, but it's less reliable.

Cause 8: Google Ads counting twice.

This sits outside GA4 but produces the same symptom. If you import GA4 key events into Google Ads and also have a Google Ads conversion tag on the same action, Google Ads counts both. It's common after migrations where the old Ads tag stayed in place when the import was set up.

How to check: In Google Ads, go to Goals → Conversions and look for an action imported from GA4 alongside a tag-based action for the same thing, both set as primary.

How to fix it: Choose one as the source of truth for bidding and keep it as the primary action. Set the other to secondary so it's still reported but not counted twice, or remove it once you're sure the primary one works.

How to verify the fix.

Don't rely on GTM Preview alone. It runs in a debug context that can differ from live traffic.

  1. Turn on debug mode (through GTM Preview, the Google Analytics Debugger extension or a debug_mode parameter on the tag) and walk through the whole journey while watching DebugView
  2. Check the key event appears exactly once per journey, with every expected parameter, including transaction_id for purchases
  3. For purchases, place two test orders with different order IDs and confirm both appear, each with its own transaction ID. Then reload the confirmation page for one order and confirm no second purchase is counted.
  4. After a few days live, compare GA4 against your system of record (CRM, payment processor, form database) for the same period. A good fix brings the numbers much closer.

Summary.

Duplicate key events rarely have one universal cause. Diagnose first with GTM Preview and DebugView, then fix at the source rather than compensating later.

As a rough guide: double-tagging is the most common and easiest to fix. Missing transaction IDs are the usual ecommerce cause. History Change triggers are the usual single page application cause. Cross-domain problems show up on sites with external payment gateways.

If you've worked through all of this and the numbers still don't add up, the problem is probably two or more of these causes interacting. That's where a structured GA4 audit finds what individual checks miss. Marc Alexander, a GA4 consultant, can then fix them at source.

Sources.

Checked on 31 October 2026.