Guides → Why is my analytics data missing? — SGEN debugging guide

Fix analytics missing data on your SGEN site

How to fix missing analytics data on your SGEN site

Your Analytics Reports showed steady traffic last week. Then you deployed a change — a consent banner update, a Custom Codes edit, a new GTM tag — and now pageviews are down 60%. The data might not have gone anywhere. Four things explain the vast majority of analytics drops on SGEN sites: a rise in consent declines, a change in GTM script gating order, a custom code placed in the wrong position relative to the consent check, or the roughly 30% of users whose browsers block third-party tracking scripts outright.

This guide walks your business through each of those four causes in order, from the most likely to the least, and tells you what to look at in your SGEN admin at each step.

What is this for?

This is a decision-tree workflow for diagnosing a sudden drop in analytics data — specifically data coming from third-party tools (Google Tag Manager, GA4, Clarity, Facebook Pixel) rather than SGEN's built-in native tracker. Use it when the drop is recent, correlates with a change you made, or appeared without a change you can identify.

It is a diagnostic guide, not a setup guide. If you have not yet set up analytics on your site, start with the pile docs: Event Logs, Traffic Reports, Configure Cookie Consent, and Custom Codes.

The symptom this guide addresses: a drop of 30% or more in pageviews or sessions in your third-party analytics tool (GA4, Clarity, etc.) that appeared after a deploy, a settings change, or a Custom Codes edit — and is not explained by a real drop in site traffic.

Good use cases

Post-deploy analytics regression. You updated the consent banner copy or toggled a new Exclusion, and your GA4 sessions dropped the next morning.
New consent banner launch. You launched a GDPR-compliant banner for the first time and now want to understand why your session counts dropped 40% versus the same period last month.
GTM tag stopped firing. A Google Tag Manager tag that used to fire consistently is now showing zero events in the GA4 DebugView.
Custom Codes script is not loading. A tracking snippet you added under Custom Codes is not appearing in the page source of your public homepage.
You suspect ad blockers. Your site serves a technical or privacy-aware audience and you want to estimate how many sessions ad blockers are silently dropping.
Consent log shows high decline rate. Your Tracking Consent → Logs screen shows more visitors choosing Decline than you expected, and you want to understand the impact on your analytics numbers.

What NOT to use this for

SGEN native Analytics is missing data. SGEN's built-in Event Logs and Traffic Reports run server-side and are not affected by consent banners, ad blockers, or GTM at all. If your native SGEN counts dropped, that is a different problem — check whether a real traffic drop explains it, and look at the Traffic Reports date range.
You have never had analytics data. This guide assumes you had working analytics that has now dropped. If you are setting up from scratch, follow the setup docs first: Custom Codes to add the tracking snippet, then Configure Cookie Consent to gate it correctly.
Your GA4 property itself is broken. If the problem is on the Google Analytics side (property permissions, data stream configuration, filter rules), this guide will not help. Log in to GA4 directly, go to Admin → Data Streams, and confirm your stream is active and receiving hits.
You want to stop analytics from running. If you intentionally want to suppress analytics for compliance or testing, toggle the relevant Exclusion under Tracking Consent → Settings or deactivate the Custom Code — do not try to "fix" a correctly-working consent gate.

How this connects to other features

Event Logs — SGEN's server-side tracker. Not affected by consent or ad blockers. Use it as a ground truth: if Event Logs shows normal traffic but GA4 does not, the gap is explained by one of the four causes in this guide.
Traffic Reports — the charted summary of native event data. Useful for confirming that real visitor traffic is arriving, independent of whether third-party tools see it.
Configure Cookie Consent — the settings panel where you enable the consent banner, write disclosure copy, and gate which tracking scripts require consent. Steps 1 and 2 of this guide both point here.
Custom Codes — where GTM, GA4, and other tracking snippets live on your SGEN site. Custom code placement (head vs. body, before vs. after the consent check) is Step 3 of this guide.
Google Tag Manager — configured outside SGEN. The Gate Google Tag Manager toggle under Tracking Consent gates the entire GTM container, including every tag inside it. When GTM is gated, GA4, Pixel, and any other GTM-loaded tag all stop firing until consent is given.

