GA4 Audit documentation

This document provides explanations and troubleshooting steps for the audit checks performed by the GA4 Audit tool.

Privacy policy

🔒 Your GA4 data stays in your Google account. We don’t see it, store it, or share it—ever.

To learn more about our privacy policy, click here.

GA4 audit help: UTM parameter checks

Inverted UTMs check

What it checks: Looks for instances where utm_source and utm_medium values seem swapped (e.g., utm_source=cpc, utm_medium=google). It ignores (not set) values.
Why it matters: Incorrect source and medium values lead to traffic being misclassified in your GA4 channel reports, making channel performance analysis unreliable.
Interpreting results:

Pass: No obvious swaps detected.
Warn: Potential swaps found. Check the ‘Details’ column for examples.

Review the examples in the ‘Details’ column.
Examine the campaign URLs associated with the flagged source/medium pairs.
Correct the utm_source (the specific site or platform, e.g., google, facebook, newsletter_spring) and utm_medium (the marketing channel, e.g., cpc, social, email) values in your campaign links or URL builder tool. Ensure they logically represent the origin and channel.

UTM formatting check

What it checks: Scans page URLs to see if UTM parameters (utm_...) appear before the question mark (?) or are incorrectly attached to the path (e.g., /pageutm_source=google). It only checks URLs that have UTMs present.
Why it matters: GA4 relies on the standard URL structure where query parameters follow a ?. If UTMs are part of the path, GA4 will likely not recognize them, leading to traffic being misattributed (often as 'Direct' or 'Unassigned').
Interpreting results:

Pass: UTM parameters appear correctly placed after a ?.
Warn: Found URLs where UTMs might be part of the path. Check ‘Details’ for examples.

Examine the example URLs listed in the ‘Details’ column.
Locate where these URLs are generated (e.g., in ad platforms, email marketing tools, social media posts, URL builders).
Ensure the tool or process correctly appends UTM parameters starting with a ? (for the first parameter) and separated by & (for subsequent parameters). Example: https://www.example.com/page?utm_source=google&utm_medium=cpc

UTMs unusual length check

What it checks: Identifies utm_source or utm_medium values that are longer than 30 characters. It ignores (not set) values.
Why it matters: Overly long UTM values can be hard to read in reports and might indicate unstructured or automatically generated values that aren't useful for analysis. While GA4 might not truncate them, keeping them concise is best practice.
Interpreting results:

Pass: All utm_source and utm_medium values are 30 characters or less.
Warn: Found some values > 30 characters, affecting < 10% of relevant sessions.
Fail: Found values > 30 characters, affecting ≥ 10% of relevant sessions.

Review the examples in the ‘Details’ column.
Identify the campaigns or sources generating the long values.
Shorten the utm_source and utm_medium values in your URL builder or campaign setup, adhering to your team’s naming conventions. Aim for clear, concise, and standardized values.

UTM repetition check

What it checks: Looks for cases where the utm_source value is repeated within the utm_medium value (e.g., utm_source=facebook, utm_medium=facebook_social). It ignores (not set) values and is case-insensitive.
Why it matters: This often indicates redundancy. utm_medium should define the channel type (e.g., social, cpc, email), not just repeat the source. It makes channel grouping less effective.
Interpreting results:

Pass: No significant repetition found.
Warn: Repetition found, affecting < 10% of relevant sessions.
Fail: Repetition found, affecting ≥ 10% of relevant sessions.

Review the examples in ‘Details’.
Adjust your campaign tagging strategy. Ensure utm_medium clearly represents the marketing channel (e.g., cpc, display, social, email, affiliate) and doesn’t just repeat the source information.

UTM source missing check

What it checks: Identifies sessions where utm_source is (not set) but utm_medium OR utm_campaign has a value.
Why it matters: utm_source is a required parameter for proper attribution. Missing it while others are present means GA4 doesn't know the origin of the traffic, leading to incomplete reporting.
Interpreting results:

Pass: Less than 1% of relevant sessions are affected.
Warn: 1-2% of relevant sessions are affected.
Fail: More than 2% of relevant sessions are affected.

Review the examples in ‘Details’ (showing the medium/campaign found).
Identify the campaigns or links missing the utm_source parameter.
Ensure all tagged URLs include a valid utm_source value. Update your URL builder templates or campaign setup processes.

UTM campaign missing check

What it checks: Identifies sessions where utm_campaign is (not set) but utm_source OR utm_medium has a value.
Why it matters: While technically optional, utm_campaign is crucial for differentiating specific marketing efforts (e.g., "spring_sale", "product_launch_promo"). Missing it makes it hard to compare the performance of different initiatives within the same source/medium.
Interpreting results:

Pass: Less than 1% of relevant sessions are affected.
Warn: 1-2% of relevant sessions are affected.
Fail: More than 2% of relevant sessions are affected.

Review the examples in ‘Details’ (showing the source/medium found).
Identify the traffic sources/mediums missing the utm_campaign parameter.
Update your URL tagging process to consistently include a descriptive utm_campaign value for all marketing links.

UTM medium missing check

What it checks: Identifies sessions where utm_medium is (not set) but utm_source OR utm_campaign has a value.
Why it matters: utm_medium is a required parameter for GA4's default channel grouping. Missing it means traffic won't be correctly assigned to channels like Paid Search, Organic Social, Email, etc., often falling into 'Unassigned'.
Interpreting results:

Pass: Less than 1% of relevant sessions are affected.
Warn: 1-2% of relevant sessions are affected.
Fail: More than 2% of relevant sessions are affected.

Review the examples in ‘Details’ (showing the source/campaign found).
Identify the campaigns or links missing the utm_medium parameter.
Ensure all tagged URLs include a valid utm_medium value (e.g., cpc, email, social, affiliate, display). Update your URL builder templates or campaign setup processes. Use standard medium values recognised by GA4 where possible.

Source & medium missing check

What it checks: Identifies sessions where both utm_source and utm_medium are (not set). This often corresponds to 'Direct' or 'Unassigned' traffic but specifically flags sessions where GA4 couldn't determine either parameter.
Why it matters: A high volume here can indicate significant tracking problems, such as lost referrer information, broken redirects, missing tags on marketing links, or issues with cross-domain tracking.
Interpreting results:

Pass: Less than 0.5% of total sessions are affected.
Warn: 0.5% – 2% of total sessions are affected.
Fail: More than 2% of total sessions are affected.

