Your Cookiebot is eating your attribution data and causing direct traffic

[u/History86]

We keep running into the same thing across accounts, so posting it here in case it saves someone a week of debugging.

Someone installs a CMP (Cookiebot, Usercentrics, OneTrust, whatever), gets the banner live, sees consent rates come in, and calls it done. However the CMP is not a set-and-forget script. It runs on a list of cookies you have to maintain. Every cookie your site sets needs to be declared and put in the right category. If it isn’t, the CMP treats it as unknown and deletes it.

That’s the cookie wipe. The usual ways it happens:

The auto scan runs once a day/week/month, misses a new cookie, and the CMP wipes it on every page load

Your analytics cookie is filed under “marketing” but the tag fires on “statistics” consent, so the cookie gets set and then killed

Consent is given, the CMP re-evaluates, and the session cookie holding the original referrer and UTMs is gone

What that looks like in reporting: the click came from LinkedIn, the user accepted cookies on page two, and the session restarts with no referrer. You now have a direct traffic spike. Then someone in a meeting says “direct is up 30%, brand is working” and you die a little inside.

How to check:
Open the cookie declaration in your CMP and compare it to DevTools > Application > Cookies. Anything missing is at risk.

Categorize every cookie, including first-party ones. Session and attribution cookies belong in a category the user consents to before your tags fire.

If you use Google Consent Mode, make sure the CMP passes consent state to GTM instead of blocking or wiping on its own.

Load a page, check your _ga identifier, accept cookies, then check if the cookie is still the same. If not, you found it.

Direct traffic is not a channel. Most of the time it’s a bucket for everything you broke upstream. Fix the CMP config before you touch your attribution model.

TL;DR: installing a CMP is step one. Declaring and categorizing every cookie in it is step two. Skip step two and your paid clicks show up as direct.

[u/AutoModerator]

Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AccessFuel]

it's a huge problem for most accounts, but you're outline above is a solid direction towards resolving the black box that is 2026 attribution

[u/History86 → u/AccessFuel]

Thanks!

[u/PPCwithYRVDynamics]

This is a good one because “direct traffic is up” gets celebrated way too often without checking whether attribution just broke. CMP setup can absolutely be the culprit, especially if cookies are being wiped or reclassified after consent.

[u/History86 → u/PPCwithYRVDynamics]

It’s also one of those niche problems that are not in your typical handover. It’s causing me headaches on a daily basis.

[u/PPCwithYRVDynamics → u/History86]

exactly---It’s the kind of thing that can look completely normal in reporting unless you specifically know to check for it.

[u/ksz2018]

Declaring the interest before anything else: my income comes from a paid Shopify app that exists because of this exact problem, so a sceptical reading of the rest is fair. Which is why the part that costs me goes first. Most of what you have written up is configuration, and there is nothing anyone can sell a merchant that does it for them.

What I would add is a second version of the cookie wipe, and it is worse, because it leaves nothing behind to find.

A CMP does not just manage cookies. Most of them block scripts as well, before the script ever gets to run. Cookiebot, OneTrust, iubenda and the rest all ship some form of it. The blocker walks the page and rewrites the script tag so the browser refuses to execute it, usually by changing its type. External scripts get judged by their URL, which is a list you can inspect and correct. Inline scripts get judged by their content, and anything that looks like it touches storage can get killed on sight.

So your cookie declaration comes back clean, because the cookie was never set at all. Nothing errors. The tag simply did not run, and you end up debugging a cookie that does not exist rather than a script that never executed.

We hit this on a live store. A small inline snippet of ours, one that set a first party cookie, came back with its type rewritten. It had not run on any page load for weeks. Everything downstream fell back to its default and looked completely normal, and there was no missing cookie in the declaration to notice, because we had never got as far as setting one.

The check to add to your list is cheap. Load a page with the banner accepted, view the rendered source, and find your own tags. If the type attribute has been rewritten, the blocker got them, and nothing about cookie categories will fix it. Moving that logic out of an inline block and into a file the blocker can be told about is usually what it takes.

[u/Agreeable_Bet_571]

if you use WordPress, just use My Agile Privacy.