The Most Common GA4 Implementation Issues We Find in Audits

Most unreliable Google Analytics 4 implementations are not completely broken. They are collecting enough data to appear functional, while a combination of legacy tags, duplicated events, missing parameters, attribution problems and undocumented changes quietly undermines the reports built from them.

After reviewing and implementing Google Analytics across ecommerce, government, healthcare, finance, education, not-for-profit and multi-site organisations, we repeatedly find the same underlying problem: the implementation has evolved without a clear measurement strategy or ongoing ownership.

Tags have been added by different developers, agencies and marketing teams. Websites have been redesigned. Forms and checkout systems have changed. Data-layer values have disappeared. New events have been placed on top of old ones without anyone first establishing exactly what is already being collected.

The result is often a GA4 property that contains plenty of data, but cannot reliably answer the organisation’s most important questions. That is why measurement reliability has to come before optimisation, reporting or AI-assisted analysis.

The short answer

The most common GA4 implementation issues we find are legacy and undocumented tracking, duplicate tags and events, brittle website-based triggers, inconsistent measurement across multiple websites, broken cross-domain attribution, poorly defined conversions, inherited Universal Analytics structures, missing parameters, weak governance and a lack of ongoing quality assurance.

These problems can distort engagement, conversion and channel reporting. They also make AI-assisted analysis less reliable because an AI system generally interprets the data it receives; it does not independently prove that the underlying tracking was implemented correctly.

Common GA4 problems at a glance

1. Legacy implementations accumulate over time

One of the most common problems we encounter is a GA4 and Google Tag Manager implementation that has passed through several different hands.

The original tracking may have been configured by a developer or agency several years ago. Since then, new marketing managers, developers, platforms and external suppliers have added tags to meet immediate requirements. Each individual addition may have seemed reasonable, but nobody has stepped back to review the implementation as one measurement system.

Over time, the container becomes harder to understand. Old tags remain active. New tags replicate existing functionality. Naming conventions vary. Triggers overlap. Variables no longer have an obvious purpose. Hardcoded tracking may operate alongside GTM without being documented in the container.

This creates two risks.

First, nobody can confidently explain what the implementation is doing. Second, each new change is made on top of an uncertain foundation, making the setup progressively more complicated and fragile.

We sometimes describe analytics as being like a garden. It does not remain orderly simply because it was implemented correctly once. Websites, campaigns and business requirements change, and the measurement environment needs to be maintained with them. Without that maintenance, outdated tracking behaves like weeds: it spreads, overlaps with newer work and makes the useful parts harder to see.

2. Duplicate tags and events create believable but incorrect data

Duplicate tracking is particularly common when organisations have large websites, multiple platforms or several teams working on the same implementation.

A Google tag may be hardcoded into the website while another GA4 configuration is deployed through Google Tag Manager. A CMS plugin, ecommerce integration or third-party application may also send events to the same measurement ID. Each source can appear to be working correctly when reviewed in isolation, while collectively sending the same interaction more than once.

Common examples include:

• Two page_view events being sent for one page load.
• A form submission being recorded by both a website plugin and GTM.
• A purchase event firing from the ecommerce platform and again on the confirmation page.
• Enhanced Measurement collecting an interaction that is also tracked through a custom event.
• The same GTM container or Google tag being installed more than once.

Duplicate page views inflate view and event counts. They can also distort engagement and bounce-rate reporting because a session with two or more page views meets one of GA4’s engaged-session conditions, even when the second page view was generated by a tracking error rather than another page being viewed.

Duplicated key events are more commercially damaging. If a lead or purchase is counted twice, conversion rates, revenue, campaign performance and return-on-ad-spend reporting may all be overstated. This is one of the first issues we look for in a structured GA4 audit.

The difficult part is that the resulting numbers can still look plausible. A report does not display a warning saying that two implementation methods generated the same event. The duplication normally has to be found by inspecting the live website, network requests, data layer, GTM configuration and GA4 event data together.

3. Website changes quietly break event tracking

Tracking frequently depends on website elements that change over time.

For example, an event may fire when GTM detects a particular CSS class, element ID, link text or page structure. A developer can update a component, rename a class or replace a form without knowing that analytics relies on that exact element. The website continues to work for users, but the corresponding analytics event stops firing.