This often requires broader investigation beyond just UTMs.
Ensure all marketing links (emails, social posts, ads, affiliates) are consistently tagged with utm_source and utm_medium.
Investigate potential self-referral issues (see Referrals audit).
Verify cross-domain tracking is set up correctly if users navigate between multiple domains you own.
Check for technical issues like redirects that might strip referrer data.

UTM source mixed case check

What it checks: Detects if the same utm_source value appears with different capitalization (e.g., google vs. Google vs. GOOGLE). It ignores (not set).
Why it matters: GA4 treats values with different cases as distinct sources. This splits your data, making it harder to see the total performance for a single source (e.g., all Google traffic).
Interpreting results:

Pass: No mixed-case variations found for any source.
Warn: Found at least one source with mixed-case variations. Check ‘Details’ for examples.

Review the examples in ‘Details’ showing the different casings found for the same conceptual source.
Establish a consistent casing convention for all UTM parameters (lowercase is highly recommended).
Update all your URL builders, campaign setups, and documentation to enforce the chosen convention (e.g., always use google, never Google).

UTM medium duplicates check

What it checks: Looks for different utm_medium values that likely represent the same channel, considering case variations (e.g., cpc vs. CPC) or common synonyms (though this check primarily focuses on case). It ignores (not set).
Why it matters: Inconsistent utm_medium values split your data across multiple channel definitions in GA4, preventing accurate analysis of overall channel performance (e.g., total Paid Search traffic).
Interpreting results:

Pass: No significant inconsistencies or duplicates found.
Warn: Found different values likely representing the same medium (primarily case differences). Check ‘Details’ for examples.

Review the examples in ‘Details’ (e.g., ‘cpc’ vs ‘CPC’).
Establish standardized utm_medium values for each marketing channel. Use GA4’s recognized values where possible (e.g., cpc, organic, social, email, affiliate, referral, display).
Update all URL builders, campaign setups, and documentation to use only the standardized medium values consistently (lowercase recommended).

GA4 audit help: custom definitions checks

Custom Definitions Sheet

Event scoped custom dimensions check

What it checks:Compares the number of active event-scoped custom dimensions in your property against the GA4 limit (currently 50 per property).
Why it matters: Exceeding the limit prevents you from creating new event-scoped custom dimensions. High usage suggests you might be creating redundant dimensions or using them inefficiently. Event-scoped dimensions are registered based on event parameters.
Interpreting results:

Pass: Using less than 80% of the limit (fewer than 40).
Warn: Using 80-99% of the limit (40-49). You are close to the limit.
Fail: Using 100% or more of the limit (50+). You cannot create more.

Review existing dimensions: Go to GA4 Property > Admin > Custom Definitions > Custom Dimensions. Filter by “Scope = Event”.
Identify unused/redundant dimensions: Look for dimensions that are no longer needed, were created for testing, or capture similar information redundantly. Check the “Events used in” count (though this might not be perfectly accurate immediately after creation/archiving).
Archive unnecessary dimensions: Select the dimensions you don’t need and click “Archive”. Archived dimensions don’t count towards the limit but cannot be easily unarchived (you’d need to recreate them). Be certain before archiving.
Consolidate: Can multiple existing dimensions be replaced by one dimension with more general applicability? For example, instead of button_color and link_color, maybe just element_color?
Plan carefully: Before creating new event-scoped dimensions, ensure they are truly necessary and distinct from existing ones.

Event scoped custom metrics check

What it checks: Compares the number of active event-scoped custom metrics in your property against the GA4 limit (currently 50 per property).
Why it matters: Exceeding the limit prevents you from creating new event-scoped custom metrics. These metrics allow you to analyze numerical values sent with your events (e.g., video watch time, form field count).
Interpreting results:

Pass: Using less than 80% of the limit (fewer than 40).
Warn: Using 80-99% of the limit (40-49). You are close to the limit.
Fail: Using 100% or more of the limit (50+). You cannot create more.

Review existing metrics: Go to GA4 Property > Admin > Custom Definitions > Custom Metrics.
Identify unused/redundant metrics: Look for metrics that are no longer relevant, were for testing, or duplicate existing metrics.
Archive unnecessary metrics: Select the metrics you don’t need and click “Archive”. Archived metrics free up space but cannot be easily restored.
Plan carefully: Ensure new custom metrics provide unique analytical value before creating them.

User scoped custom dimensions check

What it checks: Compares the number of active user-scoped custom dimensions in your property against the GA4 limit (currently 25 per property).
Why it matters: Exceeding the limit prevents you from creating new user-scoped custom dimensions. These dimensions describe segments of your users (e.g., customer_tier, logged_in_status).
Interpreting results:

Pass: Using less than 80% of the limit (fewer than 20).
Warn: Using 80-99% of the limit (20-24). You are close to the limit.
Fail: Using 100% or more of the limit (25+). You cannot create more.

Review existing dimensions: Go to GA4 Property > Admin > Custom Definitions > Custom Dimensions. Filter by “Scope = User”.
Identify unused/redundant dimensions: Look for dimensions describing user attributes that are no longer relevant, were for testing, or capture overlapping information.
Archive unnecessary dimensions: Select the dimensions you don’t need and click “Archive”. Be certain before archiving.
Consolidate: Can multiple user properties be combined logically?
Plan carefully: User-scoped dimensions are valuable but limited. Prioritize the most important user attributes for segmentation and analysis before creating new ones.

GA4 audit help: data validity checks

Data Validity Sheet

Mixed case events check

What it checks: Looks for the same event name being recorded with different capitalization (e.g., button_click vs. Button_Click).
Why it matters: GA4 treats event names with different cases as separate events. This fragments your data, making it difficult to analyze the total count for a single intended event.
Interpreting results:

Pass: No mixed-case event names detected.
Warn: Found event groups with mixed casing, but the total count for each group is 10 or less.
Fail: Found event groups with mixed casing where at least one group has a total count greater than 10.

Review the ‘Details’ column to see which event names have inconsistent casing (e.g., ‘Login’ vs. ‘login’).
Establish a consistent naming convention for all events (lowercase with underscores, like event_name, is highly recommended).
Update your website/app code (GTM tags, dataLayer pushes, gtag calls) to send event names using only the standardized casing.
Communicate the naming convention to your development team

Mixed case URLs check

What it checks: Looks for the same page URL (including path and query string) being recorded with different capitalization (e.g., /path/Page?id=A vs. /path/page?id=a).
Why it matters: Like event names, GA4 treats URLs with different cases as distinct pages. This splits pageview data across multiple rows in reports, making it hard to analyze the true performance of a single page. It can also sometimes indicate server configuration issues.
Interpreting results:

