What 250+ GA4 Audits Found:
Patterns in Almost Every Property

GA4's default event data retention period is 2 months. Almost nobody changes it. Almost nobody realizes they should. The setting is buried in Admin → Data Settings → Data Retention, and its consequences aren't immediately visible — your standard reports work fine with 2-month retention. The limitation only appears when you try to analyze longer trends in Explore, compare year-over-year periods, or model attribution across long buying cycles.

For any business with a decision cycle longer than 60 days — which includes most B2B companies, high-consideration purchases, and services requiring proposals or approvals — the 2-month default is actively truncating the data that shows how people actually buy. Early-funnel sessions that precede conversion by 3+ months simply disappear from Explore before you can analyze them.

Why it stays broken: changing data retention doesn't affect standard GA4 reports (which use a separate aggregated storage system). So the property "works" even with 2-month retention, and there's no visible error or warning that data is being deleted.

GA4 has a two-step process for filtering internal traffic: define which IPs are "internal" in the data stream settings, then create an active Data Filter that actually excludes them. Both steps are required. The IP definition alone does nothing.

Most properties that have attempted to set this up have completed only step one. The Data Filter either was never created, exists in "Testing" status but was never activated, or was set up correctly but later accidentally deactivated during a property change.

The impact varies by company. For a remote company with no fixed office IPs, internal traffic filtering matters primarily during site launches when developers are testing. For agencies testing client sites, or companies with large co-located teams, internal traffic can represent a consistent background rate of false conversions and engagement signals.

The particularly insidious case: internal test form submissions and test purchases appear as direct traffic (no campaign attribution), which inflates the "Direct" channel's apparent contribution and makes paid channels look comparatively less effective.

GA4's enhanced measurement fires form_submit when a form's submit event is triggered in the browser — regardless of whether the submission succeeded, passed validation, or created an actual lead. Clicking Submit on a form with invalid data and seeing a validation error still fires the event.

