After implementing DigiConsent, you might notice that your analytics data is missing, incomplete, or not tracking correctly. This is particularly concerning because analytics provide crucial insights into your website performance and user behavior. When analytics stop working after installing cookie consent management, it’s usually because the consent system is correctly blocking tracking until users provide consent, but something in the configuration prevents tracking from resuming after consent is given. This guide helps you diagnose and fix analytics tracking problems while maintaining proper consent management.
Understanding that reduced analytics data after implementing consent management is partially expected is important. Not all users will consent to analytics cookies, and that’s the point of consent management—respecting user choices. However, for users who do consent, analytics should work perfectly. If consenting users still aren’t being tracked, you have a technical problem to solve.
Expected vs Problematic Analytics Reduction
First, distinguish between expected and problematic tracking reduction. After implementing proper consent management, you should expect analytics data to decrease because some users will reject tracking cookies. Depending on your audience and how you present consent options, anywhere from 20% to 60% of users might reject analytics tracking. This is normal and legally required—you cannot track users who haven’t consented.
Expected behavior: Analytics data volume decreases but data for consenting users is complete and accurate. You see fewer overall sessions, but each tracked session includes all the normal data points—page views, events, conversions, etc.
Problematic behavior: Analytics data is completely missing, or you see sessions initiating but no subsequent page views or events. Users who accept cookies still aren’t being tracked, or tracking is partial and broken. These scenarios indicate technical problems, not just users declining consent.
To test, clear your cookies, visit your site, explicitly accept analytics cookies, and browse multiple pages. Then check your analytics dashboard (Google Analytics, Matomo, etc.) in real-time view. You should see your session appear immediately with accurate page tracking. If your session doesn’t appear or appears but doesn’t track properly, you have a technical issue.
Google Analytics Not Loading After Consent
Google Analytics is the most common analytics platform, and it has specific requirements for proper loading. Whether you’re using Universal Analytics (the older version with UA- tracking IDs) or Google Analytics 4 (GA4 with G- measurement IDs), the tracking code must load and initialize correctly after consent is provided.
Verification test: Open your browser console, provide analytics consent, then type typeof gtag (for GA4) or typeof ga (for Universal Analytics). If the function is defined, it should return "function". If it returns "undefined", the analytics library hasn’t loaded even after consent, indicating a blocking problem.
Script blocking format issues: Google Analytics requires two parts: loading the library and initializing it with your measurement ID. Both parts must be properly blocked and then enabled together. A common mistake is blocking only one part, or blocking them with different category names so they don’t enable simultaneously.
A properly configured GA4 implementation through DigiConsent should look like this when you view page source:
<script type="text/plain" data-category="analytics" async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXX"></script>
<script type="text/plain" data-category="analytics">
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXX');
</script>Note that both script tags have type="text/plain" and data-category="analytics". The category name must match exactly (including capitalization) with your DigiConsent category configuration. If the library loads but the initialization doesn’t, or vice versa, they’re not properly coordinated.
Timing issues: The gtag.js library must load before the initialization code runs. If DigiConsent enables both scripts simultaneously but the initialization executes before the library finishes downloading, you’ll get errors. The initialization code will try to call gtag() before it exists.
Solution: The external script tag loading gtag.js should include the async attribute even when blocked. When DigiConsent unblocks it, the async attribute ensures proper loading. The initialization script should execute after the library loads. DigiConsent typically handles this automatically, but if you’re manually configuring scripts, ensure proper ordering.
Multiple Analytics Installations Causing Conflicts
If you have Google Analytics or other tracking installed through multiple methods, they can conflict with each other and with DigiConsent’s management. One installation might be blocked while another loads immediately, creating duplicate tracking or partial tracking that doesn’t work correctly.
Common sources of duplicate analytics:
- Analytics plugin (MonsterInsights, ExactMetrics, Site Kit) loading tracking code independently
- Theme options panel with a field to paste analytics tracking ID
- Google Tag Manager deploying analytics (while also configured directly in DigiConsent)
- Hardcoded analytics in theme files (header.php or footer.php)
- Another plugin with built-in analytics (like WPForms or MemberPress tracking form submissions or purchases)
Diagnosis: View your page source and search for your Google Analytics tracking ID (the part that looks like G-XXXXXXXXX or UA-XXXXXXXX). Count how many times it appears. If it appears more than twice (once to load the library, once to initialize), you have duplicate installations.
Check the Network tab in browser developer tools. After providing consent, look for requests to googletagmanager.com or google-analytics.com. If you see multiple separate requests for the same tracking property, you have duplicate tracking.
Solution: Choose one method for managing analytics and remove all others. The recommended approach is to manage all tracking exclusively through DigiConsent. This ensures proper consent management and eliminates conflicts.
If you use an analytics plugin like MonsterInsights for viewing reports in WordPress admin, you can keep the plugin active but disable its frontend tracking code output. Most analytics plugins have a setting to disable frontend tracking while keeping backend features. Enable this option and let DigiConsent handle all frontend analytics loading.
Google Tag Manager Integration Issues
Google Tag Manager (GTM) is a powerful tag management system, but it adds complexity to consent management. GTM loads first, then dynamically injects tracking tags including analytics. Getting GTM to work correctly with cookie consent requires careful configuration.
The GTM container loading problem: If you block the GTM container completely until consent, users must provide consent before GTM loads at all. This means GTM can’t fire tags even for essential functions that don’t require consent. However, if GTM loads before consent, it might immediately fire all its tags, including analytics, before users can consent.
Consent Mode is the solution: Google Tag Manager includes a feature called Consent Mode that integrates with consent management platforms. With Consent Mode, GTM loads immediately but holds back certain tags until consent is granted. This is more sophisticated than blocking the entire container.
DigiConsent should support GTM Consent Mode integration. When properly configured, DigiConsent sends consent state to GTM using Google’s consent API. GTM then knows whether analytics_storage and ad_storage consent has been granted, and it fires tags accordingly.
Configuration steps:
- In DigiConsent settings, enable Google Consent Mode integration
- Map your cookie categories to Google consent types (e.g., “Analytics” category maps to “analytics_storage”)
- Allow GTM container to load normally (don’t block it)
- In GTM, configure your Google Analytics tag with consent settings requiring “analytics_storage” consent
- Test by denying consent and verifying the GA tag doesn’t fire, then accepting consent and confirming it fires
This approach gives you the power of GTM while maintaining proper consent flow. It’s more complex than direct analytics integration but necessary if you’re committed to using GTM.
Analytics Tracking Without Consent (Compliance Issue)
Sometimes the opposite problem occurs: analytics tracks too well, continuing to track even when users deny consent. This is a serious compliance violation that exposes you to legal risk under GDPR and other privacy regulations.
Testing for premature tracking: Clear all cookies and visit your site in a private browsing window. Before interacting with the consent banner at all, check the Network tab in developer tools for requests to analytics services. Also check the Application/Storage tab for analytics cookies. If you see analytics requests or cookies before providing consent, tracking is happening too early.
Deny analytics consent explicitly through the banner. Navigate to multiple pages while still denying consent. Analytics should absolutely not track these page views. Check your analytics dashboard’s real-time view—you should not appear there. If you do, tracking is bypassing consent.
Common causes:
- Analytics installed through a method DigiConsent doesn’t control (another plugin, hardcoded, etc.)
- Incorrect script blocking format—scripts missing
type="text/plain"or data-category attributes - Automatic script blocking feature not working correctly
- Caching serving old page versions with unblocked analytics
Solution: Consolidate all analytics management into DigiConsent. Search your entire codebase for analytics tracking IDs and remove all instances except those managed by DigiConsent. Verify script blocking syntax is correct in page source. Clear all caches and test thoroughly.
Event Tracking and Enhanced Ecommerce Issues
Basic pageview tracking might work, but event tracking (button clicks, video plays, form submissions) or ecommerce tracking might fail. This happens because these tracking features depend on additional code that might not be loaded or initialized correctly after consent.
Event tracking dependencies: Events are tracked by calling gtag('event', 'event_name') or similar functions. If this code executes before the analytics library loads (before consent is given), it fails silently. The code tries to call functions that don’t exist yet.
Many sites have event tracking code inline on buttons or in theme/plugin JavaScript. This code typically assumes analytics is always loaded and ready. With consent management, analytics might not be loaded when these scripts execute.
Solution: Event tracking code must check if analytics is loaded before trying to track events. Modify event tracking to be consent-aware:
// Bad: Assumes gtag is always available
gtag('event', 'button_click');
// Good: Checks if gtag exists first
if (typeof gtag !== 'undefined') {
gtag('event', 'button_click');
}Better yet, use DigiConsent’s API (if available) to execute event tracking code only after consent is granted. This ensures events are only tracked for consenting users and tracking code executes at the right time.
Enhanced Ecommerce tracking: WooCommerce, Easy Digital Downloads, and other ecommerce plugins often include analytics integration that tracks purchases, product views, and add-to-cart events. These integrations load their own tracking code that might bypass consent management.
Review your ecommerce plugin’s analytics settings. Disable built-in tracking if it’s not consent-aware and implement tracking through DigiConsent or GTM with proper consent checks.
Matomo (Piwik) Specific Issues
Matomo is a popular privacy-focused analytics alternative to Google Analytics. It can be self-hosted or cloud-hosted. Matomo has its own consent management features that must be coordinated with DigiConsent.
Matomo’s built-in consent management: Matomo includes functions like _paq.push(['requireConsent']) and _paq.push(['setConsentGiven']) that control tracking based on consent. If both Matomo’s consent management and DigiConsent are active, they might conflict or create redundant consent requests.
Solution: Choose one consent management system. If using DigiConsent site-wide, disable Matomo’s consent features and let DigiConsent control when Matomo loads. Block the Matomo tracking code using DigiConsent’s script blocking, just like Google Analytics.
If you prefer Matomo’s consent management, ensure it’s properly integrated with DigiConsent. When users provide consent through DigiConsent’s banner, it should trigger Matomo’s setConsentGiven() function to enable tracking.
Self-hosted Matomo CORS issues: If Matomo is self-hosted on a different domain than your WordPress site, browser CORS (Cross-Origin Resource Sharing) policies can block tracking requests. This isn’t specifically a consent issue but can appear after implementing consent management if it changes request timing.
Verify your Matomo instance is configured to accept requests from your WordPress domain. In Matomo’s config file or settings, add your WordPress domain to allowed origins.
Facebook Pixel Not Firing
Facebook Pixel tracking for ads and conversions requires similar consent management to analytics. The pixel must be blocked before consent and load correctly after consent is granted.
Facebook Pixel structure: The pixel has base code that initializes the library and event tracking code that logs specific events. Both must be properly blocked and enabled together.
A properly blocked Facebook Pixel looks like:
<script type="text/plain" data-category="marketing">
!function(f,b,e,v,n,t,s)
{if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};
if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t,s)}(window, document,'script',
'https://connect.facebook.net/en_US/fbevents.js');
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');
</script>Testing pixel loading: After providing consent, check the browser console for typeof fbq. It should return "function" if the pixel loaded correctly. Check the Network tab for requests to facebook.net or facebook.com containing your pixel ID.
Use Facebook’s Pixel Helper browser extension (available for Chrome) to diagnose pixel issues. It shows whether pixels are firing, what events they’re tracking, and any errors. After consenting, the Pixel Helper should show your pixel as active and tracking events.
Conversion API vs Browser Pixel: Facebook now recommends using both the browser pixel and the Conversions API (server-side tracking) for reliable conversion tracking. If you’re using only the browser pixel and it’s being blocked by consent or ad blockers, conversion tracking suffers. The Conversions API sends data from your server to Facebook, bypassing browser-based blocking.
While implementing Conversions API is beyond DigiConsent’s scope, be aware that even with perfect consent management, browser-based pixels are increasingly blocked by ad blockers and privacy tools. Server-side tracking provides more reliable data.
Real-Time Analytics Debugging
Most analytics platforms offer real-time reporting that shows activity as it happens. This is invaluable for debugging tracking issues.
Google Analytics real-time reports: In Google Analytics, navigate to Reports → Real-time → Overview. Open your website in another browser window. You should see yourself appear in the real-time report within seconds. Navigate between pages—each page view should appear.
If you don’t appear in real-time reports after consenting to analytics, tracking isn’t working. Check browser console for errors, verify consent was actually recorded, and confirm analytics scripts loaded.
Browser extension debugging: Extensions like Google Analytics Debugger (for Chrome) provide detailed console logging of all analytics hits being sent. After enabling the extension, you see every analytics request logged in the console with all parameters. This shows exactly what data is being sent or reveals that no data is being sent at all.
Similarly, Facebook Pixel Helper, LinkedIn Insight Tag Helper, and other platform-specific debugging extensions help diagnose tracking issues for their respective platforms.
Server-Side Tracking Considerations
Some analytics implementations use server-side tracking where your server sends data to analytics platforms rather than browser JavaScript. Server-side tracking isn’t affected by client-side consent management in the same way.
If you have server-side analytics tracking (common in headless WordPress setups or custom applications), DigiConsent’s client-side script blocking won’t prevent it. You need server-side consent checking where your server code checks if the user has consented before sending analytics data.
This typically involves reading the DigiConsent cookie on the server (in PHP for WordPress) and conditionally executing tracking code based on consent state. This requires custom development and deep integration between your consent management and server-side code.
Analytics Debugging Checklist
When analytics isn’t tracking after implementing DigiConsent, work through this systematic checklist:
- Clear all cookies and visit your site fresh
- Open browser developer tools (F12) before interacting with the banner
- Explicitly accept analytics cookies through the banner
- Check the Console tab for JavaScript errors
- Verify in the Network tab that analytics libraries are loading (requests to googletagmanager.com, google-analytics.com, etc.)
- Check the Application/Storage tab that analytics cookies are being set (like _ga, _gid for Google Analytics)
- Test
typeof gtagortypeof fbqin the console to confirm tracking functions exist - Navigate to multiple pages and verify each page view is tracked
- Check analytics real-time reports to confirm your session appears
- View page source and verify analytics scripts have correct blocking syntax (
type="text/plain"and matching data-category) - Search page source for your tracking ID to identify duplicate installations
- Temporarily disable other plugins to identify conflicts
- Test in different browsers in case it’s browser-specific
This methodical approach identifies whether the problem is with consent not being granted, scripts not loading after consent, scripts loading but not initializing correctly, or data being sent but not appearing in reports. Each scenario has different solutions, and systematic testing reveals which scenario you’re facing.
Remember that some analytics reduction after implementing consent management is expected and legally required. The goal is ensuring users who do consent are tracked accurately while those who decline consent are properly excluded from tracking.