We also see data-layer implementations degrade after redesigns and platform changes. An event may continue to be sent while important values such as product name, form type, content category, location or transaction information are missing. GA4 then records an event with incomplete parameters or (not set) values.

This is why seeing an event name in GA4 is not proof that the event is healthy. A proper review needs to establish:

• Whether the event fires on the correct interaction.
• Whether it fires once rather than multiple times.
• Whether it fires consistently across devices, templates and websites.
• Whether all required parameters are populated.
• Whether the parameter values use the agreed format.
• Whether the event reaches the intended GA4 property and advertising destinations.

Where an interaction is commercially important, a stable data-layer event is generally more maintainable than tracking based only on the visible structure of the page. It gives the website and measurement implementation a defined contract rather than relying on selectors that can change during routine design work.

4. Multi-site organisations lose visibility across their measurement estate

Tracking health becomes harder to manage when an organisation operates multiple websites, brands, regions, services or GA4 properties.

One website may use a current GTM implementation while another still contains hardcoded tags. Similar actions may have different event names across sites. One property may classify a form as a key event while another treats the same interaction as ordinary engagement. Parameters may differ even when the events appear to have the same name.

This prevents reliable comparison. A report may show that one brand generates fewer enquiries than another when the real difference is that the sites measure enquiries differently.

Smaller analytics and marketing teams are especially vulnerable because checking every property and website manually takes time. Problems can remain isolated within one part of the estate for months before someone notices an unexpected change in a group-level report. Our case studies show how multi-site and multi-journey implementations become usable again once naming, ownership and QA are brought into one system.

A sustainable multi-site implementation requires more than placing the same GA4 measurement ID everywhere. It needs:

• A documented account and property architecture.
• Standard event names and definitions.
• Shared parameter requirements.
• Agreed rules for key events.
• Clear ownership of global and site-specific tags.
• A consolidated view of tracking health.
• Recurring testing across each priority website and journey.

5. Cross-domain journeys damage attribution

Many organisations send users between domains as part of a normal customer journey. Common examples include payment providers, booking systems, donation platforms, application portals, customer-service platforms and third-party forms.

Without correctly configured cross-domain measurement, GA4 may not preserve the client identifiers required to recognise the journey as one continuous user session. The original marketing source can be lost or obscured, and the second domain—or an intermediary platform—may appear as the source of the conversion.

This can create misleading increases in Direct, Referral or other channels while understating the campaign, organic search result or referring website that originally brought the user into the journey.

The problem becomes more complex when several websites feed into one shared third-party platform. A conversion may be sent from that platform without enough information to associate it with the correct originating website, brand or GA4 property. The organisation can see that a conversion occurred, but not reliably identify which website or channel contributed to it.

Cross-domain measurement and unwanted-referral configuration solve related but different problems. Cross-domain measurement is used to maintain continuity between domains that are part of the same measured journey. An unwanted-referral list can prevent an intermediary such as a payment gateway from being treated as a new referral source. Adding a domain to the unwanted-referral list alone does not create a complete cross-domain implementation.

Google’s documentation explains how cross-domain measurement uses a linker parameter to share identifiers between configured domains, while unwanted referrals control which referring domains should not appear as traffic sources.

6. Too little—or too much—is classified as a conversion

Some GA4 implementations collect little more than page views and a small number of conversions. This leaves marketing, content and product teams without enough information to understand how users progress through important journeys.

For example, an organisation may record a completed enquiry but not the preceding service selection, location choice, form start or validation failure. The final number is available, but there is no practical way to investigate why users did or did not complete the journey.

The opposite problem is also common: too many interactions are marked as key events.

If every download, button click, video play and form interaction is treated as a conversion, the organisation loses sight of which outcomes actually matter. Advertising platforms may optimise towards low-value actions, and stakeholders can struggle to distinguish genuine business outcomes from general engagement.

The solution is not simply to track more events. It is to establish a measurement strategy that separates:

• Business outcomes, such as purchases, qualified leads or completed applications.
• Journey milestones that help explain progression and abandonment.
• Supporting engagement signals used for content and experience analysis.
• Diagnostic events required for implementation monitoring.

