Check whether your GA4 measures what you think it does

A GA4 audit answers one question: does the data reaching your property describe what actually happens on the site. It splits into two layers. The first is the implementation — what the site sends to Google on every page view and every click. The second is the property configuration — how GA4 receives, attributes and reports that data.

A URL scan examines the first layer, because that is the only one visible from outside. We open the site in a real browser, walk the path like a customer and read the measurement requests going to Google. No access to your account is needed.

A property audit requires the account to be connected and covers what cannot be seen from outside: key events, data retention, the Google Ads and BigQuery links, custom definitions, reporting identity, attribution and stream settings. Unwanted referrals, internal traffic filters and domain configuration are not exposed by Google's API — those three you can only check in the interface.

Order matters. Property settings will not fix events the site never sends, which is why we start with the implementation. If the first layer is healthy, the second is a handful of fields in the admin panel.

The scan walks the home page, a listing, a product page, the cart and the checkout (on B2B sites — the contact form) and compares the collected requests with what correct measurement looks like. Findings fall into these areas:

• Installation and data flow — whether the GA4 tag exists at all, whether there is one property, whether a page view is counted twice, whether data goes browser-side or through your own server.
• Events and conversions — page views in apps that change the URL without reloading, page scrolling, debug mode left on in production, personal data in URLs and event parameters, form tracking.
• E-commerce — view_item on the product page, add_to_cart after adding, view_cart in the cart, begin_checkout on entering checkout, complete product data, currency and value.
• GTM and pixels — how many containers run, the Meta pixel and its standard events, the Google Ads conversion tag, the TikTok, LinkedIn and Microsoft pixels, how fast measurement scripts load.

Every finding carries evidence: the URL of the view and the fragment of the request or data layer it is based on. The full rule list lives in our methodology.

These are the mistakes that come up most often in scans.

• A double implementation. GA4 wired through Google Tag Manager and again in the page code or a shop plugin. The result: page_view fires twice, page views are inflated, bounce rate is deflated and engagement rate sits near 100%.
• Two properties at once. Usually a leftover from a previous agency or a plugin. Two properties mean two versions of the truth and an argument about which one is right.
• A product page without view_item. The GA4 e-commerce funnel then starts at the cart, so you cannot measure how many people viewed a product versus added it.
• Item entries without item_id or item_name. GA4 shows „(not set)” instead of products, and dynamic remarketing has nothing to match against the feed.
• Sales events without currency and value. GA4 needs both to compute revenue. Without them monetisation reports show zeros and value-based bidding has nothing to work with.
• Debug mode in production. Someone switched debug_mode on for testing and never turned it off — every user lands in DebugView.
• Personal data in URLs. An email address or phone number in a URL parameter reaches GA4 along with the full page_location. That breaches the Google Analytics terms and GDPR.
• Apps without page views. The site changes the URL without reloading and GA4 receives no page_view. Reports show only the first page of each session.
• Payment providers missing from unwanted referrals. The customer returns from the provider domain after paying, and the purchase is attributed to „referral” instead of the campaign that brought it.

You need nothing beyond a browser. Open the site, open developer tools, go to the Network tab and type collect into the filter. Every GA4 request appears as its own row.

Start by accepting the cookie banner — consent-gated tags will not fire otherwise and you will see a picture no real user ever gets. That is the most common reason someone „cannot see” tracking that in fact works.

In the request parameters look for: tid (the property ID — there should be one), en (event name), dl (page URL), gcs (consent state), cu and epn.value (currency and value on sales events), pr1 and onwards (product entries).

Reload the page and count the requests with `en=page_view` for the same URL. One per view is correct. Watch out for a false alarm: with Consent Mode you will see two — the first before consent (gcs=G100), the second after accepting (gcs=G111). That is the consent transition, not a double implementation.

To confirm events inside the property, use DebugView in GA4 together with preview mode in Google Tag Manager. Realtime shows less detail but is enough to check whether an event arrives at all.

In a store the stakes are higher, because measurement decides what your campaigns optimise for. The full GA4 funnel is: view_item_list on the listing, view_item on the product page, add_to_cart after adding, view_cart in the cart, begin_checkout on entering checkout, add_payment_info on choosing a payment method and purchase after the order.

Each of these events carries an items array. An entry needs item_id, item_name, price and quantity. The identifier should be identical to the one in Merchant Center — otherwise dynamic remarketing cannot match the product to the feed and shows a random assortment instead of what the customer viewed.

The most common platform trap: the plugin sends the SKU in a field other than item_id, so product data is technically there while per-product reports stay empty. The second: add_to_cart fired on the button click rather than on confirmation of the add — then you also count failed attempts, for instance when the button opens a variant picker.

purchase should fire once per order and carry transaction_id, because that is what GA4 uses to drop duplicates when someone refreshes the thank-you page. If the purchase path loses customers regardless of tracking, check it in the UX Audit.

In Europe GA4 operates inside a consent framework. Consent Mode v2 passes a gcs parameter on every request: G100 means analytics consent was not granted, G111 means it was. Without those signals Google Ads loses conversion modelling and remarketing for users who declined.

Our scan clicks „accept” and shows measurement in the post-consent state — the one most of your measured traffic is in. It deliberately does not judge the banner itself, nor what fires before consent and after a refusal. That is a separate test, in three passes, and the Consent Mode Checker runs it.

The two tools answer different questions. The GA4 audit: is what you send correct. The checker: are you allowed to send it, and are the consent signals passed properly. A store with flawless e-commerce events and broken Consent Mode still loses data despite a correct implementation.

An expert audit of a GA4 implementation ranges from a few hundred euros for a review of a basic install to five figures for the full scope: the property audit, the data layer, server-side tagging and the Google Ads links. Delivery usually takes from a few days to three weeks.

Our scan is free and ready in a minute — two for a shop — so the natural order is simple: a quick diagnosis first, then a decision with data in hand.

Moments worth checking your tracking:

• before launching campaigns — Google Ads and Meta algorithms learn from your conversions, so a measurement error costs you for the whole run,
• after a redesign, a store migration or a template change — the most common moment for events to quietly disappear,
• when changing agencies — so you know what you are taking over,
• when GA4 numbers disagree with your shop back office or your ad platform.

Order matters more than it seems, because errors compound. Start with the installation: one property, one container, one page_view per view. As long as page views are counted twice, every metric above them is distorted and fixing anything higher is pointless.

Then the path events — the ones your campaigns optimise for first. In a store that is add_to_cart and purchase; on a B2B site, the form submission. The pixel and ad-tag layer comes last, because it feeds on the same data layer events.

After each batch of fixes, confirm the effect in DebugView before moving on. Fixing several things at once ends with nobody knowing which one worked.

One step is easy to forget: event parameters will not appear in GA4 reports until you register them as custom dimensions or metrics (Admin → Custom definitions). Text parameters belong in dimensions, numeric ones in metrics — otherwise you cannot average them. Data reaches the property from day one, but without definitions you will only see it in DebugView.

Finally, run the scan again. The Google Tag Manager cache refreshes some fifteen minutes after publishing, so give it a moment before you check the result.