A GA4 tracking QA checklist to run before a site goes live

Updated September 2026 · 6 min read

A Google Analytics™ 4 setup can look fine for days before someone notices a missing event or a duplicated purchase in the reports. This checklist covers what you can verify from the browser before a site goes live, or after any change to its tags, and what only GA4 itself can confirm.

Before you start

• Write down what should happen: the events for each page and action, their parameters and the consent each one needs. A tracking plan in a spreadsheet is enough; our CC0 CSV templates are a starting point.
• Test in a fresh browser profile or a new incognito session after closing all existing incognito windows, without ad blockers, so earlier cookies and consent choices do not change the result.
• Open DevTools (F12), go to the Network tab, tick Preserve log and filter by collect.

1. The right property

• Every GA4 request carries the measurement ID in tid. It must be the web data stream meant for the site you are testing: a staging ID on the live site, or the other way round, mixes data between properties.
• If more than one measurement ID appears, make sure each one is intended (for example, a second property for a region or an agency).

2. Page views

• page_view is sent once per page load. Two identical page views often mean the Google tag is installed twice, for example in the site code and in Google Tag Manager.
• On a single-page app, GA4’s enhanced measurement can send a page view on browser history changes. If your code also sends one on each route change, every virtual page counts twice.
• The page URL (dl) and title (dt) are right and contain no emails, names or other personal data, for example in the query string.

3. Key events

• Each action you measure (a lead form, a sign-up, a purchase) sends its event once, with the exact name in your plan. GA4 event names are case-sensitive: Purchase and purchase are different events.
• The events you mark as key events in GA4 use exactly those names.
• Reload thank-you pages and use the back and forward buttons: the event should not be sent again.

4. Ecommerce parameters

• currency (cu in the request) is a three-letter ISO 4217 code whenever value is sent.
• value (epn.value) is a number, without currency symbols or thousands separators.
• Items (pr1, pr2…) have an item_id or an item_name, and every purchase has its own transaction_id. The purchase checklist covers the details.

5. Consent

• The default consent state is set before measurement tags run or other code uses or updates consent. Consent updates reflect the visitor’s choice.
• In advanced Consent Mode, GA4 can send cookieless pings while analytics_storage is denied. Inspect gcs and gcd where present, and confirm the effective consent state in Tag Assistant. In basic mode, tags remain blocked while the required consent is denied.
• Repeat the journey accepting and rejecting cookies. See how to check Consent Mode v2.

6. Personal data

• No emails, phone numbers or names in any parameter, URL or page title sent to GA4: Google’s policies do not allow sending personally identifiable information to Analytics.
• Watch forms that put the email in the URL of the next page, and internal search pages whose URL includes what the visitor typed.

7. What only GA4 can confirm

The browser shows what was sent, not what GA4 did with it. With debug mode on, use DebugView to check incoming events, bearing in mind that denied analytics consent or client-side privacy controls can prevent them from appearing; check data filters and internal traffic rules; and look at the standard reports once the data is processed, which Google says can take 24 to 48 hours.

Sign-off

For each item, note what you checked, on which page and browser, and the result. A list of findings, each with the request that proves it, is easier to hand to the client or to the developer who fixes it.