What to Look for in a GTM and GA4 Data Quality Audit

GA4 data quality is the largest audit category in any GTM container review, and for good reason — GA4 is where the measurement happens. Consent configuration determines whether tags fire legally, and container hygiene determines whether someone else can maintain the container, but GA4 data quality determines whether the numbers you're making decisions with are actually correct. Twenty-four rules across event naming, parameter architecture, ecommerce tracking, and configuration settings, and most containers have findings in at least three of those areas.

The common thread across GA4 data quality problems is that they fail silently. A misconfigured consent setup might produce a banner that looks like it's working, and a messy container might still function, but a GA4 event name that exceeds 40 characters simply doesn't record — and nobody finds out until someone asks why a specific interaction has zero data in the reports. The feedback loop between implementation error and visible consequence can be weeks or months, which is why auditing proactively matters.

This piece covers every GA4 and ecommerce finding category, what each one means in practice, and what to do about it.

Event naming rules

GA4 enforces strict rules on event names, and violations cause data loss that's difficult to detect without deliberately testing for it. These are the naming checks that surface the most findings in container audits.

Invalid characters in event names. GA4 event names can only contain letters, numbers, and underscores, and they must start with a letter. Spaces, hyphens, periods, and special characters cause the event to fail silently — the most common violation being developers using hyphens (form-submit) instead of underscores (form_submit) because hyphens are the convention in CSS and URL slugs. The event gets sent, GA4 ignores it, and the data never appears in reports.

Event names exceeding the 40-character limit. GA4 enforces a hard 40-character maximum for event names, which means descriptive names like product_comparison_tool_calculation_complete look reasonable in a spec document but exceed the limit by two characters and won't record. This tends to emerge in implementations where the naming convention tries to encode too much information into the event name rather than using parameters.

Casing inconsistency. GA4 event names are case-sensitive, so form_submit and Form_Submit are different events, each consuming a slot in your 500 distinct event name limit. When multiple people implement tracking without a shared convention, mixed casing fragments what should be a single event into multiple events with identical intent but separate reporting.

Reserved event name collisions. GA4 reserves event names that start with google_, ga_, firebase_, and gtag. prefixes. Using these prefixes doesn't throw an error in GTM — the tag fires, the event appears to send — but GA4 rejects it on ingestion, and the failure only surfaces when someone checks why a specific event has no data.

Enhanced measurement conflicts. GA4's enhanced measurement automatically tracks certain interactions: page views, scrolls, file downloads, form submissions, and video engagement. When a custom event uses the same name as an enhanced measurement event (like file_download or scroll), both the automatic and custom events fire, which means download counts double, scroll engagement inflates, and the duplicate is invisible in standard reports unless you specifically compare the event source.

The event proliferation problem

Event proliferation is the most structurally damaging GA4 pattern, and it comes from a reasonable instinct: when you're not sure how to structure tracking, creating a new event for each variation feels safe. Nobody gets blamed for creating too many events — they get blamed when data is missing.

The result is containers where form_submit_contact, form_submit_demo, form_submit_newsletter, form_submit_pricing, and form_submit_careers are all separate events tracking the same fundamental interaction. Each one consumes a slot in the 500-event namespace, each one gets its own row in reports, and comparing form submissions across types requires manually combining five events instead of filtering one event by a parameter.

The fix is straightforward in concept: one event (form_submit) with a parameter (form_type) that captures the variation. A form_type parameter with values like "contact", "demo", "newsletter" gives you the same segmentation capability with a single event that's reportable, comparable, and scalable — and when marketing adds a new form, you add a parameter value rather than a new event.

The pattern extends beyond forms. Page-specific events (cta_click_homepage, cta_click_pricing, cta_click_blog) should usually be one cta_click event with a page_section parameter, and product-specific events (view_product_electronics, view_product_clothing) should be one view_item event with item category parameters. Any time you see three or more events sharing a naming prefix, that's a signal that parameterization would serve the implementation better.

