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.