How to check if GA4 fires before consent is given

Why can't the Network tab tell you whether GA4 fired before consent?

Because a network request carries no record of the consent state at the moment it was sent. The Network tab shows you that a hit happened; it cannot show you what the visitor had agreed to when it happened.

A GA4 pageview typically fires within a few hundred milliseconds of page load, often before the visitor has touched the cookie banner. Whether that hit fired before consent is exactly what a GDPR or ePrivacy review needs to know. You can filter for /g/collect requests to google-analytics.com, but each row is just a URL: nothing says what the consent state was at that moment. To reconstruct it manually you would have to decode the CMP's consent cookie (OneTrust's OptanonConsent, Cookiebot's CookieConsent), note its timestamp, and line it up against every request by hand.

Event Watcher does that correlation automatically. It reads consent state from 45+ CMPs (cookies, window APIs, and dataLayer pushes) plus Google Consent Mode signals, and stamps every captured event with a verdict: granted, denied, or pre-consent.

What do you need before you start?

Event Watcher installed, DevTools open on the Event Watcher panel, and a session where the cookie banner still appears. That last one is the part people skip, and it invalidates the whole test.

Consent testing needs a clean slate: use a fresh incognito window (with the extension allowed in incognito) or clear the site's cookies first, so the consent banner actually appears. Stay in the default Stream view and leave the Consent filter chip on Auto. Violation badges are shown automatically in that mode.

How do you check whether GA4 fired before consent, step by step?

Load the page without answering the banner, then read the consent badge on each GA4 event in the stream: a yellow shield means the hit fired before any consent choice, a red shield means it fired after an explicit rejection. The seven steps below cover where to look, and how to tell a real violation from a Consent Mode ping.

1. Load the page and do not touch the banner yet. Events start appearing in the stream immediately.
2. Look for the Baseline consent marker near the top of the stream. It shows the consent state Event Watcher read from CMP cookies at page load, with category chips for analytics, marketing, and functional. On a first visit everything should be undecided or denied.
3. Scan for GA4 events. Anything that fired before a consent choice carries a yellow shield badge (pre-consent); anything that fired after an explicit rejection carries a red one (denied). The violations counter in the toolbar totals them for the session.

4. Click a flagged GA4 event. The detail view's Consent section shows the required category (bold row), what the CMP reported at fire time, the CMP's own category name (e.g. C0002 (Performance) for OneTrust, statistics for Cookiebot), and the Google Consent Mode columns. The decoded parameters also expose GA4's own consent signals: gcs and gcd.

5. Check the Cookies section of the same event. Each cookie row carries a direction badge: Set, Sent, or Set & Sent. A _ga cookie being set before consent is a separate finding from the hit itself.
6. Now accept the banner. A Consent Given marker appears in the stream, and subsequent GA4 hits should be clean. Cycle the Consent chip to Only to see green granted badges explicitly and isolate consent-relevant events.

7. Finally, look at the filter toolbar. The GA4 chip's count badge gains a red or yellow pill when the tool fired denied or pre-consent events. The digit is the violation count, so you can quantify the finding without re-scrolling the stream.

What does a clean result look like, and what does a violation look like?

Clean means GA4 either stays silent until the banner is answered, or sends only cookieless Consent Mode pings. A violation means a full /g/collect hit, with cookies, went out before the visitor chose.

Good: before any banner interaction, GA4 either sends nothing, or sends only cookieless pings carrying gcs=G100 (Consent Mode default denied, see the Consent Mode guide). After acceptance, hits show gcs=G111, the Consent section reads granted for analytics, and no _ga cookie was set pre-consent. The GA4 chip carries no warning pill.

Bad: full /g/collect hits with yellow pre-consent badges before the banner was answered; red denied badges after the visitor rejected; a _ga cookie with a Set badge on a pre-consent event; a red pill with a nonzero count on the GA4 chip. Treat each flag as a starting point for investigation. Verify it against the site's actual consent configuration before calling it a violation.