The underlying insight: proliferation is a hedging mechanism where people create disposable events instead of future-proof ones because the upfront planning required for parameterized events feels expensive. But the technical debt compounds — you can start to use analytics data for real decision-making when it's organized into clean, consistent buckets, not when every interaction variation gets its own event name.

Parameter hygiene across GA4 events

Parameters are where GA4's flexibility becomes a liability if there's no governance. The naming is up to you, the structure is up to you, and without conventions, implementations accumulate parameter debt that undermines reporting quality.

Excessive parameters per event. GA4 allows 25 custom parameters per event, and beyond that, parameters are silently dropped. The issue emerges in implementations that treat every available data point as something to capture, sending 30+ parameters on key events without prioritizing which ones actually answer business questions — the first 25 arrive and the rest disappear.

PII in parameter names and values. Parameters with names like email, phone_number, user_email, or customer_name suggest that personally identifiable information is being sent to GA4. Google's terms explicitly prohibit PII in analytics data, and the risk extends beyond policy violation: PII in analytics creates compliance exposure under GDPR, CCPA, and similar regulations. Even parameter names that imply PII (like email_domain or phone_prefix) warrant review to confirm they don't contain identifying information.

Reserved parameter prefixes. Parameter names starting with google_, ga_, or firebase_ are reserved by GA4, and using them doesn't generate an error in GTM — the event sends, but GA4 ignores the parameter, which means the data appears to be collecting but never arrives in reports or BigQuery exports.

Casing inconsistency across events. When one event sends product_category and another sends Product_Category, GA4 treats these as different parameters. Registering one as a custom dimension doesn't capture data from the other, and this fragmentation is invisible until someone tries to build a cross-event report and finds that the parameter they registered only captures data from half their events.

Hardcoded parameter values. Parameters that always send the same value (like country: 'US' or language: 'en' hardcoded in GTM rather than read from the data layer) don't break anything, but they defeat the purpose of the parameter. If the value never varies, either it should be dynamic (reading the actual country or language from the page) or it shouldn't be a parameter at all.

Ecommerce tracking findings

Ecommerce tracking is a subset of GA4 data quality, but the failure modes are distinct enough and the business impact high enough to warrant separate treatment. Five rules cover the most common ecommerce problems.

Missing required parameters on purchase events. The purchase event requires transaction_id, value, and currency, and without all three, GA4 records the event but doesn't calculate revenue. This is the single most common cause of $0 revenue in GA4 ecommerce reports — currency is the parameter most often missing because it was optional in Universal Analytics and many migration implementations didn't add it.

Separate ecommerce tags instead of parameterized events. Some implementations create separate GA4 event tags for each ecommerce step: one tag for view_item, one for add_to_cart, one for purchase. This works but creates maintenance overhead, especially when the ecommerce data layer push already includes the event name. A single GA4 event tag triggered by ecommerce data layer events is cleaner and less prone to configuration drift across multiple tags.

Purchase event on the wrong trigger type. A GA4 purchase tag triggered by Page View or DOM Ready instead of a Custom Event trigger fires before the data layer contains ecommerce data, so the event sends with empty or partial parameters. The fix is a Custom Event trigger matching the data layer push event name, ensuring the tag fires only after the ecommerce data is available.

The ecommerce data toggle. GA4 property settings include an ecommerce reporting toggle that must be enabled for revenue data to appear in the monetization reports. Data collection isn't affected — the events still fire and the data reaches GA4 — but with the toggle off, the ecommerce reports remain empty regardless of implementation quality.

Incomplete funnel coverage. GA4's ecommerce specification defines events for view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, and purchase, and many implementations only track the first and last steps, eliminating the funnel analysis that would show where customers drop off. This doesn't cause incorrect data, but it eliminates the diagnostic capability that makes ecommerce analytics actionable.

Ecommerce tools deployed through Custom HTML

Third-party ecommerce tools like Klaviyo, Segment, and Braze sometimes get deployed through GTM's Custom HTML tag type instead of through their official GTM templates or server-side integrations, and this creates two problems.