Each event should have a defined purpose. Key-event status should be reserved for actions the organisation genuinely considers important enough to use in performance and optimisation decisions. GA4 consulting should start with those definitions, not with a larger tag inventory.

7. Universal Analytics structures remain inside GA4

We still encounter GA4 implementations that were automatically migrated or recreated from Universal Analytics without redesigning the event model for GA4.

Universal Analytics commonly organised events using Event Category, Event Action and Event Label. GA4 uses an event name with associated event parameters. Carrying the old structure forward can produce generic event names accompanied by parameters such as event_category, event_action and event_label that make sense only to someone familiar with the previous implementation.

This creates an unnecessarily confusing reporting environment. Marketing managers may see an event name without understanding which parameters need to be added to a report. Important parameters may not be registered as custom definitions. Similar actions may be grouped together under generic names, making the data harder to interpret and govern.

A GA4 implementation should not simply imitate the old Universal Analytics structure. Its event taxonomy should be designed around the organisation’s current customer journeys, reporting questions and activation requirements.

Clear names such as form_start, generate_lead, service_search or an appropriately governed business-specific event are easier to understand than a generic interaction event whose meaning is hidden across several legacy parameters.

8. Events are collected without enough context

An event can be technically valid and still be analytically weak.

Consider a website that sends generate_lead whenever any form is completed. If the event does not include the form name, form type, website, service, location or other relevant context, the organisation may know how many leads were recorded but not what those leads relate to.

Missing context becomes particularly damaging in multi-site and multi-service organisations. The same event name may represent dozens of different forms and user intentions.

Useful parameters should be designed as part of the measurement plan, rather than added reactively after stakeholders discover that a report cannot answer their question. Those parameters also need consistent naming, formatting and scope so that they work predictably in GA4, BigQuery, dashboards and AI-assisted analysis.

9. Documentation and ownership are missing

Many tracking problems are ultimately governance problems.

New staff members inherit a GA4 property and GTM container without a measurement plan, event dictionary, change log or clear explanation of the account structure. They cannot determine which tags are still required, which events are business-critical or why particular decisions were made.

Rather than risk removing something important, teams leave the old implementation in place and add new tracking beside it. That is how a manageable container becomes a collection of overlapping implementations.

A maintainable setup should give future teams a clear record of:

• What each event means.
• When it should fire.
• Which parameters it requires.
• Which business question it supports.
• Whether it is a key event.
• Which GA4 properties and advertising platforms receive it.
• Who owns the event or journey.
• When the implementation was last tested.

Documentation is not an optional handover item. It is part of the measurement system.

10. Unreliable tracking produces unreliable AI analysis

More organisations are feeding GA4, advertising and business data into AI-assisted analytics workflows to accelerate reporting and analysis. This makes measurement quality more important, not less important.

An AI assistant generally does not know that a website stopped sending purchase events for three weeks, that one brand fires a lead event twice, or that a redesign removed a required data-layer parameter. Unless that context is provided, the assistant may treat the recorded data as a faithful representation of business performance.

This can produce a confident explanation built on an implementation fault.

Even when the underlying data is correct, AI-generated analysis still requires review. GA4 contains dimensions and metrics with different scopes and compatibility rules. Combining incompatible fields, mixing user and session measures, or comparing differently defined conversions can produce an invalid result that nevertheless sounds reasonable.

AI-assisted analytics therefore needs three foundations:

1. Reliable underlying tracking and source data.
2. Clear definitions and business context.
3. Evidence requirements and informed human review.

AI can help analysts investigate patterns and prepare reporting. It cannot retroactively make a broken measurement implementation trustworthy.

Why consistency matters for historical comparisons

Tracking problems do not affect only the day on which they occur. They can undermine months of future analysis.

Suppose purchase tracking stops for part of the current year. When a stakeholder later asks how revenue performed compared with the previous year, GA4 may show a substantial decline. The apparent decline may have little to do with customer behaviour; revenue was simply absent from the dataset during the affected period.

The same problem applies to leads, add-to-cart activity, applications and other important events. If the implementation changes without being documented, analysts may compare two periods that were measured differently.

