GA4 Audit Checklist: Check Property Settings, Key Events and Reporting Gaps With AI

Set the scope before running the audit

Connect your property using the guide for Google Analytics with Claude or Google Analytics with ChatGPT.

Record the website, property ID, main business outcome and reporting period. Use complete dates and account for processing delays.

Start with this instruction:

Audit GA4 property [property ID] for [website]. Our main outcomes are [purchases, qualified enquiries or another defined action]. Review [dates] against [comparison dates]. Inspect configuration and reporting only. Make no changes. For every finding, show the evidence, its likely reporting impact and the next check. Separate confirmed problems from possible explanations and items that need manual testing.

1. Confirm the property, reporting currency and time zone

Check that the connected property belongs to the website you intend to analyse. Similar property names can make production, staging and old implementations easy to confuse.

Retrieve the property ID, display name, reporting time zone and currency. Compare them with the property used in your regular reports.

A currency or time-zone mismatch can affect comparisons with advertising platforms, order systems and finance reports. Record the difference before treating it as a performance problem.

Show the connected property’s ID, name, reporting time zone and currency. List the other properties returned from the same account so I can check for similarly named properties. Do not change any settings.

2. Match data streams to the live website

List the configured data streams and check the web stream’s measurement ID and website address.

Compare the measurement ID with the tag actually installed on the website. A stream existing in GA4 does not establish that the correct tag is present on every page.

Test representative pages, including the homepage, a landing page, a form and checkout or confirmation pages. Google’s setup process treats creating a stream and installing the website tag as separate steps. Google’s Analytics setup guide.

3. Review key-event definitions and counting methods

A GA4 key event is an event you have identified as important to the business. Review whether your current list reflects the outcomes you use to judge marketing performance. Google’s explanation of key events.

Check the event name, counting method and any default value. Google supports counting a key event once per event or once per session. These methods can produce different totals when someone repeats an action. Key-event counting methods.

List the configured key events, counting methods and default values. Compare their definitions with [business outcomes]. Flag events whose purpose is unclear and explain what I should verify.

Keep purchases, form submissions and engagement actions separate when presenting results.

4. Compare recorded events with actual outcomes

Retrieve event counts and key-event counts by event name for the audit period. For an ecommerce site, also inspect transactions and purchase revenue.

Compare the relevant figures with your order system or CRM using matching dates and definitions.

For example, 120 recorded form submissions and 90 CRM leads create a question to investigate. The difference alone does not prove that GA4 duplicated 30 leads. Spam filtering, failed CRM delivery, repeat submissions and timing can also affect the comparison.

Complete a controlled test and inspect its event parameters in GA4 DebugView. Google’s DebugView instructions.

5. Check custom dimensions and metrics

List the custom dimensions and metrics registered on the property. Review their names, associated parameters and scopes.

Ask whether each definition supports a report someone uses. Investigate duplicate definitions, unclear names and parameters that the website no longer sends.

Registering a custom dimension makes a parameter available for reporting. Confirm the underlying event implementation separately.

List our custom dimensions and metrics with their parameter names and scopes. Flag unclear definitions and possible duplicates. Identify the definitions that require a browser or tag-manager check to confirm data collection.

6. Review data retention

Check the current retention settings against the history your team needs for investigations.

Google distinguishes user-level and event-level retention from standard aggregated reporting. A short retention window can limit explorations without removing the same period from standard aggregated reports. Increasing retention cannot recover data that has already been deleted. Google’s data-retention guidance.

SourcetoMCP can read these settings. During the audit, request the current values without supplying replacement settings.

Record a recommendation if the current retention period conflicts with an established reporting requirement.

7. Inspect traffic sources and campaign naming

Compare sessions by session source, medium and campaign name. Look for inconsistent campaign names, unexpected referral domains and sudden changes in direct or unassigned traffic.

A change in these categories is a reason to inspect tagging and attribution. It is not enough to identify the cause by itself.

Use session-based dimensions when investigating how visits arrived. First-user dimensions answer a different question about how users were originally acquired. Google’s traffic acquisition guidance.

Compare sessions by session source, medium and campaign name across the two periods. Show the largest changes with their underlying counts. Suggest checks for campaign tagging or referral issues without assuming the cause.

8. Look for landing-page and device gaps

Compare landing-page sessions, engagement and key events across periods. Review device and browser breakdowns separately where they help isolate a change.

Suppose desktop traffic remains stable but mobile activity falls sharply after a website release. Test the mobile experience and tag behaviour before concluding that demand has fallen.

Keep report requests focused. SourcetoMCP’s GA4 reporting has a maximum of 1,000 rows per request. Reports combining many dimensions can reach that limit quickly.

An incomplete landing-page report should not be presented as the full property.

9. Test consent, filters and cross-domain journeys manually

Inspect settings and browser behaviour that a performance report cannot fully validate.

Test the consent experience, internal-traffic exclusions and any journey that moves between domains. Follow an actual form submission or checkout from entry to completion.

Where consent modelling applies, GA4 can include estimated activity, subject to Google’s eligibility requirements. Record the reporting context before comparing modelled totals with directly observed activity. Google’s consent-modelling documentation.

Treat a report anomaly as evidence directing the test, rather than proof that a particular setting is wrong.

10. Record findings with evidence and a retest

Give each finding an owner and a specific validation step.

Ask your assistant to organise the findings:

Create an audit action table with finding, evidence, affected report, next action, owner and validation method. Mark each item as confirmed, suspected or not yet tested. Prioritise problems affecting purchase or lead measurement. Do not make configuration changes.

Use the SourcetoMCP Google Analytics connection to repeat the reporting checks after fixes, then complete the browser tests needed to verify the implementation.