First, Custom HTML tags bypass GTM's built-in consent framework. When you use a vendor's official GTM template and configure consent settings on it, GTM respects the visitor's consent choice before firing the tag, but Custom HTML tags can include consent-checking JavaScript where the consent integration is manual and often incomplete — the tag fires, sends data, and the consent banner's choices have no effect on it.

Second, Custom HTML execution carries performance and security implications that template-based tags avoid. GTM templates run in a sandboxed environment, while Custom HTML executes arbitrary JavaScript in the main browser thread, which means that for ecommerce tools that process transaction data, PII and payment-related information flows through unsandboxed code, creating a larger attack surface than necessary.

The audit finding isn't that these tools are present — it's that they're deployed in a way that sidesteps consent governance and security controls. The fix is typically migrating from Custom HTML to the vendor's official GTM template (most major ecommerce tools have one) or moving to a server-side implementation where data processing happens outside the browser entirely.

Configuration findings that affect GA4 data quality

Several container-level configurations affect GA4 data quality without being tied to a specific event or parameter.

Debug mode left enabled in production. GTM's debug mode sends additional data to GA4 DebugView, which is useful during development but creates noise in production. When debug mode is hardcoded to true in a GA4 configuration tag instead of being controlled by a variable that activates only during testing, every visitor's events appear in DebugView, polluting the debugging environment and adding minor overhead to every event.

Measurement ID hardcoded in tags. When multiple GA4 event tags each contain a hardcoded measurement ID instead of referencing a shared GTM variable, changing the measurement ID requires editing every tag individually. This is a maintenance problem more than a data quality problem, but it creates risk: when a measurement ID changes (property migration, testing property vs production), missing one tag means partial data collection.

Custom HTML implementing gtag.js directly. Some implementations use Custom HTML tags to call gtag() directly instead of using GA4's native GTM tag templates, which bypasses GTM's consent integration, measurement protocol handling, and parameter validation. The data reaches GA4 but through a path that doesn't benefit from GTM's built-in safeguards.

Duplicate event names across tags. Two or more GA4 event tags sending the same event name creates double-counting — if two tags both fire a page_view event, GA4 records two page views per actual page view. This inflates metrics across all reports and is especially problematic for events marked as key events (conversions), where double-counting directly affects ad optimization and attribution.

Events not configured for once-per-load firing. Certain events should only fire once per page load (like page_view or purchase), but without explicit trigger configuration limiting them to a single fire, they can fire multiple times if the trigger conditions are met repeatedly during a session. For purchase events specifically, this means a single transaction can generate multiple purchase events, inflating both transaction counts and revenue.

Prioritizing GA4 data quality fixes

A container with findings across multiple GA4 categories can feel overwhelming, but not all findings carry equal weight. The prioritization follows the same effort-based framework used across the entire audit: start with what has the most impact for the least effort.

The first three affect data accuracy for decisions being made right now — missing ecommerce parameters mean revenue is underreported, PII in parameters means compliance risk is active, and duplicate events mean conversion counts are inflated. These are worth fixing immediately.

Event naming conventions and proliferation cleanup are important but lower urgency because they affect reporting convenience and long-term maintainability rather than current data accuracy. A container with inconsistent event names still collects data correctly; it's just harder to work with, and cleaning up naming is a maintenance investment that pays off over months rather than a fix for something that's currently broken.

The full ecommerce funnel implementation is the highest-effort item but also the one that enables the most valuable analysis. Without intermediate funnel events, you can see that people view products and some of them purchase, but you can't see where the rest drop off. Implementing the complete funnel is a project rather than a quick fix, and it requires developer involvement to add data layer pushes at each checkout step.

TagManifest checks all 24 GA4 and ecommerce rules described in this piece. Upload your container JSON export and the scan maps every event tag against naming conventions, parameter architecture, ecommerce requirements, and configuration settings. The event model foundations piece explains the architectural thinking behind these rules, and the ecommerce spec covers the parameter requirements in detail if you're fixing ecommerce-specific findings.