Historical GA4 collection generally cannot be repaired simply by correcting the tag today. The fix improves data collected from that point forward, but the affected historical period still needs to be identified, documented and, where possible, reconciled against ecommerce, CRM or other first-party records.

This is why change logs and recurring monitoring are essential. They allow analysts to distinguish business performance changes from measurement changes and place appropriate caveats around period-on-period comparisons.

How we audit and rebuild a GA4 implementation

Our approach begins by treating the implementation as a connected measurement system rather than a collection of individual tags.

1. Review the complete measurement estate

We identify the relevant websites, domains, GA4 accounts and properties, GTM containers, hardcoded Google tags, ecommerce or form platforms, advertising destinations and reporting outputs.

This is especially important for organisations with multiple brands or websites because the main property rarely reveals every tracking source on its own.

2. Test priority journeys at event and request level

We test how events are generated on the website, inspect the data layer and browser requests, and confirm what reaches GA4. This helps identify duplicate events, missing values, incorrect destinations, broken triggers and cross-domain discontinuity.

3. Define the measurement strategy

The most important part is deciding what the organisation actually needs to measure.

We work with stakeholders to understand the business outcomes, customer journeys, reporting requirements and activation needs. This prevents the new implementation from becoming another technically functional collection of events with no clear analytical purpose.

4. Create the measurement plan and visual tracking map

We document the proposed events, parameters, definitions, triggers, key-event status and destinations. We also map the customer journey visually so marketing, analytics, development and leadership teams can understand how the measurement fits together.

5. Remove or isolate outdated tracking

Legacy, duplicated and superseded tags are cleaned up carefully, with backups, workspaces and change documentation retained so that important functionality is not removed blindly.

6. Implement the new event taxonomy

We configure the agreed tracking through Google Tag Manager and work with developers where stable data-layer changes are required. The implementation is built around clear naming, consistent parameters and defined business use.

7. QA, document and explain the resulting data

After implementation, we retest the priority journeys and validate the resulting GA4 data. We then provide the event documentation, reporting guidance and practical explanation teams need to use the information correctly.

Where appropriate, this can include defining reporting outputs and establishing how validated data may be used in an AI-assisted analytics workflow without losing its definitions, limitations or supporting evidence.

How often should GA4 tracking be audited?

There is no universal audit schedule. The appropriate frequency depends on the volume and value of the data, how often the website changes and how many platforms or websites are involved.

As a practical starting point:

• Stable, lower-change implementations should receive a structured review at least quarterly and after material website releases.
• Active ecommerce, lead-generation and multi-site implementations may require monthly monitoring.
• High-volume or commercially critical journeys may justify weekly or automated checks for priority events and parameters.

An audit should also be triggered by a website redesign, platform migration, new checkout or form provider, consent-management change, major campaign launch, unexplained reporting movement or change of agency or internal ownership.

The aim is not to conduct a full rebuild every month. It is to detect deterioration early enough that teams do not make decisions using months of unreliable data.

Frequently asked questions

What is the most common GA4 implementation problem?

The most common underlying problem is accumulated, undocumented tracking. Tags and events have been added by different teams over time without first auditing the existing implementation. This produces duplicate collection, outdated events, inconsistent naming and uncertainty about what the data represents.

How can I tell whether GA4 is double tracking?

Common warning signs include unexpectedly high views per user, inflated engagement, duplicate conversions, repeated events in DebugView and multiple Google tags or GTM containers loading on the same page. Confirmation requires testing the website and inspecting the requests sent for a single interaction.

Why does GA4 attribute conversions to referral or direct traffic?

Possible causes include incomplete cross-domain measurement, third-party payment or form domains, redirects that lose campaign information, missing linker parameters, consent behaviour or conversions sent without the identifiers needed to associate them with the original session. The exact cause needs to be tested across the complete journey.

Can fixing GA4 repair historical data?

Usually, correcting an implementation improves future collection rather than rewriting the already processed historical period. Affected dates should be documented and, where possible, reconciled against ecommerce, CRM or other first-party records before comparisons are made.

Can AI identify whether GA4 tracking is wrong?

AI can help detect unusual patterns when it has appropriate access to the data and definitions, but it cannot assume that an event was implemented correctly. Reliable validation still requires evidence from the website, data layer, tag configuration, network requests and relevant source systems.