When form_submit is marked as a conversion (which it often is, since it's the most obvious "form" event available), every failed submission becomes a reported conversion. On forms with field validation, this typically inflates conversion counts by 20–40%. On forms with weak validation, the inflation can be much higher.

The additional problem: form_submit also fires on newsletter signup widgets, site search forms, and filter/sort dropdowns on product listing pages — not just lead generation forms. Properties that marked form_submit as a conversion often have significant conversion noise from these non-lead interactions.

When GA4 conversions are imported into Google Ads, those conversions should replace the native Google Ads conversion tag — not supplement it. When both sources remain active, every conversion is reported twice: once from the GA4 import, once from the native tag.

This configuration emerges most often in accounts with long histories or multiple people who've touched the setup. A developer adds the Google Ads conversion tag via GTM during initial launch. Later, an analytics team member sets up GA4 and imports conversions, assuming this replaces the old setup. The old tag is never removed. Both run quietly in parallel for months or years.

The bidding consequence: Smart Bidding in Google Ads uses conversion signals to calibrate bids. Doubled conversion signals produce bids calibrated to a cost-per-acquisition that's half the real number. The algorithm thinks campaigns are more efficient than they are, which affects how it competes in auctions and allocates budget.

The tell: in Google Ads, go to Goals → Conversions → Summary. Look for conversion actions where the same conversion behavior appears twice — once with source "Google Analytics 4" and once with source "Website." That's the duplication pattern.

"Unassigned" in GA4 channel reporting means the session arrived with UTM parameters, but GA4 couldn't match them to any of its default channel definitions. This is usually a UTM syntax problem: using utm_medium=email maps to the Email channel; using utm_medium=Email (capital E) or utm_medium=newsletter does not — it becomes Unassigned.

Common sources of Unassigned traffic in audited properties:

• Email campaigns using non-standard medium values (e-mail, newsletter, email_blast)
• Social campaigns using medium values other than social (social_media, sponsored, paid_social with no matching channel rule)
• Paid campaigns with misspelled medium values (cpc works; ppc, paid-search, paid search do not match default rules)
• Affiliate traffic with custom medium values that no channel group rule covers

The reporting impact: Unassigned traffic moves volume from named channels into an unattributable bucket, making channel performance analysis unreliable and obscuring which channels are actually driving traffic and conversions.

GA4 allows 50 event-scoped and 25 user-scoped custom dimensions per property. These slots are a finite resource. When custom dimensions are registered in Admin but the corresponding event parameter isn't being sent — due to incomplete GTM implementation, a broken data layer, or scope mismatch — the slot is consumed but provides no value.

In audited properties, it's common to find 5–15 registered custom dimensions with zero or near-zero data in the past 90 days. These are typically relics of planned-but-unfinished implementations: someone registered the dimension in Admin in preparation for implementation work that was never completed, or was completed but later broke silently.

The compounding problem: wasted custom dimension slots mean there may not be room to implement genuinely valuable dimensions later. In properties already using 40+ of their 50 event-scoped slots, discovering that 8 of them are empty is both a data quality problem and a resource allocation problem.

How to check: In GA4, go to Admin → Custom Definitions and review each registered custom dimension. Then check an Explore report to see the last 90 days of data for each one. Any dimension with no data in 90 days should be investigated and either fixed or removed.

When a user clicks from your main site to a subdomain (shop.yourdomain.com) or a related domain (yourdomain-checkout.com), GA4 treats them as a new user from a new session by default. The referring domain is your own main site, so the new session is attributed to "referral" from yourself.

In audited properties with e-commerce checkout on a subdomain, this creates a consistent pattern: the checkout domain appears as a significant referral source in channel reporting, and conversions look like they came from "referral" rather than from the actual acquisition channel. The cross-session journey — ad click → browse → checkout → purchase — is broken into disconnected fragments.

Cross-domain tracking requires two separate configurations: adding the destination domain to the "List your domains" field in the data stream settings, and also adding the destination domain to the referral exclusion list. Missing either step produces different but equally problematic behavior.

Google Signals is a feature that uses Google account data to enable cross-device reporting and demographic dimensions (age, gender, interests). It's enabled by default in many GA4 properties because it's presented during initial setup as a straightforward enhancement.

For properties with modest traffic volumes — typically under 50,000 monthly sessions — Google Signals triggers data thresholding. GA4 removes rows from reports when enabling a dimension would reveal information about fewer than a threshold number of users. The result: demographic dimensions show "(threshold applied)" messages, and granular breakdowns of audience behavior become unavailable.

The less obvious consequence: thresholding applies not just to demographic reports but to any report where Signals data is being blended. Age, gender, and interests dimensions become unreliable. For lower-traffic properties, Google Signals costs more in report reliability than it provides in cross-device insights.

The appropriate action depends on your traffic level. Higher-traffic properties benefit from Signals. Lower-traffic properties often benefit more from disabling Signals and gaining clean, unthresholded reporting across all dimensions.

GA4's default conversion counting method is "once per event," which means if a conversion event fires multiple times in a single session, each instance is recorded as a separate conversion. For form-based conversions, this creates inflation through a common pattern: user submits form, lands on thank-you page (conversion 1), hits back button, navigates forward (conversion 2).

This is subtle because the inflation is inconsistent — it only affects users who navigate back from the thank-you page. The conversion count is always somewhat inflated, but the magnitude varies. The appropriate setting for virtually all form-based lead generation conversions is "once per session."

The exception: for e-commerce purchases, "once per event" can be appropriate when combined with correct transaction ID deduplication. If transaction IDs are passed correctly, GA4 deduplicates repeated page views of the same order confirmation. But if transaction IDs are missing or static, even e-commerce can be affected.

GA4's enhanced measurement automatically tracks seven categories of events: page views, scrolls, outbound clicks, site search, video engagement, file downloads, and form interactions. Each of these events appears in the Events table and can be marked as a conversion with one click.

In audited properties, it's common to find engagement events marked as conversions as a result of early experimentation or setup by someone who wasn't sure what should be a conversion and marked several things to "see how they perform." file_download as a conversion, scroll at 90% as a conversion, and video_complete as a conversion are frequently found in this way.

The consequence: conversion volume is inflated by engagement signals that don't represent business outcomes. Worse, these engagement conversions get imported into Google Ads if the import is set to include all GA4 conversions, influencing Smart Bidding to optimize for engagement rather than actual business results.

How to check: Admin → Conversions. For each marked conversion, ask: does this event represent a real business outcome, or is it an engagement indicator? Engagement indicators (scrolls, video views, PDF downloads) should be removed from the conversion list and tracked as events only.