Reject cookies, keep the lead source: the seam that makes first-touch legal

A buyer clicks a Google Ads campaign, lands on the development page, reads for a minute, and dismisses the cookie banner with Reject all. Ten minutes later they fill in the enquiry form. When that lead reaches the CRM, what does the source field say?

On most sites it says direct / none, which is a polite way of saying the marketing team just paid for a click they can no longer prove they bought. The received wisdom explains this away: the visitor rejected cookies, attribution is a cookie thing, so of course the source is gone. That sentence sounds airtight and it is quietly wrong. It fuses two decisions the law keeps separate, and untangling them is how the same rejected banner still hands you the campaign that produced the lead.

The switch that isn't one switch

The buried assumption is that a cookie banner is a single on/off control over all tracking. Accept, and everything works; reject, and everything stops, attribution included. Teams build to that mental model, then either nag visitors with a consent wall or shrug and eat blind direct / none on half their enquiries.

But "attribution" is not one thing that lives in one place. A visitor's source can sit in three different storage locations, each with a different legal trigger and a different lifespan. Collapse them into one bucket and you gate the whole lot behind consent, throwing away data the law never asked you to withhold. Split them by where the data physically lives and the picture changes: some of it was never the banner's business to begin with.

Article 5(3) gates the device, not the deal

Start from what the banner is actually for. In the EU the cookie banner exists because of the ePrivacy Directive, whose Article 5(3) requires consent before you may store information on, or gain access to information already stored in, a user's terminal equipment (EUR-Lex, ePrivacy Directive 2002/58/EC Art. 5(3)). Read the trigger precisely: it fires on storing or reading a device. It says nothing about your right to process a piece of data you have lawfully received.

That is the distinction the whole post turns on. GDPR governs the processing of personal data and asks for a lawful basis. ePrivacy Art. 5(3) governs the act of touching the visitor's device and asks for consent. A cookie banner is the ePrivacy gate, not the GDPR one. The same article carries a carve-out that matters here: consent is not required for storage or access that is strictly necessary to provide a service the user has explicitly requested. Sending an enquiry is such a service, and that carve-out is the seam this design is built on.

Three tiers, three gates

Here is the same attribution data, split by where it lives and what gates it. Naming the tiers is the point; a single word like "attribution" hides exactly the distinction that keeps the source alive.

The rejection cost, stated plainly: you lose the stickiness across sessions, the 90-day first-touch cookie and the returning-visitor marker. You do not lose the source of the conversion that actually happened. When a visitor who rejected cookies submits the form in the same visit, the session-entry touch is still in sessionStorage, and it rides out with the enquiry. The lead lands with its real source; only the cross-visit memory is gone.

Why the form POST isn't tracking

This is the move most teams miss. When the enquiry form submits, it carries first-touch and last-touch source as fields inside that one POST, and it does so regardless of consent state. That is lawful, and not by loophole.

Cross-site tracking is the thing consent exists to gate: reading and persisting identifiers on someone's device to follow them around. A single form submission is the opposite. The attribution rides inside a message the visitor has chosen to send you — they filled in the form and clicked send. Reading sessionStorage that this same page wrote, to populate a field in the enquiry the user is actively trying to submit, is strictly necessary to that requested service. It writes nothing new to the device and it persists nothing. The converting POST is one lawful message; the sticky cookies behind it are a separate, gated thing.

Denied-by-default, and why four categories not one

The cookies that are gated need a mechanism, and the standard one is Google Consent Mode v2. The tags load, but until consent arrives they run in a restricted state rather than dropping identifiers. You set the denied defaults in the page <head>, before the GTM loader, so nothing fires first and asks permission after:

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

The wait_for_update: 500 gives your banner half a second to restore a saved choice before tags decide how to behave, and ads_data_redaction: true alongside it strips ad identifiers from network calls while consent is denied. The saved choice comes from a first-party vinode_consent cookie (1-year, SameSite=Lax), read on load so a returning visitor who already accepted never sees a denied-to-granted flash. Google's own reference for these signals and the head-first ordering is the Consent Mode developer documentation.

