Consent-first analytics: measuring marketing without breaking GDPR

Almost every cookie banner shares the same defect, and it is not a technicality: accepting is a big dark button, refusing is a grey link.

That difference in prominence is exactly what European regulators call out, with Spain's AEPD among the most explicit. Consent has to be as easy to refuse as it is to give. If withdrawing or refusing takes more clicks, or is less visible, it is not freely given consent.

This is about complying without going blind.

What is actually required

• Consent before setting. Nothing beyond strictly necessary may be written before the person says yes. Not a cookie, not a localStorage entry.
• Refusing as easy as accepting. Same visual weight, same number of clicks, same layer.
• Granularity by purpose. A single "accept all" is not enough: analytics and advertising are separate decisions.
• Withdrawal must be possible and simple, as easy as giving consent was.
• Clear information up front: which cookies, whose, what for, how long.
• Continuing to browse is not consent. Scrolling is not a yes.

The most common mistake: "strictly necessary"

The exemption is narrower than people think. "Strictly necessary" means necessary to deliver the service the person asked for, not necessary for your business.

A couple of things that get misfiled regularly:

• Attribution identifiers (gclid, fbclid, ttclid). These are advertising click identifiers issued by third parties. Attributing a lead is your need, not a service the visitor requested. They need consent.
• A persistent support-chat identifier created on page load, before anyone opens the chat. Loading the widget is not the same as using it.
• Analytics, except in narrow first-party aggregated cases.

If your banner classifies any of these as necessary, you are carrying avoidable risk.

How to keep measuring while complying

The interesting part: complying does not mean giving up attribution. It means designing it differently.

1. Hold in memory, persist on consent.

The classic problem: the campaign only exists on the landing URL, and if you wait for consent the person has already navigated and the parameters are gone.

The answer is not to write the cookie before asking. It is to read the parameters and keep them in memory, writing them only if the person accepts. Whoever refuses leaves nothing behind; whoever accepts keeps the campaign that brought them, even from a URL they have already left.

2. Registrable domains do not share cookies.

A cookie on .yourcompany.es never reaches app.yourcompany.com. They are different registrable domains and nothing crosses. If your marketing site and your app live on different domains, attribution has to travel in the sign-up URL, not in a cookie.

3. Do not fake a fresh campaign click.

When you pass a campaign to another property, avoid raw utm_* parameters: you would be telling your analytics that a new click just happened, inventing sessions for a click that might be three weeks old. Use your own namespaced parameter and treat it as what it is: a join key, not a click.

4. Consent Mode and modelled measurement.

If you use Google Analytics or Ads, consent mode keeps aggregate signal from people who refuse without setting cookies. It does not replace the data, but it avoids the cliff edge in your reports.

An honest checklist

• Do accept and refuse have the same visual weight?
• Can someone refuse on the first layer, without opening "manage"?
• Is anything written before they decide? Check it in devtools: cookies, localStorage and sessionStorage.
• Does your cookie policy list the cookies you actually set? Declaring a vendor's cookies you never installed is as wrong as omitting the ones you do.
• Can someone change their mind later, from somewhere visible?
• Are third-party scripts genuinely blocked until the yes, or merely muted?

That second-to-last point surprises people. It is common to find policies listing Facebook or DoubleClick cookies on sites that never installed either, inherited from a template. A policy describing a site that is not yours protects you from nothing.

The real cost of doing it properly

Yes, you will lose data: a share of your visitors will say no, and those people stop being individually measurable. That is the correct price.

What you get back is not only avoiding a fine. It is that the numbers you keep are real. A dashboard built on consent nobody gave is a dashboard that can vanish entirely the day someone reviews it.

Summary

• Refusing has to cost what accepting costs. Otherwise the consent is not valid.
• "Strictly necessary" means what the user asked for, not what your business needs.
• Attribution survives by being held in memory until consent.
• Declare the cookies you set, and only those.
• Check the browser state before signing off on anything: it is the only way to know what you actually write.