Before you start

You are signed in to SGEN as an Administrator.
You know roughly when the drop started and whether it correlates with a change you made (new banner, updated consent settings, new Custom Code, GTM tag edit).
You have access to your third-party analytics tool (GA4, Clarity, etc.) in a separate browser tab.
You have an incognito or private browser window ready — the consent banner does not reappear in a browser that has already recorded a decision, so all verification steps must be done in a fresh incognito window.
You know whether your site has a consent banner live (Tracking Consent → Settings with Enable Consent toggled on). If you are unsure, navigate there first.

Where to go

The four diagnostic steps each live in a different part of your SGEN admin:

Tracking Consent → Logs — Step 1, consent decline rate
Tracking Consent → Settings — Step 2, GTM gating
Custom Codes — Step 3, script placement
Analytics → Reports (compare native vs. third-party) — Step 4, ad-blocker estimate

Navigate to Tracking Consent from the left sidebar. Custom Codes is also in the left sidebar. Analytics is in the left sidebar under the same group.

Steps — Diagnose the drop

1. Check your consent decline rate in Tracking Consent → Logs

Open Tracking Consent → Logs. This screen shows one row per visitor decision — accepted, declined, or no decision. Sort by the most recent decisions and look at the distribution.

If your decline rate has risen above 20–30%, that alone explains a significant analytics gap. Visitors who click Decline have their tracking scripts suppressed for all future page views in that browser. A banner redesign, a copy change, a new checkbox requirement, or a position switch can all push the decline rate up sharply.

The consent log for your business after a banner update looks like this — accepted sessions (green) down, declined sessions (red) up compared to the week before:

A split of 147 accepted / 138 declined on 312 sessions is a 44% decline rate — roughly double the pre-update rate of ~22%. That gap alone accounts for most of a 60% analytics drop, because declined visitors generate zero GA4 sessions.

What to do if decline rate has risen: open Tracking Consent → Settings and review what changed since the drop. Common culprits: the "I agree" checkbox was turned on (raising friction), the banner position was moved to Center (modal, more intrusive), or the button labels were changed to something that feels more like "refuse" than "continue." Revert one change at a time and watch the Logs distribution shift.

The healthy decision distribution for a site with a well-worded bottom-position banner looks like this — accepted sessions carrying the majority, declines in a meaningful but not dominant minority:

2. Check which tracking scripts the consent banner is gating

Open Tracking Consent → Settings and look at the four Exclusion toggles: Gate Google Tag Manager, Gate Microsoft Clarity, Gate Session Attributer, Gate Draft Form Entries. All four default to on (gated) on a fresh install.

If GTM is gated (the toggle is ticked), then GA4, Facebook Pixel, and every other tag loaded through your GTM container are all suppressed until the visitor accepts. That is correct behavior — but if you recently ticked this toggle without realizing it, that is the change that caused the drop.

The gating order matters. SGEN runs the consent check before any Custom Code in <head> renders. If GTM is ticked under Exclusions and a visitor declines, the GTM container never loads — no tags fire, no GA4 sessions record, no Pixel events trigger.

What to do if the wrong toggle is ticked: decide whether gating that script is required by your compliance posture. If you added GTM recently and want it to load without consent (not recommended for EU/UK audiences), untick the Gate Google Tag Manager toggle and save. If you must gate it, the drop in your analytics is expected and correct — your options are to improve your consent accept rate (Step 1) or switch to server-side tagging outside SGEN.

3. Check the placement of your Custom Code scripts

Open Custom Codes from the left sidebar. Find the entry for your GTM snippet or GA4 tag. Check its Placement — the options are <head>, <body> — Start, or </body> — End.

The placement relative to the consent check matters:

Scripts placed in <head> load before the visible page renders. SGEN's consent gate fires early in <head> and suppresses gated scripts before the browser encounters them. This is the correct placement for GTM when consent gating is in use.
Scripts placed at </body> — End load last. SGEN's consent gate is still applied, but some older GTM container configurations rely on document.write and may behave differently at body-end. If your GTM snippet was working at body-end before the consent banner was added, and is now silent, move it to <head>.
Scripts placed at <body> — Start load early in the body. Consent gating still applies, but there is a small window where the banner has not yet rendered — this can cause the consent check to race on slow connections.