Why four categories and not one accept/reject? Because consent under GDPR is purpose-specific, not a blanket yes. Recital 32 is explicit that consent should cover all processing activities carried out for the same purpose, and separate consent should be given for different purposes (GDPR Recital 32). Marketing consent and analytics consent are different purposes, so they are different switches. That maps cleanly onto the Consent Mode signals:

That marketing-is-not-analytics split is purpose-limitation doing real work, not UX decoration. A visitor who accepts analytics and rejects marketing has told you two different things, and the four-signal map is what lets you obey both. The active-choice requirement behind all of it has teeth: the Court of Justice held in the Planet49 case that consent is not validly given by a pre-ticked box a user must deselect — consent must be an active, affirmative act (EUR-Lex, Case C-673/17 Planet49). Default-denied honours that: nothing is granted until the visitor grants it.

First-party by construction

Notice what the source itself is derived from: never a third-party pixel. Source, medium, and campaign come from two first-party signals the browser already hands the page — document.referrer and the utm_* and click-id parameters (gclid, fbclid) on the landing URL. When a UTM tag is present it overrides the referrer, because an explicit campaign tag is a stronger signal of intent than where the click happened to come from.

This is not just cleaner privacy hygiene; it is what keeps attribution alive as the ground shifts under it. Third-party cookies are ending — a visitor arriving from a Google Ads click with gclid and utm_campaign on the URL is fully attributable with zero third-party storage, because the campaign identity is sitting in the URL the visitor themselves navigated to. a UTM-tagged campaign outlives both the rejected banner and the third-party cookie's demise, for the same underlying reason: it never depended on anyone's device but the one delivering the message.

There is one more mechanic that closes the loop. Say the visitor first rejected the banner, so their entry touch sits only in vinode_attr_session, and then, a few clicks later, they accept. You do not want to lose the touch they arrived with, and you do not want to force a page reload. A vinode:consentchange event fires on accept: the page re-captures attribution in place, and promotes the pending sessionStorage first-touch into the sticky 90-day vinode_attr cookie. The first-touch they came in with becomes durable at the moment they grant permission for it to be, and not a second before.

Poland vs Riyadh: portable logic, local statutes

The architecture is portable; the statutes are not. Kozielska Park and Malinowskiego are Polish developments, squarely under GDPR and the ePrivacy regime, so Art. 5(3), Recital 32, and Planet49 are the live citations. Safa Al Fursan is a 528-unit scheme in Riyadh, outside GDPR entirely, where those articles simply do not apply.

The tiered design does not change between them. Session-entry touch as strictly-necessary, the form POST carrying source inside the enquiry, persistent cookies gated behind a purpose-specific banner — that logic is sound engineering anywhere, because it maps storage lifetime to consent rather than treating all tracking as one blob. What changes across the border is the citation you write above it, not the code you ship. Keep the seam, swap the statute for your local one.

The compliant enquiry flow in one panel

Put the tiers back together and the flow reads simply. The visitor arrives; the page derives source from referrer and UTM and writes the entry touch to sessionStorage, no consent needed. The banner sits denied-by-default. If the visitor submits the enquiry, the POST puts the entry and last touch into fields inside the message they chose to send, and the lead lands in the Back Panel CRM with its real source attached, consent or not. If and when the visitor accepts analytics, the sticky 90-day cookie and the returning marker come to life, and consentchange promotes the pending touch so nothing is lost.

That seam sits inside the enquiry form and the CRM record, and it is deliberately narrow. How the form itself is built to convert is its own craft; what you actually own and can export at contract exit is a separate question; and the behavioural source-to-deal-to-unit trail through the sales cycle is traced elsewhere. This post is only the banner seam — the point where a rejected cookie either loses your lead source or, designed right, doesn't.