Short answer
When GA4 appears before consent, start by finding every loader: GTM, hard-coded gtag, WordPress or Shopify plugins, tag gateways, and server-side configurations. Most failures come from duplicate paths or defaults applied after the first configuration call.
A correct result is behavioural: no optional GA4 request or cookie before the relevant choice in a strict setup, and no unexpected reactivation after Reject or withdrawal. Consent Mode parameters alone do not prove that your implementation is correct.
What to check
- Whether analytics_storage defaults to denied before gtag or GTM runs.
- Whether a second GA4 measurement ID or loader exists outside the intended container.
- Whether analytics-only consent accidentally grants advertising parameters.
- Whether navigation, hard refresh, and withdrawal preserve the selected state.
Practical steps
- Search source, GTM, plugins, and app settings for each GA measurement ID.
- Set denied defaults before optional tag execution.
- Test clean-session initial load, Reject, analytics-only, Accept, navigation, and withdrawal.
- Check Network requests and _ga-style cookies at each stage.
- Use GDPRChecker to capture the production result and re-test after container publishes.
Common mistakes
- Fixing only GTM while a theme or plugin still loads gtag.
- Using browser preview sessions that already retain consent.
- Confusing Google Ads parameters with GA4 analytics consent.
- Loading GA4 on all pages and hoping a later consent update repairs the first hit.
Important boundary
Know the scope
Google Analytics configuration can have legal implications that depend on your processing, region, and settings. This checklist is technical troubleshooting, not legal advice.