Analytics dropped after adding a consent banner: how to find the cause

TL;DR — After adding a consent banner, the most common reason for lower analytics is simple: your analytics tag now waits for consent and many visitors do not opt in. The second most common reason is a setup mistake where the banner never sends the "granted" signal, so analytics stays blocked even for users who accept. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon: your new consent banner went live before lunch, and by 3 PM someone posts in Slack that traffic is "down 40%." Sales says orders still look normal in the shop admin, but your analytics dashboard shows fewer sessions, fewer pageviews, and almost no returning users. You open the site, click around, accept the banner, and now you are wondering whether the drop is expected privacy behavior or whether the banner broke tracking entirely.

Symptoms

• Traffic, sessions, pageviews, or conversions drop immediately after the consent banner release.
• Orders or leads in your store/CRM look stable, but analytics-reported conversions are much lower.
• Real-time analytics only starts showing your visit after you click "Accept," or never shows it at all.
• In the browser developer tools (built-in site debugger), requests to analytics endpoints only appear after consent, or do not appear even after consent.
• In the JavaScript console, you may see errors like:

Uncaught ReferenceError: gtag is not defined

Blocked script execution because the document's frame is sandboxed

Failed to load resource: net::ERR_BLOCKED_BY_CLIENT

• In the Network tab, analytics requests such as these are missing or delayed:

https://www.google-analytics.com/g/collect
https://www.googletagmanager.com/gtm.js
https://plausible.io/api/event
https://cdn.segment.com/analytics.js

• The banner appears on every page load, even after you accept or reject it.
• Consent logs in your consent platform show very low opt-in rates compared with expectations.

Likely causes

Step-by-step diagnosis

1. Check whether the drop is expected privacy behavior.

   • Action: Open your analytics real-time report. Then open your site in a private/incognito window.
   • Test A: browse without clicking Accept.
   • Test B: reload and click Accept.
   • This is your problem if: Test A does not appear in real-time, but Test B does. That means analytics is correctly waiting for consent, and the lower numbers are likely due to real opt-outs. Jump to Fixes → Visitors are declining analytics cookies.

2. Check whether accepting the banner actually starts analytics requests.

   • Action: In your browser, open Developer Tools → Network. Filter by collect, gtm.js, analytics, or your analytics vendor domain. Click Accept on the banner and reload once.
   • This is your problem if: after clicking Accept, you still do not see requests such as g/collect, gtm.js, /api/event, or your analytics endpoint. Jump to Fixes → The banner never sends a "granted" consent signal after Accept.

3. Check whether scripts are loading in the wrong order.

   • Action: Right-click the page → View Page Source. Search for your consent script and analytics script names. Also open Developer Tools → Console.
   • This is your problem if: the analytics code throws errors like gtag is not defined, or the consent script runs after the analytics initialization in a way that leaves tags blocked. Jump to Fixes → Analytics loads before or after consent in the wrong order.

4. Check whether consent is being saved.

   • Action: Accept the banner, refresh the page, then close and reopen the same page.
   • This is your problem if: the banner reappears every time, or your choice is forgotten between pages. Jump to Fixes → Consent choice is not being stored.

5. Check your tag manager triggers if you use one.

   • Action: In your tag manager's preview/debug mode, connect to your site and load a page. Click Accept. Inspect whether your analytics tag fires on the page view event.
   • This is your problem if: the tag only fires on some pages, only on click events, or never fires after consent. Jump to Fixes → A tag manager trigger is misconfigured.

6. Rule out browser extensions and privacy features.

   • Action: Test in a private window with extensions disabled, then compare with your normal browser.
   • This is your problem if: analytics requests appear in the clean test but not in your normal browser. Jump to Fixes → Ad blockers or browser privacy features are being mistaken for a banner problem.

[Visitor] ---- 1. loads page ----> [Site]
   |                                 |
   | 2. sees banner                  | 3. loads consent script
   v                                 v
[Consent choice] ---- 4. granted? --> [Analytics tag]
                                        |
                                        | 5. send pageview/event
                                        v
                                  [Analytics endpoint]

Fixes

Visitors are declining analytics cookies, so the drop is real and expected

If your tests show analytics only starts after Accept, your setup may be working correctly. The issue is reporting expectations, not a broken tag.

Remediation:

• Compare business-system numbers with analytics numbers for the same period: store orders, CRM leads, booking submissions.
• In your consent banner settings, review the wording and button design. Use plain language and avoid dark patterns; do not hide Reject if your legal basis requires a real choice.
• If your analytics tool supports cookieless or consent-aware measurement, enable the privacy-friendly mode in that tool's dashboard and document what it can and cannot recover.
• Update stakeholder reporting notes: "Since consent banner launch on YYYY-MM-DD, analytics reflects consented traffic only."

