WordPress maintenance Hacked site cleanup Security plugin Pricing Security tips
Home / Security tips / Web development
October 31, 2026

Cookie banners that kill your analytics and how to fix them

A visitor opens your WooCommerce shop, sees a cookie banner, and clicks “Decline all.” Fair enough. But what if they only wanted to avoid ads? Your analytics disappears along with the ad tracking, even though that visitor might have been happy to allow plain site statistics. Consent Mode can help your Google tags respond to a more useful choice. It can’t make anyone say yes, and it shouldn’t try.

I’m Andrei. I work on WordPress maintenance and development, and my take is simple: don’t remove the reject button to improve your numbers. Give people separate choices, then make sure the site actually follows them.

Why two buttons aren’t enough

“Accept all” and “Decline all” put analytics and advertising in the same basket. Some people who’d decline ad tracking are fine with plain stats. That’s an expectation, not a promise about how your visitors will behave. But if the banner offers no middle option, you’ll never give them that choice.

That matters when you use your analytics data to decide which product pages need work or where to focus your SEO efforts. You’re trying to make decisions from what you can measure. An all-or-nothing banner can leave out visits from people who object to ads, not statistics.

The fix is a simple first layer: Accept all, Reject all, and Settings or Customize. Inside Settings, show Necessary, Analytics, and Marketing/Ads. Add Preferences if your site uses that category. Necessary stays on; the optional toggles start off. No pre-ticked permission.

Keep the legal bit straight

The ePrivacy Directive requires consent before your site stores or reads cookies or similar identifiers on someone’s device that aren’t strictly necessary. Cart cookies, login sessions, security cookies, and the cookie that remembers a visitor’s consent choice are strictly necessary and don’t need that permission.

GDPR says consent must be freely given, specific, informed, and unambiguous, with a clear affirmative action. Withdrawing it should be as easy as giving it. EU data protection authorities expect rejecting to be as easy as accepting, on the same layer rather than behind a hidden menu. Pre-ticked boxes don’t count as valid consent. This isn’t legal advice; get advice for your own setup if you need it.

So no, hiding Reject all isn’t a clever analytics fix. It’s the wrong fix.


What Consent Mode v2 actually does

Google Consent Mode v2 tells Google tags what the visitor allowed. It uses four signals, each set to granted or denied:

  • analytics_storage follows the Analytics choice.
  • ad_storage, ad_user_data, and ad_personalization follow the Marketing/Ads choice.

The last two signals arrived with the v2 update. Both ad_user_data and ad_personalization must be granted for personalized ads and remarketing. If you don’t run ads or remarketing, analytics_storage is probably the signal you care about most. Set defaults for all four anyway.

Google requires advertisers using its tags for measurement or personalization with EEA users to collect consent and pass these signals. A banner that merely looks right isn’t enough; the choice has to reach the tags.

Basic or advanced? Start with basic

In basic consent mode, Google tags are blocked untill someone interacts with the banner. Nothing goes to Google before that choice, and if they reject, nothing goes to Google at all. Google’s conversion modeling then uses a general model.

Advanced consent mode works differently. Tags load with consent defaults set to denied, and while consent is denied they send cookieless pings without writing cookies. Once someone grants consent, cookies can be written and full data is sent. Those earlier pings enable advertiser-specific modeling.

My preference for a small site is basic. It’s simpler and the safer default. Advanced sends cookieless pings before consent, so treat it as a privacy decision to discuss with whoever handles that side of your business, not a switch to flip because a dashboard looks sparse.

Make the banner and tags agree

The default consent call must run before the Google tag. It sets every signal to denied:

gtag('consent', 'default', { 'ad_storage': 'denied', 'ad_user_data': 'denied', 'ad_personalization': 'denied', 'analytics_storage': 'denied' });

After a visitor chooses, the banner calls gtag('consent', 'update', {...}) with the corresponding granted and denied values. In basic mode, keep Google tags blocked until that choice too. If someone accepts Analytics but rejects Marketing, analytics can run; ad consent stays denied.

Many WordPress cookie banner plugins support Consent Mode v2, and Google-certified consent management platforms can pass the signals automatically when consent mode is enabled in their settings. Check your plugin’s own documentation for all four parameters. Don’t assume a banner labeled “GDPR compliant” handles them. If you block Google tags without consent mode, Google says it can’t verify consent choices, which may lead to data loss.

On a shop, don’t accidently block the cart while sorting this out. WooCommerce’s own cart and session cookies are necessary. If you’re planning wider WooCommerce shop work, put consent behavior on the same testing checklist as checkout.

Test it as a visitor, not an admin

Open a private window while logged out. Google Tag Assistant shows consent state by event, so check the initial page view and then check again after each choice. You can also use browser DevTools to inspect cookies:

  • Before clicking the banner, there should be no _ga cookies.
  • After Reject all, there should still be no _ga cookies.
  • After accepting only Analytics, _ga cookies may appear, but ad cookies shouldn’t.
  • With everything rejected, add an item to the cart and go through the checkout pages. The cart and session should still work.

Also look for analytics loaded from two places: a theme option, Site Kit, or an old GA snippet can fire outside the banner’s control. Marketing scripts such as the Meta pixel need to follow the Marketing choice. Add a small “Cookie settings” link in the footer so people can change their mind later. On a multilingual site, check each banner language. And test with caching enabled; a cached banner state can give a logged-out visitor the wrong view.

Payment security is a separate job, but it’s easy to overlook during a checkout test. My guide to securing WordPress when your shop takes payments covers that side. Another EU shop task, the WooCommerce withdrawal button, needs its own check rather than being buried in your cookie project.

Do this this week

  1. Open your site in a private window and write down the choices on the first banner layer. Can you reject as easily as you accept?
  2. Check that Analytics and Marketing have separate, off-by-default toggles, and that your plugin passes all four Consent Mode signals.
  3. Run the reject and Analytics-only tests in Tag Assistant or DevTools, then test cart and checkout with everything rejected.
  4. Check the footer for a way to reopen settings. If it’s missing, add one.

Start with that private-window test. Five minutes will tell you whether your visitors can actually say yes to stats and no to ads.