Pass: No mixed-case URLs detected.
Warn: Found URL groups with mixed casing, but the total pageviews for each group is 10 or less.
Fail: Found URL groups with mixed casing where at least one group has total pageviews greater than 10.

Review the ‘Details’ column to identify URLs with inconsistent casing.
Server-side fix (recommended): Configure your web server (e.g., Apache .htaccess, Nginx config) to automatically redirect all incoming URLs to a consistent case (usually lowercase) using a 301 redirect. This is the most robust solution.
Application-level fix: Ensure your website’s internal linking, canonical tags, and sitemaps all use the consistent, standardized URL case.
Campaign URL fix: Ensure marketing campaign destination URLs also use the standardized case.

Page cardinality check

What it checks: Counts how many different query parameter names (e.g., id, type, filter) are used with the same base page path (e.g., /products/widget) across your collected data.
Why it matters: Too many unique parameter names for the same page (high cardinality) can cause GA4 to group data into an "(other)" row in reports, hiding details and making analysis difficult. It can sometimes signal underlying URL structure or tracking issues.
Interpreting results:

Pass: Good URL structure; fewer than 11 unique parameter names per base page path.
Warn: Potential issue; at least one base path has 11-20 unique parameter names. Check the ‘Details’ column.
Fail: Likely reporting impact; at least one base path has over 20 unique parameter names. Check the ‘Details’ column.

Analyze flagged URLs: Use the ‘Details’ column in the sheet to see the specific URLs and the list of unique parameters found. Identify parameters that seem unnecessary for analysis in GA4 (e.g., session IDs, unique user tokens, redundant filters, internal tracking codes).
Exclude parameters in GA4 admin: For parameters not needed for GA4 reporting:
- Navigate to: GA4 Property > Admin > Data Settings > Data Collection.
- Click Show more under URL Query Parameter Exclusions.
- Enter the parameter names you want GA4 to ignore (e.g., sessionid, usertoken, filter_id). Note: Excluding id means GA4 treats /page?id=1 and /page?id=2 as the same page in reports.
- Important: Do NOT exclude utm_ parameters or any parameters needed to differentiate page content, functionality, or traffic sources within your GA4 analysis.
- Reference: Google Help: Exclude URL Query Parameters
Review website code/CMS: If problematic parameters (especially non-standard ones like PHPSESSID or custom IDs) are present, investigate your website’s code, CMS, or third-party plugins. Modify the configuration or code to prevent these parameters from being appended to URLs sent to GA4.

GA4 audit help: referral checks

Referrals Sheet

Self referrals check

What it checks: Identifies sessions attributed to the 'referral' medium where the referring source domain is your own website's domain (or subdomain). Requires Website Domain to be set in Configuration.
Why it matters: When your own site appears as a referrer, it usually indicates a break in the user's session tracking. This often happens due to missing or incorrect cross-domain tracking, payment gateway redirects that don't return properly, or overly aggressive session timeouts. Self-referrals inflate session counts and distort the true origin of your traffic.
Interpreting results:

Pass: Less than 1% of total sessions are self-referrals.
Warn: 1-5% of total sessions are self-referrals.
Fail: More than 5% of total sessions are self-referrals.

Add domain to referral exclusion list: This is the primary fix. Go to GA4 Property > Admin > Data Streams > [Select your Web Stream] > Configure tag settings > Show more > List unwanted referrals. Add your own domain (e.g., example.com) and any relevant subdomains (e.g., shop.example.com, blog.example.com). Reference: Google Help: Identify unwanted referrals
Check cross-domain tracking: If users navigate between different domains you own (e.g., main site to a separate booking engine), ensure cross-domain tracking is correctly configured in your GA4 tag settings.
Review payment gateway redirects: Ensure users returning from third-party payment gateways are correctly returned without triggering a new session or losing the original source. The payment domain should often be added to the referral exclusion list.
Check session timeout settings: Ensure the session timeout (Admin > Data Streams > [Web Stream] > Configure tag settings > Show more > Adjust session timeout) is appropriate for your site’s user behaviour (default is 30 minutes).

Suspicious self referrals check

