GA4 duplicate page views: how to find the cause and fix it

Duplicate page views rarely announce themselves with an error. You notice them because numbers stop making sense. Typical signs:

• Views per session jumped on a specific date, with no obvious change to the store or its traffic.
• In DebugView or the Realtime report, a single page load shows two page_view events with practically the same timestamp.
• In the Pages and screens report, views for individual pages look implausibly high compared to users.
• Funnel explorations show a step with more views than the step before it, which hardly makes sense.

This is more than a cosmetic issue. Duplicate page_view events skew views per session, path analysis and any report built on page views. If the same root cause affects events like add_to_cart or purchase, revenue and conversions are overstated as well. So it pays to find the real cause instead of mentally halving your reports.

Almost every case follows one pattern: the same event is sent from two independent places. In e-commerce, these are the usual suspects.

GTM and gtag.js running side by side

The Google tag (formerly the configuration tag) runs in Google Tag Manager, while a hard-coded gtag.js snippet with the same measurement ID still sits in the theme or comes from an app or plugin. Both send a page_view automatically when the page loads. This often happens after a migration to GTM where the old code was never removed.

Store integration plus GTM

Most store platforms ship their own analytics integration, and many add-ons do too. Shopware 6, for example, has an analytics setting per sales channel. If a GA4 measurement ID is entered there and GTM also runs a Google tag for the same ID, GA4 counts twice.

Container loaded twice

The GTM container itself is loaded twice, for example once in the template and once through a plugin or the consent tool. Depending on the setup, tags then fire more than once, and that affects every tag in the container, not only GA4.

Enhanced Measurement and history changes

GA4's Enhanced Measurement can count page views when the browser history changes. This is meant for single-page apps and headless frontends where the page does not fully reload. If the frontend also sends its own page_view, or GTM has a separate history change trigger, you get duplicates. Classic stores are affected too when filters, sorting or variant selection change the URL via JavaScript.

Other triggers

• An extra GA4 event tag named page_view, although the Google tag already sends one automatically.
• The Google tag fires once on page load and again after consent because two triggers are attached.
• The same measurement ID is configured as a destination in more than one Google tag.

You don't need GA4 access for the diagnosis, just a browser with developer tools. Work through these steps:

1. Open the Network tab. Open developer tools, go to Network, enable preserve log and reload a product page. Filter for collect. GA4 hits go to an endpoint containing /g/collect.
2. Count the hits. In each request, look at the en parameter (event name) and tid (measurement ID). GA4 can batch several events into one request, so check the request payload as well. Two page_view events with the same tid from a single page load confirm the problem.
3. Search the page source. Look for gtm.js and gtag/js. If the GTM ID appears twice, or there is a separate gtag snippet with a G- ID, you have found your candidate.
4. Use GTM preview. Preview mode (Tag Assistant) shows which tags fired on which event. If the Google tag fires twice, or an extra event tag sends page_view, the cause is in the container.
5. Test a history change. Click a filter or variant that changes the URL and watch how many page_view events follow.

Important: test both with and without accepting the cookie banner. Some duplicates only appear after consent, when tags are fired a second time.

The fix follows one simple principle: for each measurement ID and each event, exactly one place is responsible. In most stores that place is Google Tag Manager, because consent, triggers and versions can be managed centrally there.

• Remove hard-coded gtag.js if GA4 runs through GTM. Check the theme, template extensions and plugins.
• Disable the store's built-in analytics integration, or clear the measurement ID there, if GTM takes over. The reverse works too: if you deliberately use only the platform integration, GTM must not run a second Google tag for the same ID.
• Load the container once. Choose one installation method and remove the other. That includes consent tools that can optionally load GTM themselves.
• Decide who handles history changes. In SPAs and headless frontends, use either Enhanced Measurement's automatic detection or a page_view sent by the frontend, not both. If you send it yourself, turn off the automatic page view in the Google tag, for example with send_page_view set to false, and disable history-based detection in the Enhanced Measurement settings.
• Delete redundant event tags that send page_view on top.
• Clean up triggers so the Google tag doesn't fire once before and once after consent. With Consent Mode, one trigger is usually enough; consent is handled through the consent state.

Publish GTM changes as a new version with a clear name so you can roll back if needed.

GA4 does not correct data that has already been collected. The duplicate views stay in the period before your fix. Record the date of the change, internally or as an annotation in your reporting, so nobody later mistakes the correction for a sudden drop in page views.

For comparisons across the fix date, use metrics that are less affected, such as users, sessions or orders from your store backend. Compare page-based metrics only from the fix date onward.

Also check whether other events were affected. If two Google tags ran in parallel, e-commerce events may have been sent twice too. Comparing GA4 purchases with actual orders in your store for the same period quickly shows whether revenue was inflated. Some gap is normal, for example due to missing consent or ad blockers. Clearly more purchases in GA4 than in your store, however, is a red flag.

• Each page load sends exactly one page_view per measurement ID, checked in the Network tab including batched requests.
• The GTM container appears only once in the page source.
• There is no extra gtag.js snippet with the same G- ID in the theme or any plugin.
• The platform's analytics setting is empty, or GTM is not handling the same ID.
• GTM has no separate event tag for page_view while the Google tag sends it automatically.
• The Google tag has exactly one trigger and does not fire again after consent.
• For URL changes without a reload, it is clear who sends the page view: Enhanced Measurement or the frontend.
• Tested with and without accepting the cookie banner.
• Date of the fix documented.
• GA4 purchases compared with store orders for a test period.

For a quick first read on whether tags load twice in your store, run the free self-check: it opens your homepage and a product page like a visitor and flags duplicate tags, GA4 and GTM, among other things, in about a minute.