Verify it worked: your private-window test should still show no tracking before Accept and tracking after Accept, and your team should stop treating the drop as a system outage.

The banner never sends a "granted" consent signal after Accept

This is the most common broken setup: the banner blocks analytics, but clicking Accept does not unblock it.

Remediation:

• In your consent platform, open the integration settings for your analytics/tag manager and enable consent updates for analytics storage/cookies.
• If your developer needs a concrete pattern, the page should set a denied default first, then update to granted on Accept. Example for a Google-style gtag setup:

<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
  analytics_storage: 'denied',
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied'
});
</script>

<script>
function onAcceptAnalytics() {
  gtag('consent', 'update', {
    analytics_storage: 'granted'
  });
}
</script>

• If you use a tag manager, map the banner's Accept action to a data layer event your tags can listen for:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'consent_accepted_analytics' });
</script>

Verify it worked: after clicking Accept, Developer Tools → Network should show analytics requests such as g/collect or your vendor endpoint.

Analytics loads before or after consent in the wrong order, so tags never initialize correctly

The safe pattern is: define consent defaults first, then load analytics/tag manager, then update consent when the user chooses.

Remediation:

• Ask your developer to move the consent default snippet above the analytics or tag manager script in the page <head>.
• Example order:

<head>
  <!-- 1. consent defaults -->
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('consent', 'default', { analytics_storage: 'denied' });
  </script>

  <!-- 2. analytics loader -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
  <script>
    gtag('js', new Date());
    gtag('config', 'G-XXXXXXX');
  </script>
</head>

• If Console shows gtag is not defined, define the helper before any call to gtag(...).

Verify it worked: Console errors disappear, and accepting the banner starts analytics requests without a second click or broken page state.

Consent choice is not being stored, so users are repeatedly treated as declined

If the banner keeps coming back, the site may be failing to save the consent cookie/local storage entry.

Remediation:

• In your consent tool, confirm the consent storage domain matches your site, such as .example.com for all subdomains.
• If your team manages the banner code directly, check that the cookie is set on the correct domain and path:

document.cookie = "site_consent=analytics:true; Path=/; Domain=.example.com; Max-Age=31536000; SameSite=Lax; Secure";

• If your site runs on both www.example.com and example.com, standardize one canonical host and redirect the other so consent is read consistently.

Verify it worked: accept once, refresh, and the banner should stay hidden on subsequent page loads on the same site.

A tag manager trigger is misconfigured, so pageviews/conversions only fire on some pages

A common mistake is requiring both "Page View" and a consent event in a way that never matches, or only firing on a custom event after the initial pageview has already passed.

Remediation:

• In your tag manager preview/debug mode, inspect the analytics tag trigger.
• Use a trigger that fires on page view when consent is already granted, plus a second trigger for a consent-accepted event to catch the first page after the click.
• Example event your banner can push:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'consent_accepted_analytics' });
</script>

• Then configure your analytics pageview tag to fire on:
  • All Pages, with consent required for analytics
  • and/or the custom event consent_accepted_analytics

Verify it worked: in preview/debug mode, the pageview tag fires on the first page after Accept and on later pages normally.

Ad blockers or browser privacy features are being mistaken for a banner problem

This does not explain a sudden sitewide drop by itself, but it can confuse testing.

Remediation:

• Repeat tests in a private window with extensions disabled.
• Ask one colleague to test from another browser and device.
• If you use server-side analytics collection, review that setup separately; do not assume browser tests represent every path.

Verify it worked: your clean-browser test behaves consistently, and you can separate extension-related blocking from banner-related blocking.

Prevention

1. Add a post-release consent smoke test to your checklist.

1. Open site in private window
2. Confirm no analytics request before consent
3. Click Accept
4. Confirm analytics request appears
5. Refresh
6. Confirm banner stays hidden

1. Add a lightweight browser test in CI (automated checks during deploys) for consent flow. Example Playwright snippet:

await page.goto('https://example.com');
await page.getByRole('button', { name: /accept/i }).click();
const requests = [];
page.on('request', r => requests.push(r.url()));
await page.reload();
expect(requests.some(u => u.includes('collect') || u.includes('gtm.js'))).toBeTruthy();

1. Version-control your consent defaults and analytics load order in one template file so they are reviewed together.

<!-- consent-defaults.html included before analytics.html -->

1. Track consent rate and analytics request rate side by side in your reporting.

Metric A: banner accept rate
Metric B: analytics pageview requests per 1,000 page loads
Alert if B drops sharply while A stays flat

1. Add a dashboard note or annotation on the consent-banner launch date so future comparisons are not misleading.

2026-10-30: Consent banner enabled. Analytics now reflects consented traffic only.

1. Keep one canonical hostname for the site so consent storage works consistently.

server {
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}

This article was written by an AI system and published pending human review. Verify anything you intend to act on.