What it checks: Identifies referral traffic where the source domain contains your website's name but isn't your actual domain or a standard subdomain (e.g., if your site is example.com, it flags example.xyz or translate.googleusercontent.com/translate_c?...&u=https://example.com). Requires Website Domain to be set in Configuration.
Why it matters: These can indicate several things:

Third-party tools or services embedding your content (like translation services, caching services).
Potential brand spoofing or scraper sites.
Misconfigured tracking on related (but distinct) domains.

Pass: Less than 0.5% of total sessions are suspicious self-referrals.
Warn: 0.5% – 2% of total sessions are suspicious self-referrals.
Fail: More than 2% of total sessions are suspicious self-referrals.

Review the sources listed in the ‘Details’ column.
Identify legitimate sources: Determine if sources like translation services (googleusercontent.com), web archives, or known third-party platforms integrating your content are expected. If legitimate and causing issues, add the specific referring domain (e.g., googleusercontent.com) to your Referral Exclusion List (see Self-Referrals fix #1).
Investigate unknown sources: Research unfamiliar domains. They might be spam (see Spam Referrals check) or indicate other issues.
Check tracking: Ensure tracking isn’t accidentally implemented on domains that merely mention your brand.

Spam referrals check

What it checks: Identifies referral traffic coming from domains known for sending fake or "ghost" referral spam. It checks against a list maintained in the 'SpamReferralDomains' sheet within your spreadsheet.
Why it matters: Spam referrals are not real visitors. They inflate your traffic metrics, skew engagement rates (often 100% bounce rate), and pollute your reports with irrelevant data, making genuine performance analysis harder.
Interpreting results:

Pass: Less than 1% of total sessions come from known spam domains.
Warn: 1-5% of total sessions come from known spam domains.
Fail: More than 5% of total sessions come from known spam domains.

Update spam list: Regularly review the ‘SpamReferralDomains’ sheet. Add any new spam domains you identify from your GA4 reports (Acquisition > Traffic acquisition > filter by Medium = referral, look for suspicious sources with high bounce/low engagement).
GA4 traffic filtering (recommended for future data): While GA4 automatically filters some known bots/spam, you can create Data Filters to exclude traffic based on hostname or other dimensions if spam is persistent and identifiable by patterns beyond just the referrer. Go to Admin > Data Settings > Data Filters. Note: Data filters are destructive and apply going forward.
Segment historical data: For analyzing past data, create segments in GA4 Explorations or Looker Studio to exclude sessions where Session source matches known spam domains.

Missing referrers check

What it checks: Identifies sessions where the sessionMedium is 'referral' but the sessionSource is (not set) or blank.
Why it matters: When traffic is identified as a referral (meaning it came from another site), but the specific referring site (source) is missing, you lose valuable information about where your traffic originates. This can happen due to technical reasons like security policies (e.g., HTTPS to HTTP transitions), browser limitations, or redirects stripping referrer information.
Interpreting results:

Pass: Less than 1% of total sessions are referrals with missing sources.
Warn: 1-5% of total sessions are referrals with missing sources.
Fail: More than 5% of total sessions are referrals with missing sources.

Ensure HTTPS: Make sure your entire website uses HTTPS. Transitions from secure (HTTPS) referrers to non-secure (HTTP) pages on your site often cause the referrer to be dropped.
Review redirects: Check if any internal or external redirects involved in user journeys might be configured in a way that strips referrer data.
Check rel=”noreferrer”: Examine links pointing to your site from partners or your other properties. If they use rel=”noreferrer”, the referrer information will be intentionally withheld. Ask partners to remove it if appropriate.
Understand limitations: Some referrer loss is unavoidable due to browser privacy settings or specific app behaviors. Focus on fixing technical issues within your control (HTTPS, redirects).

GA4 audit help: sanity checks

Sanity Check Sheet

(not set) landing pages check

What it checks: Identifies sessions where the landingPage dimension is recorded as (not set).
Why it matters: Every session originating from a page view should have a landing page recorded. (not set) indicates that GA4 couldn't determine the first page viewed in the session, often due to tracking implementation issues (e.g., events firing before the first page_view), session timeouts, or complex filtering. This obscures where users are actually entering your site.
Interpreting results:

Pass: Less than 1% of total sessions have (not set) landing pages.
Warn: 1% or more of total sessions have (not set) landing pages. (Threshold adjusted based on code logic).
Fail: More than 1% of total sessions have (not set) landing pages. (Threshold adjusted based on code logic – Fail effectively triggers at the same point as Warn in the provided code).

Verify base tag placement: Ensure your GA4 configuration tag (gtag.js or GTM base tag) fires correctly on all pages before any other GA4 events.
Check for delayed pageviews: Ensure the page_view event isn’t significantly delayed by scripts or consent mechanisms, potentially allowing other events to start the session first.
Review session timeout: A very short session timeout could contribute if users return quickly after inactivity. Check Admin > Data Streams > [Web Stream] > Configure tag settings > Show more > Adjust session timeout.
Analyze filters: Check if any GA4 Data Filters or GTM triggers might be excluding initial pageviews under certain conditions.
Examine event timing: Use browser developer tools (Network tab) or GTM Preview mode to see the exact sequence of GA4 hits when a session starts.

Dubious landing pages check

What it checks: Identifies sessions where the traffic source is (direct) or (not set), but the landing page is a "deep" page (typically more than 2 levels deep in the URL path, e.g., /category/product/details) rather than the homepage or a common top-level page (like /blog, /contact).
Why it matters: While users can bookmark deep pages or type them directly, a high volume of direct traffic landing on deep, obscure pages often indicates that the actual referrer information (e.g., from email, social, or another site) was lost during the user's journey to your site. This leads to misattribution.
Interpreting results:

Pass: Less than 0.2% of total sessions are affected.
Warn: 0.2% – 1% of total sessions are affected.
Fail: More than 1% of total sessions are affected.

Review tagging: Ensure all marketing links (email, social, ads, QR codes) are consistently tagged with UTM parameters (utm_source, utm_medium, utm_campaign). This is the most common cause.
Check redirects: Ensure server-side or client-side redirects aren’t stripping referrer data before the user lands on the final page.
Verify cross-domain tracking: If users arrive from another domain you own, ensure cross-domain tracking is working correctly.
Analyze specific pages: Look at the landing pages listed in ‘Details’. Are they pages linked heavily from untagged emails or social posts?

Unassigned traffic check

What it checks: Identifies sessions where the sessionSource dimension is (not set) or blank.
Why it matters: All traffic should ideally have a source attributed. "Unassigned" traffic often results from missing or improperly formatted UTM parameters, issues with Google Ads auto-tagging linkage, or problems capturing referrer data. It represents a gap in understanding where your users come from.
Interpreting results:

Pass: Less than 1% of total sessions are unassigned.
Warn: 1-3% of total sessions are unassigned.
Fail: More than 3% of total sessions are unassigned.

tagging: Ensure comprehensive and correct UTM tagging across all campaigns (email, social, custom campaigns). Check for missing utm_source or utm_medium.
Check Google Ads linking & auto-tagging: Verify your Google Ads account is linked to GA4 (Admin > Product Links > Google Ads Links) and that auto-tagging is enabled in Google Ads. Ensure cost data is importing.
Investigate referrer issues: See fixes for “Missing Referrers” check in the Referrals audit.
Check consent management: Ensure your consent platform isn’t blocking analytics tags before source information can be captured.

Direct traffic check

What it checks: Measures the percentage of total sessions attributed to the (direct) source. Direct traffic includes users who typed your URL, used a bookmark, or arrived via a channel where the referrer was lost or unavailable.
Why it matters: While some direct traffic is expected and healthy (brand recognition, bookmarks), an unusually high percentage often indicates problems elsewhere, such as:

Missing UTM tags on marketing links (causing them to appear direct).
Lost referrer data (HTTPS-to-HTTP issues, rel=”noreferrer”).
Traffic from non-web sources (like mobile apps) without proper tagging.

Pass: Direct traffic percentage is below the calculated threshold for your site’s traffic volume.
Warn: Direct traffic percentage exceeds the threshold (20% for <30k sessions, 15% for 30k-50k sessions, 10% for >50k sessions).

Improve UTM tagging: This is often the biggest lever. Ensure all inbound marketing links are tagged.
Ensure full site HTTPS: Prevent referrer loss from secure sites.
Check rel=”noreferrer”: Audit links pointing to your site.
Analyze landing pages: Look at the top landing pages for direct traffic. Are they pages typically bookmarked, or are they campaign-specific pages that should have UTMs?
Review dark social/app traffic: Understand how traffic from untaggable sources (messaging apps, some mobile apps) might be contributing.

Single hostname usage check

Spam/Ghost Traffic: Fake hits sent directly to GA4 servers.
Cross-Domain Tracking Issues: Data from other domains you own appearing incorrectly.
Third-Party Tools: Staging sites, translation services, or other tools sending data.
Implementation Errors: Your tracking code accidentally placed on another website.

Pass: Less than 0.2% of sessions come from unexpected hostnames.
Warn: 0.2% – 2% of sessions come from unexpected hostnames.
Fail: More than 2% of sessions come from unexpected hostnames.

Review unexpected hostnames: Look at the list in ‘Details’.
Filter spam hostnames: Create Data Filters (Admin > Data Settings > Data Filters) to Include only traffic from your valid hostname(s). This is the most effective way to block hostname spam going forward.
Exclude legitimate third-party hostnames: If hostnames like translate.googleusercontent.com or known staging/tool domains appear and are legitimate but unwanted in reports, add them to your Referral Exclusion List (see Self-Referrals fix #1) – note this primarily affects referral attribution, filtering is better for hostname spam.
Verify tracking code placement: Ensure your GA4 code isn’t active on incorrect domains.

Suspicious engagement rates check

Very Low (<10%): Suggests users are leaving very quickly without interacting. This could be due to poor content relevance, slow load times, technical errors on the page, or misleading traffic sources.
Very High (>90%): While sometimes legitimate for highly engaging content, consistently near-100% rates can indicate tracking issues, such as the GA4 tag firing multiple times, sessions not ending correctly, or potentially bot traffic that triggers engagement metrics artificially.

Pass: No landing pages with significant traffic fall outside the 10%-90% engagement range.
Warn: Found landing pages outside the 10%-90% range, affecting < 5% of total sessions.
Fail: Found landing pages outside the 10%-90% range, affecting ≥ 5% of total sessions.

Analyze specific pages: Review the landing pages listed in ‘Details’.
For low engagement:

Check page load speed (using tools like PageSpeed Insights).
Review content relevance – does the page match user expectations from the traffic source?
Look for technical errors or poor user experience on the page.
Analyze the traffic sources leading to these low-engagement pages.

3. For high engagement:

Verify GA4 tag implementation – is it firing only once per page load? Use GTM Preview or browser developer tools.
Check session timeout settings – are they excessively long?
Investigate potential bot traffic patterns.
Ensure single-page applications (SPAs) are correctly configured to send virtual pageviews and manage session engagement.

GA4 audit help: ecommerce checks

Ecommerce Sheet

Note: All ecommerce checks (except the first one) are skipped if “Enable Ecommerce Audit” is not checked in the Configuration or if the “Transaction Count” check fails.

Transaction count check (gatekeeper)

What it checks: Verifies if any transaction events (like purchase, ecommerce_purchase, in_app_purchase) are being recorded in GA4 for the selected date range.
Why it matters: This is fundamental. Without transaction events, GA4 cannot report on revenue, purchases, or ecommerce conversion rates. It's the cornerstone of ecommerce tracking.
Interpreting results:

Pass: At least one transaction event was detected.
Fail: Zero transaction events were detected during the period.

Verify ecommerce tracking implementation: Ensure your ecommerce tracking code (e.g., data layer pushes for GTM, gtag event snippets) is correctly implemented on your purchase confirmation page or triggered upon successful transaction.
Check trigger conditions: If using GTM, ensure the trigger for your purchase event tag is firing correctly on the confirmation page/event. Use GTM Preview mode to debug.
Confirm event naming: Ensure you are using one of the standard GA4 recommended event names for purchases (e.g., purchase).
Check data layer structure: Verify that the ecommerce data layer object (especially the transaction_id and items array) is correctly formatted according to Google’s documentation. Use browser developer tools to inspect the dataLayer.
Review consent settings: Ensure consent settings aren’t preventing the purchase event tag from firing.

Funnel stages check

What it checks: Ensures that key standard ecommerce funnel events (view_item, add_to_cart, begin_checkout, purchase) are present in your data.
Why it matters: Missing stages create gaps in your funnel analysis, preventing you from understanding where users drop off in the buying journey.
Interpreting results:

Pass: All four key funnel events (view_item, add_to_cart, begin_checkout, purchase) were recorded during the period.
Fail: One or more of the key funnel events are completely missing from the data.

Identify the missing event(s) listed in ‘Details’.
Implement tracking for the missing events using the standard GA4 event names:

3. Ensure the data layer or event parameters for these events are correctly formatted, especially the items array.

Funnel order check

What it checks: Verifies if the counts for key funnel events follow the expected decreasing pattern: view_item ≥ add_to_cart ≥ begin_checkout ≥ purchase.
Why it matters: Deviations from this order strongly suggest tracking implementation errors. For example, having more add_to_cart events than view_item events is illogical and points to view_item tracking being missed or add_to_cart firing incorrectly.
Interpreting results:

Pass: Event counts follow the expected decreasing order.
Fail: The count for at least one funnel stage is higher than the preceding stage. The ‘Details’ will show the counts found.

Examine the counts in the ‘Details’ to see where the order breaks (e.g., add_to_cart > view_item).
Review tag implementation: Use GTM Preview or browser developer tools to meticulously check the triggers and firing conditions for each funnel event tag (view_item, add_to_cart, begin_checkout).
Check view_item: Ensure it fires reliably on all relevant product page views.
Check add_to_cart: Ensure it fires only once per add-to-cart action and not on page load or other unrelated actions.
Check begin_checkout: Ensure it fires only when the user initiates the checkout flow, not on every cart view or page load within the checkout.

Product category check

What it checks: Identifies purchased products (based on itemsViewed metric associated with itemCategory dimension - Note: Ideally this should use purchase data, but the code uses view data) that are missing a category classification (itemCategory parameter is (not set) or empty).
Why it matters: Product categories (item_category, item_category2, etc.) are vital for merchandising analysis, understanding product performance by group, and creating relevant segments. Missing categories limit reporting capabilities.
Interpreting results:

Pass: No products viewed are missing category data.
Warn: 1-10 product views are missing category data.
Fail: More than 10 product views are missing category data.

Review the example products listed in ‘Details’.
Identify where product data originates (e.g., product database, CMS, PIM).
Ensure the item_category (and other category levels like item_category2 if used) field is populated for all products in your source system.
Verify that your website code or GTM setup correctly pulls this category data and includes it in the items array for ecommerce events (especially view_item, add_to_cart, purchase). Check the data layer structure.

Product dimensions check

What it checks: Identifies purchased products (based on itemsViewed metric associated with itemName and itemId - Note: Ideally uses purchase data) where either the itemName or itemId is missing ((not set) or empty).
Why it matters: Both item_name and item_id are crucial for uniquely identifying products and analyzing their performance. Missing either leads to inconsistent data and reporting problems. item_id is often essential for joining GA4 data with external systems (like a CRM or inventory).
Interpreting results:

Pass: All viewed products have both itemName and itemId.
Warn: 1-10 product views are missing itemName or itemId.
Fail: More than 10 product views are missing itemName or itemId.

Review the ‘Details’ to see examples of products/transactions with missing dimensions.
Ensure both item_id and item_name are populated for all products in your source system (database, CMS, etc.).
Verify your website code or GTM setup correctly includes both item_id and item_name in the items array for all relevant ecommerce events (view_item, add_to_cart, purchase, etc.). Check the data layer structure.

Duplicate transaction IDs check

What it checks: Identifies if the same transaction_id is associated with more than one purchase-related event (purchase, ecommerce_purchase, etc.).
Why it matters: Each unique purchase should have a unique transaction_id. Duplicates usually mean the purchase event fired multiple times for the same order, leading to inflated revenue, transaction counts, and product quantities in GA4 reports.
Interpreting results:

Pass: No duplicate transaction_ids found.
Warn: 1-10 distinct transaction_ids were found associated with multiple purchase events.
Fail: More than 10 distinct transaction_ids were found associated with multiple purchase events.

Review confirmation page logic: Examine the code or GTM setup on your purchase confirmation page. Ensure the purchase event tag fires only once upon successful transaction completion.
Prevent refreshes/back button issues: Implement logic to prevent the purchase tag from firing again if the user refreshes the confirmation page or navigates back to it. Use techniques like server-side flags, browser session storage, or checking if the transaction ID has already been processed.
Check server-side tracking: If using Measurement Protocol for server-side purchase events, ensure your backend logic sends the event only once per transaction.
Debug with transaction IDs: Use the transaction IDs listed in ‘Details’ to investigate specific orders in your backend system and correlate them with GA4 data (using Explorations) to see when the multiple hits occurred.

Item name with multiple IDs check

What it checks: Looks for instances where the same item_name is associated with different item_id values across various ecommerce events.
Why it matters: This indicates inconsistency in your product data setup or tracking. A single product concept (represented by item_name) should consistently have the same item_id. Multiple IDs for the same name fragment product performance data, making it impossible to get an accurate picture of how that specific product is doing.
Interpreting results:

Pass: All item_name values consistently map to only one item_id.
Fail: Found at least one item_name associated with more than one item_id. ‘Details’ lists examples.

Review the examples in ‘Details’ to see which product names have multiple associated IDs.
Clean product data: Investigate your product database/catalog. Ensure each distinct product variant has a unique item_id AND potentially a more specific item_name if variations are significant (e.g., “Shirt – Red” vs. “Shirt – Blue”). If it’s truly the same product, ensure it always uses the same item_id.
Standardize tracking: Verify that your website code or GTM setup consistently pulls the correct item_id for each item_name across all ecommerce events (view_item, add_to_cart, etc.).

Negative revenue values check

What it checks: Identifies transactions (purchaseRevenue metric) with a negative value.
Why it matters: While refund events should have negative values, purchase events generally should not. Negative purchase revenue might indicate data entry errors, incorrect handling of discounts/returns in the purchase event itself (refunds should be separate events), or other data layer issues.
Interpreting results:

Pass: Fewer than 10 transactions have negative revenue.
Warn: 10-50 transactions have negative revenue.
Fail: More than 50 transactions have negative revenue.

Investigate specific transactions: Use the transaction IDs (if available in GA4 explorations for the negative revenue) to check the corresponding orders in your backend system.
Separate refunds: Ensure you are sending distinct refund events for returns/refunds, rather than sending purchase events with negative values. The refund event has specific parameters like transaction_id.
Review discount logic: Verify how discounts are applied in your data layer. Ensure they reduce the price or value correctly, not resulting in negative overall purchaseRevenue.
Check data layer implementation: Double-check the code generating the value for the purchase event.

Suspicious large revenue check

Data entry errors (e.g., misplaced decimal points).
Test transactions with unrealistic values.
Currency code mismatches or conversion issues.
Legitimate but outlier purchases (e.g., bulk B2B orders) that might need separate analysis.

Pass: No transactions found with revenue > 10x the average.
Fail: Found at least one transaction with revenue > 10x the average. ‘Details’ lists examples.

Review the transaction IDs listed in ‘Details’.
Verify in backend: Check these specific orders in your ecommerce platform/backend. Was the revenue genuinely that high?
Check data layer: Examine the value and currency being sent in the purchase event data layer for these transactions. Look for extra zeroes, missing decimal points, or incorrect currency codes.
Review test procedures: Ensure test orders use distinct identifiers or values that can be easily filtered out, or that test data isn’t sent to your production GA4 property.
Segment outliers: If the large orders are legitimate (e.g., wholesale), consider creating audience segments or using filters in your analysis to separate them from typical B2C transactions if needed.

Suspicious large quantity check

Zero Quantity: Items in a completed purchase should always have a quantity of at least 1. Zero indicates a data layer or tracking logic error.
Very High Quantity (>100): While possible for some businesses (e.g., wholesale, low-cost items), quantities over 100 are often unusual for typical ecommerce and might indicate data errors, test data, or specific bulk orders needing separate review.

Pass: No items found with quantity = 0 or > 100 in purchase events.
Fail: Found at least one transaction with items having quantity = 0 or > 100. ‘Details’ lists example transaction IDs and quantities/items.

Review the transaction/item details provided.
Check data layer: Examine the items array in the data layer for purchase events. Verify the quantity field is being populated correctly for all items. Ensure it’s an integer and reflects the actual quantity purchased.
Fix zero quantities: Investigate why items might be added to the purchase event data with a quantity of 0. This is likely a bug in the code generating the data layer.
Verify high quantities: Check the corresponding orders in your backend for the high-quantity items. If legitimate, no action may be needed in GA4, but be aware they might skew average quantity metrics. If incorrect, fix the data layer population logic.

Suspicious small revenue check

Test transactions that weren’t filtered.
Data errors (e.g., misplaced decimals).
Tracking issues where perhaps only shipping or tax was recorded as revenue.
Legitimate purchases of very low-cost items or samples.

Pass: No transactions found with revenue > 0 and < 10% of the average.
Fail: Found at least one transaction with revenue > 0 and < 10% of the average. ‘Details’ lists examples.

Review the transaction IDs listed in ‘Details’.
Verify in backend: Check these specific orders in your ecommerce platform. Was the revenue genuinely that low?
Check data layer: Examine the value, currency, shipping, and tax being sent in the purchase event data layer. Ensure the value correctly represents the total transaction value (often excluding tax and shipping, depending on your GA4 settings, but should include item revenue).
Review test procedures: Ensure test orders are identifiable or excluded.

Tax/shipping anomalies check

What it checks: Identifies transactions where the reported taxAmount or shippingAmount is greater than the total purchaseRevenue.
Why it matters: Tax and shipping should be components of, or additions to, the item revenue; they should logically never exceed the total transaction value. This indicates a significant error in how these values are calculated or passed in the data layer.
Interpreting results:

Pass: No transactions found where tax or shipping exceeds total revenue.
Fail: Found at least one transaction where tax or shipping exceeds total revenue. ‘Details’ lists example transaction IDs.

Review the transaction IDs listed in ‘Details’.
Check data layer: This is almost certainly a data layer issue. Examine the purchase event data layer for the flagged transactions. Verify the calculation and population of the value, tax, and shipping parameters. Ensure correct data types (numbers) and decimal placement.
Consult documentation: Refer to Google’s GA4 ecommerce developer documentation for the correct structure and definitions of value, tax, and shipping within the purchase event. Ensure your implementation matches.

GA4 audit help: Google Ads checks

Google Ads Sheet

Linked to GA4 check (gatekeeper)

What it checks: Verifies if any Google Ads accounts are linked to this GA4 property using the Admin API.
Why it matters: Linking Google Ads to GA4 is essential to import cost and click data, see campaign performance directly in GA4, use GA4 conversions for bidding in Google Ads, and build remarketing audiences based on GA4 data. Without the link, you cannot properly analyze paid search performance within GA4.
Interpreting results:

Pass: At least one Google Ads account is linked. ‘Details’ lists the linked Customer IDs.
Fail: No Google Ads accounts are linked to this GA4 property.

Navigate to your GA4 Property > Admin > Product Links > Google Ads Links.
Click the “Link” button.
Choose the Google Ads account(s) you want to link (you must have appropriate permissions in both GA4 and Google Ads).
Configure link settings (Enable Personalized Advertising, Enable Auto-Tagging – strongly recommended).
Submit and confirm the link.
Reference: Google Help: Link Google Ads and Analytics

Account status check (gatekeeper)

What it checks: Verifies if GA4 is receiving any data attributed to Google Ads (specifically looking for non-zero advertiserAdClicks, advertiserAdCost, or sessions associated with a googleAdsCampaignId).
Why it matters: Even if accounts are linked, data might not flow correctly. This check confirms basic data import is happening. If this fails, subsequent checks relying on Ads data are skipped.
Interpreting results:

Pass: Some Google Ads clicks, cost, or sessions were detected in GA4 during the period.
Fail: No Google Ads clicks, cost, or sessions were detected.

Verify link status: Double-check the Google Ads link in GA4 Admin (see previous check). Ensure it’s active.
Enable auto-tagging: Confirm auto-tagging is enabled in your linked Google Ads account(s) (Account Settings > Auto-tagging). This automatically adds the gclid parameter needed for data joining. Manual tagging with UTMs is generally NOT sufficient for full Ads integration.
Check campaign activity: Ensure Google Ads campaigns were actually running and receiving clicks during the selected date range.
Allow data processing time: After linking or enabling auto-tagging, allow up to 48 hours for data to start appearing in GA4 reports.
Check GA4 filters: Ensure no GA4 Data Filters are accidentally excluding Google Ads traffic.

Clicks & cost check

What it checks: Identifies Google Ads campaigns that generated significant traffic in GA4 (>100 sessions) but are missing either advertiserAdClicks or advertiserAdCost data within GA4.
Why it matters: Missing click or cost data for active campaigns prevents you from calculating essential metrics like Cost Per Click (CPC), Return On Ad Spend (ROAS), or conversion rates based on ad spend within GA4. It indicates an incomplete data import.
Interpreting results:

Pass: All campaigns with >100 sessions have both click and cost data.
Fail: Found campaigns with >100 sessions missing click or cost data. ‘Details’ lists affected campaign IDs.

Verify Google Ads link: Ensure the link between GA4 and the relevant Google Ads account is active and correctly configured.
Check auto-tagging: Confirm auto-tagging is enabled in the Google Ads account.
Check cost data import: In Google Ads, ensure cost data sharing is enabled if prompted during linking or check account settings. In GA4, there isn’t a separate import setting like in UA; it relies on the link and auto-tagging.
Permissions: Ensure the user who established the link had sufficient permissions in both platforms. Sometimes unlinking and relinking can resolve permission glitches.
Data latency: Allow up to 48 hours for cost/click data to fully populate after linking/fixing issues.

Ads sessions check

Broken landing page URLs in ads.
GA4 tracking code missing or broken on the landing page.
Slow landing page load times causing users to bounce before the tag fires.
Redirects stripping gclid or referrer information.
Issues with consent management blocking tags.
Potential (though less common) high levels of invalid clicks/bot traffic filtered by Ads but not GA4 sessions.

Pass: No campaigns found with >100 clicks and 0 sessions.
Fail: Found campaigns with >100 clicks and 0 sessions. ‘Details’ lists affected campaigns.

Verify landing pages: Check the landing page URLs used in the flagged Google Ads campaigns (listed in ‘Details’). Ensure they are correct, load properly, and don’t result in errors (404s, etc.).
Check GA4 tag on landing pages: Use Google Tag Assistant (or browser developer tools) to confirm the GA4 tag is present and firing correctly on the specific landing pages used by these campaigns.
Test ad clicks: Manually click on an ad from the affected campaign (or use Google Ads’ Ad Preview tool) and watch the GA4 Realtime report or use GTM Preview mode to see if your session is recorded correctly.
Review redirects: Check for any redirects between the ad click and the final landing page that might interfere with tracking parameters (gclid).
Analyze page load speed: Use tools like PageSpeed Insights to check the performance of the landing pages. Slow pages increase bounces before tracking loads.

Ads sessions < ad clicks check

What it checks: Compares the number of sessions recorded in GA4 to the number of advertiserAdClicks reported for each Google Ads campaign. It flags significant discrepancies.
Why it matters: While you should always expect fewer sessions than clicks (due to bounces before tracking loads, multiple clicks in one session, invalid clicks filtered by Ads), a large difference suggests potential problems similar to the "Ads Sessions" check, but perhaps less severe:

Slow landing pages.
Tracking implementation issues (tag firing late).
High bounce rates immediately upon landing.
Redirect issues.
Cross-domain tracking problems if ads land on one domain but the main site is another.

Pass: Session count is within 10% of the click count for all campaigns.
Warn: Sessions are 10-20% lower than clicks for some campaigns.
Fail: Sessions are more than 20% lower than clicks for some campaigns. ‘Details’ lists affected campaigns and the discrepancy percentage.

Prioritize ‘Fail’ status: Focus on campaigns with the largest discrepancies first.
Analyze landing page performance: Check load speed, mobile-friendliness, and user experience of the landing pages for flagged campaigns.
Verify GA4 tag implementation: Ensure the tag fires early and reliably on the landing page.
Review ad targeting/creatives: Is the ad accurately setting expectations? High immediate bounce rates can contribute to the discrepancy.
Check for redirects: Ensure redirects aren’t causing issues.
Verify cross-domain setup: If applicable, ensure cross-domain tracking is correctly configured.

GA4 audit help: key events checks

Key Events Sheet

Active key events check

What it checks: Verifies if any events marked as "Key Events" in your GA4 property settings have recorded at least 10 completions during the selected date range.
Why it matters: Key Events (formerly "Conversions") are your most important user actions. If none of your designated Key Events are firing with significant volume, it suggests that either your primary conversion tracking is not working, the events chosen as Key Events are not occurring frequently, or the threshold for activity (10 completions) hasn't been met in the period.
Interpreting results:

Pass: At least one event marked as a Key Event has 10 or more completions.
Fail: No event marked as a Key Event reached 10 completions during the period.

Verify key event configuration: Go to GA4 Property > Admin > Key Events. Ensure the events you consider conversions are listed and toggled on.
Check underlying event tracking: Confirm that the base events themselves (before being marked as Key Events) are being tracked correctly in GA4. Use GA4’s Realtime report or DebugView to test if these events fire when expected actions occur on your site/app.
Review event volume: Are the actions defined as Key Events actually happening? If expected volume is low, the check might fail even if tracking is correct, but it highlights low conversion volume.
Ensure sufficient date range: Check if the selected date range is long enough to capture at least 10 completions for your typical Key Events.

Key events equal check

What it checks: Examines active Key Events (those with >= 10 completions). It fails if you have more than one active Key Event, and all of them have the exact same completion count.
Why it matters: It's highly unlikely that different, distinct conversion actions would occur the exact same number of times. If multiple Key Events have identical counts, it strongly suggests they might be tracking the same underlying user action due to:

Marking the same base event as a Key Event multiple times with different names.
An implementation error where different Key Event flags are tied to the same trigger.
Duplicated event tracking in your website/app code or GTM setup.

Pass: Active Key Events have different completion counts, or there is only one (or zero) active Key Event.
Fail: You have two or more active Key Events, and they all recorded the exact same number of completions.

Review key event list: Go to GA4 Property > Admin > Key Events. Examine the events listed. Are there multiple Key Events that seem redundant or represent the same user goal?
Investigate underlying events: For the Key Events with identical counts (listed in ‘Details’), check which base events they correspond to. Are they truly different events triggered by distinct user actions?
Check tracking implementation: Use GTM Preview or browser developer tools to trace how the base events for the identically counted Key Events are being triggered. Ensure they fire under unique, correct conditions.
Consolidate redundant key events: If multiple Key Event names point to the same essential conversion action due to setup errors, decide on one primary Key Event name and remove/archive the redundant ones in GA4 Admin.

GA4 audit help: personal information checks

Personal Information Sheet

PII in page URLs check

What it checks: Scans page URLs (pagePathPlusQueryString) for potential Personally Identifiable Information (PII). This specifically looks for email address patterns within query parameter values and also checks if any query parameter names match a predefined list of sensitive terms (e.g., email, user_id, firstname, lastname, address, phone, etc.).
Why it matters: Sending PII to Google Analytics (especially in URLs) is a violation of Google's Terms of Service and privacy regulations like GDPR and CCPA. Google may delete data found containing PII. It exposes sensitive user data in analytics reports and potentially browser history or server logs.
Interpreting results:

Pass: No email patterns or sensitive parameter names detected in page URLs.
Fail: Found at least one instance of a potential email address or a sensitive parameter name within the query parameters of a page URL. ‘Details’ lists examples.

Review flagged URLs: Examine the URLs listed in ‘Details’. Identify which parameters contain emails or have sensitive names.
Stop collecting PII in URLs: This is critical. Modify your website/app code or CMS configuration to prevent sensitive data (emails, names, IDs, etc.) from ever being included in URL query parameters. Use POST requests for forms, store sensitive data server-side, or use secure methods instead of URL parameters.
Exclude parameters (temporary/partial fix): As a secondary measure while fixing the source, you can exclude the parameter names containing PII from GA4 collection via Admin > Data Settings > Data Collection > URL Query Parameter Exclusions. This only prevents the parameter from being used to define the page, it doesn’t guarantee removal from all GA4 processing if the PII is still being sent.
Use data redaction (advanced): GA4 offers limited text redaction capabilities (Admin > Data Settings > Data Redaction) to attempt to redact email addresses from collected text parameters. Configure this carefully, but prioritize preventing collection in the first place.
Data deletion requests: If PII has already been collected, you may need to submit a data deletion request in GA4 (Admin > Data Requests > Deletion Requests) for the affected time periods and data streams, although this is a complex process.

PII in referral URLs check

What it checks: Scans the pageReferrer dimension (the URL of the site that linked to yours) for potential email address patterns.
Why it matters: While you don't control what external sites put in their URLs, if a referring URL contains PII (like an email address) and GA4 collects it, you are still storing that PII. This could potentially violate privacy regulations depending on your local laws and policies.
Interpreting results:

Pass: No email patterns detected in referring URLs.
Warn: Found at least one referring URL containing a potential email address pattern. ‘Details’ lists examples. (Status is ‘Warn’ because you don’t directly control the referrer).

Review flagged referrers: Examine the referring URLs listed in ‘Details’.
Add to referral exclusion list: The primary way to handle this is to prevent GA4 from treating these sources as referrals and potentially storing the problematic URL. Go to GA4 Property > Admin > Data Streams > [Select your Web Stream] > Configure tag settings > Show more > List unwanted referrals. Add the domain of the referring site (e.g., problem-referrer.com) to the list. This tells GA4 to treat traffic from this domain essentially as ‘Direct’ traffic, which usually prevents the full problematic referrer URL from being stored prominently.
Contact referring site (optional): If the referrer is a known partner, you could inform them they are exposing PII in their URLs.