The recommended placement for a consent-gated GTM container is <head>. This is what a correctly configured Custom Codes list looks like for your business — GTM in <head>, Hotjar regex already in the Other scripts field:

What to do if placement is wrong: click the code name to open the edit panel, change the Placement dropdown, and save. Navigate to your public homepage in a fresh incognito window and view the page source — your GTM snippet should appear in <head> before the closing </head> tag. After clicking Accept on the banner and reloading, it should fire normally.

What to do if a script appears in the source before the consent check has run: this usually means the script is not flagged as a gated Custom Code and the Tracking Consent regex for that domain is missing. Add the script's domain to the Other scripts regex field in Tracking Consent → Settings.

4. Estimate your ad-blocker gap

Approximately 30% of web users run a browser extension or DNS-level filter that silently blocks requests to known analytics domains — googletagmanager.com, google-analytics.com, static.hotjar.com, and similar. These visitors never show up in your GA4 sessions regardless of whether they accept or decline the consent banner, because the tracking script is blocked at the network level before it can fire.

You cannot fix this at the SGEN level. However, you can measure the gap by comparing SGEN's native Event Logs count (server-side, not affected by ad blockers) to your GA4 session count for the same period.

Open Analytics → Reports in your SGEN admin. Set the event type to Page View and the date range to the last 7 days. Note the Total Events tile. Then open GA4 (or your third-party analytics tool) and look at the sessions count for the same 7-day window.

The gap between the two numbers — native page views minus GA4 sessions — is the combined effect of consent declines and ad blockers. If your consent Logs show a 15% decline rate, and the native-to-GA4 gap is 45%, ad blockers account for roughly the remaining 30 percentage points.

Ad-blocker impact is a reality for most sites — especially blogs, developer tools, and privacy-aware communities. The mitigation options are outside SGEN's scope: server-side tagging (sending events from your own server to GA4 rather than from the visitor's browser) or switching to a server-side analytics tool that is not blocked. SGEN's native tracker is server-side and is not affected.

What success looks like

You have found and fixed the cause of the analytics drop when:

Consent Logs show a decline rate under 25% and it has returned to the level you saw before the drop. If you changed the consent banner and accept rates came back, the banner was the cause.
GTM fires on every page for visitors who have accepted. Open your site in a fresh incognito window, accept the banner, then open the GTM Preview/Debug console — you should see the container fire on page load.
The Custom Codes list shows your tracking snippet as Active and the Placement is <head> (for consent-gated GTM). Viewing the page source after accepting the banner shows the GTM snippet in <head>.
The native-to-GA4 ratio is stable week over week. If SGEN native page views and GA4 sessions both moved in the same direction by the same proportion, real traffic is what changed — not your tracking setup.

What to do if it does not work

Consent Logs show zero rows. The banner has not been live long enough to record decisions, or it is being shown on pages that are Excluded from the banner. Confirm Enable Consent is on and that your homepage is not in the Excluded Pages list.

GTM fires before the visitor accepts the banner. Open your public homepage in a fresh incognito window and view the page source — search for googletagmanager.com. If you see the GTM snippet in the source before the visitor has accepted, the Gate Google Tag Manager toggle is off. Tick it and save.

GTM does not fire even after the visitor accepts the banner. The Custom Code entry for GTM may have been accidentally deactivated. Open Custom Codes, find the GTM entry, and confirm the Active toggle is on. Also check that the GTM container ID in the snippet matches the one in your GTM account — a stale container ID causes a silent failure.

One specific tag inside GTM is not firing, but others are. This is a GTM-level configuration issue, not a SGEN issue. Log in to GTM, open the Preview/Debug mode for your container, and check whether the trigger conditions for that tag are being met. SGEN gates the entire GTM container (all-or-nothing); it does not gate individual tags within GTM.

Custom Codes script is not appearing in page source at all. Open Custom Codes and confirm the entry is Active (not Inactive). Check the Placement — if it is set to a Placement you are not looking at (for example, you searched in <head> but it is placed at </body> End), you will not find it in the section you expect.

Ad-blocker gap is much larger than 30%. Some audiences (security researchers, developers, European privacy advocates) run 50–60% ad-blocker rates. Native server-side analytics is the only reliable way to count these visitors. SGEN's Event Logs is server-side and not affected.

You cannot reproduce the issue in a test. You are almost certainly testing in a browser that already has a consent decision stored. Always test in a fresh incognito or private window, or clear cookies for your domain before opening your site.

Examples

Example 1: Consent banner rewrite caused a 60% analytics drop.

your business updated their consent banner on Apr 28 — new copy, new position (moved from Bottom to Center), and the "I agree" checkbox turned on. The next morning, GA4 sessions were down 60% versus the same day the prior week.

Opening Tracking Consent → Logs showed the problem: the accepted/declined split flipped from 75%/25% to 44%/56%. The modal position and the mandatory checkbox were creating too much friction.

The fix: move Position back to Bottom, remove the "I agree" checkbox requirement, and rewrite the Decline button from "Refuse" to "Continue without analytics." After saving and waiting 48 hours, the accept rate returned to 72% and GA4 sessions recovered to within 10% of the pre-change baseline.

Example 2: GTM container suppressed by a newly-ticked Exclusion.

your business added a new tracking tag to their GTM container — a conversion pixel for a paid campaign. While adding it, the site owner also opened Tracking Consent → Settings to add a regex for the pixel domain. They accidentally ticked the Gate Google Tag Manager toggle (which had been off previously) and saved without noticing.

The result: every visitor to the site, whether they accepted or declined the banner, stopped receiving the GTM container — because now the entire container was gated, and no visitor had yet encountered the new banner flow.

The fix required two steps:

Open Tracking Consent → Settings, scroll to Exclusions, and confirm the Gate Google Tag Manager toggle reflects the intended posture — on if consent is required for GTM, off if GTM should load regardless of consent.
Rewrite the Other scripts regex for the pixel domain so only that specific pixel is gated, rather than gating the entire GTM container.

After correcting the toggle and saving, GTM fired correctly for all visitors, and the pixel alone was gated until consent.

Example 3: Custom Code placed at body-end fires after the consent check window.

your business' marketing team added a Facebook Pixel snippet to Custom Codes with Placement set to </body> — End. The consent banner was configured to gate Facebook Pixel via the Other scripts regex /connect\.facebook\.net/i.

On testing, the site owner noticed the Pixel was occasionally firing before the visitor accepted the banner — the consent check had completed and injected the banner, but the Pixel at body-end was loading slightly after the gate check on slow connections. Moving the Pixel's Custom Code Placement from </body> — End to <head> fixed the race: the consent gate in <head> now ran before the Pixel script was encountered by the browser, and the suppression was reliable on every test.

The corrected Custom Code edit panel, after changing Placement:

Tips for keeping analytics reliable

A few habits prevent most analytics data drops before they happen.

Test in incognito after every consent banner change. Your normal browser has a consent decision stored. It will not show you the consent gate or the pre-accept state of your tracking scripts. Always verify in a fresh incognito window.

Compare native SGEN page views to GA4 sessions weekly. Set up a five-minute Monday check: open Analytics → Reports, note the native page-view total for last week, then check GA4. If the ratio changes by more than 10 percentage points week over week, one of the four causes in this guide has changed.

Gate scripts at <head> placement. When using Tracking Consent to gate a Custom Code script, the most reliable placement is <head>. Body-end placement occasionally causes a race condition between the consent check and script load — especially on mobile connections where the document renders slowly.

Keep your Excluded Pages list up to date. If you add a new Privacy Policy page or change the slug of your Cookie Policy page, update the Excluded Pages list in Tracking Consent → Settings. A visitor who lands on an excluded page and still gets the banner (because the exclusion is stale) may decline immediately.

Read the decline rate, not just the accept rate. A stable 20% decline rate is expected and healthy. A sudden jump to 40% or 50% is a signal — usually a UX or copy issue on the banner, not a tracking failure. The Logs screen in Tracking Consent tells you when the jump happened, which correlates with what you changed.

Guides

Reference

Changelog

Roadmap