My own consent system: $0 and two weekends

A do-it-yourself consent system: zero dollars and two weekends. Not because twenty bucks for a CMP hurts, but because I wanted the decision to come from the need and not the other way round. It also looked like a fun challenge - bolting consent onto a setup with no gtag and no web GTM. Here is what worked, what did not, and which of my own questions I closed along the way.

Consent mode has always been an awkward topic for me, and it still is, because it sits somewhere between marTech and law. Even when you understand how the consent signal travels to a vendor on the technical level, you’re never 100% sure your implementation is correct, because you’re not a lawyer. This article is mostly about my own under-the-hood experience: how I set up everything around consent, privacy, cookies, privacy policies and all of that. One disclaimer up front: I’m not a lawyer. Everything below is my experience and my reading of the rules, not advice to act on. Check it against your own case, and better yet, ask a proper lawyer.

I’m a worrier by nature, and even with zero traffic, back when the site was still being built, I already caught myself thinking I’d sleep better knowing I break nothing. Nobody is likely to go hunting for legal gaps in a home blog, but besides sleeping well I also wanted to tick a professional box next to the achievement “figure out consent from A to Z”.

Before we get into rules and signals, let me show what came out of it. The banner has two layers: the first one is a short explanation and three equal actions, the second one is categories with toggles and a list of cookies grouped by whoever sets them, each with a description and a lifetime. Everything below is about why it looks exactly like this.

Do I worry about data completeness?

Honestly, I used to worry a lot. These days the answer is closer to “not really”. Hand on heart, it still makes me uncomfortable to realise that analytics or ad platforms capture less than 100% of the signals: an ad blocker here, a rejected banner there, something else on top of that… I try not to think about it.

Back when I was setting consent up for the first time, I kept looking for ways to game the system. I read about cookieless pings, fingerprints, storing identifiers somewhere other than the user’s browser… In short, I wanted to keep getting signals from users even when they’d explicitly said no.

These days I’d rather act cleanly and not argue with my own conscience. For my own project I made the call: we keep it legit, with one grey area around cookieless pings. We respect the user’s decision on privacy and we keep the privacy policy up to date and written in human language, so the user isn’t confused even more (that one, by the way, is a requirement of article 12 of the GDPR: write in “clear and plain language”).

Whose laws do I fall under?

From the very beginning I planned to write in two languages, my native one and English. The second one is an obvious nod to worldwide reach, and my potential audience is predictably scattered all over the planet, though the focus is still mostly on America and Europe. And let’s be honest, professional terminology gets googled not only by native English speakers, I have that feeling.

Europe has the strictest requirements: until you give consent, the site has no right to record anything about you. America is simpler here. By default you’re allowed to be tracked, but at any moment you can tell them to stop.

So to begin with I split the world into three rough jurisdictions:

1. strict (opt-IN);
2. soft (opt-OUT);
3. free.

The first one is (mostly) the European zone, the second one is America. The rest of the world is the fallback.

I went a bit overboard here and decided to make your life easier too. For convenience I collected all the jurisdictions in one table. If you spot an error or something inaccurate, please tell me.

So you should start from where your target audience, your visitors, come from. The mode has already been covered above: strict means forbidden until consent is given, soft means allowed until the user objects. The last column matters too, because every jurisdiction has its own quirks.

* The UK and Japan are soft by law, but in my case it works out strict: the first-party statistics exemption falls away the moment data leaves for someone else, and mine leaves for Google.

** Australia does not apply right now: the 3M AUD turnover threshold exempts me. The exemption is being removed on 10.12.2026, after which the mode becomes soft.

There are a lot of jurisdictions and a lot of acts, but they are mostly about the same thing. Work out the logic of your site and your consent banner for the three categories (strict, soft, free) and that should be entirely enough. At least that is the road I picked for myself and for this blog.

Do I need to buy a CMP?

At zero traffic we are of course not talking about four bags of money (a local meme), the price is 10-20 dollars for some minimal paid plan. But the main question is not even about money.

Everything in my blog revolves around the DIY concept, and I am definitely not a fan of hanging 100500 pieces of js code of unclear origin onto a site (remember, I deliberately gave up web GTM too). It is not even about the scale of this blog as a project: at my main job we are also building an internal CMP. Why? Because off-the-shelf solutions are not flexible and often come loaded with all sorts of junk sold as extra features. So we are planning to move off an Enterprise solution onto our own, in-house one soon.

Back to the blog. If I put it as a list, here are the reasons that pushed me towards my own solution:

1. the DIY concept, as the most flexible thing to customise later;
2. one less subscription, saved money;
3. the banner script of a ready-made CMP weighs as much as 5 of my pages (roughly);
4. objectively, I still do not get what technology CMP companies charge for, other than it coming out of the box;
5. the option to build a custom system of banner revisions and a signature store for every individual user (an interesting one, more on it later);
6. it is not obvious at first glance how to integrate a ready-made solution with pure server-side tracking on the site;

If you thought I went through some agony of choice, no: the decision took about three minutes and went to the homemade one. So the consent system cost 0 dollars in total, and development and rollout took about 2 weekend days.

Where the signal comes from and how it reaches the vendor

What follows is a bit of reference material, but it is the important kind worth paying attention to (in my opinion). Also keep in mind that my particular tracking setup differs from 99% of sites: the gtag mentioned below does not exist on mine.

The consent signal is first created by that same gtag, the script that, in simple words, holds up all the tracking of Google services, builds the payload and sends hits from the browser.

Then, when the user interacts with the banner, a new signal is created. These signals travel from the user’s browser to the vendor inside the payload, in four parameters:

1. gcd (Google Consent Data)
2. gcs (Google Consent Status / State /)
3. npa (Non-personalized Ads)
4. dma (Digital Markets Act)

Worth noting: Google published an official expansion only for NPA, the rest are pure guesses from the community.

GCD

The most informative parameter, its values look like 13t3t3t3t5l1 (just an example). Like the rest, it is passed with every event and carries the user’s current consent state. Inside it there is:

1. the format version
2. four pairs of characters, one per consent type
3. 3 service characters

I am not even going to suggest memorising it, but if you are curious, have a closer look at the cheat sheet I put together for you. I do not keep this in my head myself, and you probably do not need to either.

If it is still unclear, you can try the decoder: you paste a gcd value and get an explanation of the user’s current consent state in human language.

GCS

I do not really see much point in gcs existing at all, since it is fully derived from the value of gcd and carries no additional information. The only use for it I have seen is in custom tag and variable templates in the server container.

Still, let us look at what gets passed there. Nine unique values in total:

Nine is exactly what you get: two consent types, three states each - granted, denied, not set.

One thing is worth knowing, and other write-ups do not have it. The “not set” state (the dash) and the “denied” state (the zero) do not come from where you would think. If a permission was inferred implicitly, gcs shows a dash, that is, “nothing is known”. And if a denial was inferred implicitly, it shows a zero, that is, “denied”. Asymmetric: an implicit yes hides, an implicit no gets announced. Why it works that way the code does not say, it just does.

But again, this is not something worth memorising.

NPA & DMA

NPA, Non-personalized Ads, is the only parameter that works inside out, in reverse. It is an advertising parameter telling Google to show ads blind, that is, without using what it already knows about the user. A one in the value turns this mode on, a zero is the default. So with npa = 1 the following will NOT work:

1. audience targeting
2. demographic targeting
3. matching by the user’s past behaviour (search queries, visited sites, geo history and so on)
4. Google does not use new information about the user to pick ads

Worth saying as well that this parameter brings nothing new: everything is already baked into gcd.

DMA, Digital Markets Act, is a parameter named after a law, not after a technology. It concerns neither me, nor you, nor even your users. It concerns the big “players”:

1. Google
2. Apple
3. Meta
4. Amazon
5. Microsoft;
6. ByteDance (TikTok);
7. Booking.com

This is a European competition act, and the gist of it is: a large platform may not stitch data about a user across its own services without that user’s consent. For example: you searched for “car rental in Barcelona”, and an hour later you opened YouTube. Without your consent Google has no right to show you rental ads there, because that would mean putting together what it knows about you from two of its own services. With consent it does. That is exactly where the ad_user_data and ad_personalization flags came from.

dma = 1 is set when (at the same time):

1. the consent system has declared that TCF is in use OR advertiser consent mode;
2. the consent system has reported that it considers the traffic to fall under GDPR;

Mine is always zero, because the first condition never holds.

To sum up, only two of the four parameters stand on their own: gcd and dma. gcs and npa can be derived from the value of gcd.

How are users who hit Reject All tracked?

Some notes here on so-called cookieless hits. Essentially these are the same requests as with consent given, except that they carry no persistent information (user_pseudo_id, session_id and so on) that would let you tie the requests together and associate them with a particular user.

A word on IP separately: not sending it is impossible in principle, because it is part of any http request. But sending != automatically recording. Which is what I do: if the user has not consented yet, the browser sends the IP, but on my side I simply do not read it and do not write it down.

Six parameters also do not make it into a cookieless ping:

All six are derived from a cookie, and when consent is refused there is no cookie. Sending them would mean inventing a session for a person I do not recognise.

Let me put a separate emphasis on cid. That is client_id (user_pseudo_id), the browser identifier. Users are counted by it. With consent this identifier gets written into a cookie. When there is no consent, we cannot write them, yet they are generated anyway. There is a catch: this identifier is generated anew on every page load. Which makes stitching one person’s events into a single user journey impossible. A second catch: within one page load the identifier stays the same, so events happening inside a single page load share a common, but still temporary cid (client_id or user_pseudo_id).

Google and its grey area

When a person hits “Reject” in the cookie banner, gtag does not actually go quiet. The logic on this site, described above, is built on the very same mechanism: events are sent somewhat trimmed down, and cookies are not written. Google does not hide this approach at all and writes it in plain text:

Google’s defence of that decision rests on three points:

1. “we write nothing to the user’s device”;
2. “the IP is needed to determine the user’s geo. We do not store it afterwards”;
3. “the person cannot be identified from the data that is sent anyway”;

It even looks safe at first. But ePrivacy was not written only about storing cookies. It, and specifically article 5(3) of Directive 2002/58/EC, is about two different actions: writing something to the user’s device and taking something from the device. Both are forbidden, and one of the two conditions is enough.

That is where the construction hides. “We write nothing” calmly closes the first action while flatly ignoring the second. And about the second one the regulators have been unambiguous. If the information “is sent back over the network to a server”, that is access, and the fact that it was computed right on the device changes nothing.

Put differently: the law looks not at where the computation happened, but at whether the data left the device. A script can measure the screen resolution in the browser without calling anywhere, and as long as the number stays there, there are no questions. The moment it goes to a server, that is already “gaining access”, and article 5(3) applies.

A separate word on the IP. “We do not store it” is an answer to a different question. The law asks precisely about obtaining. You can store nothing, but access has already happened.

“The person cannot be identified” - here the wording matters: “cannot directly identify an individual”. The key word is “directly”. Look, in its own documentation Google lists what goes into the ping: user agent, screen resolution, IP, referrer, time and a random number for every page load. Look closely and that set is enough to fingerprint a device. And Google does not say it does anything like that, it says a person cannot be identified directly. Formally it is not lying, because each hit parameter on its own really means nothing. Their value appears when they arrive together.

At the same time, no regulator has so far called this scheme a violation. One text of the law, article 5(3) of ePrivacy, two readings: the regulator’s and Google’s. And nobody has yet gone and tested whose interpretation is the more correct one.

So I have just taken apart the arguments I am standing on myself. My grey area is borrowed from Google, and I take the risk knowingly.

So when a user refuses, he still gets tracked on my site. Yes, with limits and with no way to recognise him tomorrow, but tracked. This is probably where my conscience draws the line, and I feel better saying it out loud than keeping quiet about it.

What are the requirements for a banner?

Back when our team was setting up consent mode at work with a pricey CMP, I remember that endless stream of questions - “what about this”, “how about that” - about what has to be shown in the banner itself, and in what form.

Let me go through the list of questions I asked myself and thought I had to close. The answers are right under the spoilers:

Taking inventory of the cookie list

So the main question here is not “how to compile the list”, but “where to take it from”.

The list comes from the tools, which is obvious: do you run Google Ads? You go to Google’s policy and take all the cookies that relate to advertising. That way a new cookie cannot appear for your users from a service you never installed. But there is a limit here: such a description gives you the full list of sources, yet does not guarantee the full list of cookies. A vendor can quietly add a new one, and you will not catch that in time (you are not going to visit their data processing policy page every day).

I solved this with one cookie dictionary and three checks. The dictionary is a file describing every cookie: name, category, who writes it, who the data goes to, how long it lives. From there the list is pulled into the second layer of the cookie banner, and into the privacy policy page as well. Going out of sync is ruled out, because there is a single source.

Then come the checks against fact. Each answers its own question.

Check No. 1: the code, or what can be set at all. On every site build the check reads the code and assembles the list of cookies that could be set. Every cookie name from that list has to be found in the dictionary, and the other way round: if a record exists but there is no such cookie in the code, we get a red check.

Check No. 2: the browser, or what got set not from the server. A real browser run (using Playwright) over the built static files: pages are served by a file server, and my Cloudflare Worker is obviously unavailable at that point. So what gets recorded is exclusively what the browser sets, not what the server does.

Check No. 3: the raw data warehouse, cookie names (without values) that actually got set for live people. And cookies from there have to be in the dictionary. An unknown cookie shows up in the warehouse and the next run of the warehouse checks lights up red.

None of these checks is complete on its own: the code does not know what actually ran, the browser only sees the scenarios written in advance, and the warehouse shows the list after the fact. Together they cover three different blind spots, and as long as there are no foreign scripts on my site, these three will be enough for me.

One last thing: I even have versioning, both of the cookie list and of the banner with the policy. If I make a change to the current cookie list, the version of the banner and of the policy change automatically, since the cookie list is an inseparable part of them.

The consent log, or how to protect yourself legally

Three words that keep coming up below. So we do not get confused:

1. Signature - one answer from one person: what they allowed, when, from which page and in which mode. Sits in its own file, and it is the evidence;
2. Revision - the state of what was shown to them: the cookie list, the consent window together with its look and buttons, the text of the privacy policy. Any of that changed and a new revision appears;
3. Fingerprint - eight characters naming a revision. A signature points at revisions by fingerprints rather than retelling their content.

What the law requires

Article 7(1) of the GDPR (in more human language): the data owner has to be able to prove that a particular person gave consent. The law does not say by what means.

The EDPB in its guidelines on consent, clause 107: “The GDPR does not prescribe exactly how this must be done”. In the same place there is the answer to how long this evidence should be kept: as long as the data is processed, the duty to show the consent for processing that data stands too.

The CNIL additionally lists suitable options:

1. A code fingerprint with a timestamp;
2. A screenshot with the banner;
3. External third-party audits;
4. A settings history in the CMP;

There is nothing like a personal “my data” page in that list, but I still wanted to let everyone look at their own signature.

Revisions of the banner and the privacy policy

A record without the version of the text shown to the person proves nothing, in my opinion. That is why every signature in my system carries three revision fingerprints:

1. the version of the cookie dictionary;
2. the version of the banner;
3. the version of the privacy policy

two variants each, one per language. A fingerprint is eight characters computed from the text itself, one way only (a hash). The revision itself is stored alongside it, otherwise you end up with a key and no lock.

The privacy policy version got updated, a new record appeared in the warehouse, and every signature after that will point at the new revision. Same with the cookies and the banner. Worth noting separately: since the cookie list is part of both the banner and the policy, updating the list automatically versions all three entities at once.

How I store each individual user’s consent

The log stores signatures. On the user’s side their subject identifier (subject_id) is kept in the _ozr cookie with Path=/_consent/, meaning the browser only writes it for that service address. Outside that path the cookie does not exist at all. So this segmentation rules out subject_id ever landing in analytics data.

The signature itself is nineteen fields:

On the signature page there is one line that does not exist in the signature at all: Analytics. Many will recognise our good old client_id in it, also known as user_pseudo_id. It is not in the signature itself: there you only get the signature number, the person’s number, the decision, the mode and country, the language, three revision fingerprints and the dates. It is the signature page that shows it, and only at the moment you opened that page. It is needed because a “delete my data” request concerns not the consent log but the event warehouse, and there a person is found by exactly this number and by no other.

This is the thinnest spot in the whole scheme. The signature number lives in the consent log, the client_id lives in the event warehouse. While they stay apart, the warehouse remains impersonal: just browsers with no people attached. Write those two ids side by side even once and every event becomes an event of a specific person who once clicked a button in my window.

That is why the page “show my consent record” shows both numbers side by side and stores neither. It is the only screen where they meet, and the meeting lasts exactly as long as you are reading that page. The view of this page does not go into analytics either, otherwise I would be doing the very thing I argue against.

How this gets pulled out when needed

The scenario is simple. I get an email asking to show what the user agreed to and when. The email has a copy-paste from the “show my consent record” page. By the signature number I find their file, and in it three fingerprints: of the cookie dictionary, of the banner and of the policy. Then three lookups in the store, one per fingerprint.

The policy arrives as full text, with the date the revision first appeared next to it. The dictionary arrives as the list of cookies shown in that revision. The banner arrives as two files: parts.json with the source texts of the window (the markup of both layers, the styling, the images, exactly what the server handed over to build the banner) and banner.html itself, assembled from them.

That last file is the thing everything was done for. It is self-contained: all the styling inside, not a single external reference. It opens without internet, a year later, on someone else’s computer, and shows the same banner with the same buttons and the same cookie table. The site may be rewritten three times by then, and the revision will not care.

And now about what makes this banner.html evidence rather than a picture. The evidence is not the banner itself, but the files next to it and the fingerprint computed from them. Anyone holding these files can recompute the fingerprint and compare it with the number written in the signature. Matches, and it is the same revision. Does not match, and it is the wrong one. Eight characters work here as a revision number, not as cryptographic protection: picking another text with the same short fingerprint is theoretically possible, so the evidence is the bundle “signature plus revision in my store”, not the strength of the number itself.

Instead of a conclusion

So what did I take away from building my own solution and writing this article?

In Europe the focus has to be on two laws, not one: GDPR + ePrivacy. The latter is about the device, both about writing to it (cookies) and about reading some information from it (headers, user agent and so on). The GDPR is about personal data and on what basis we process it.

These are different subjects, and confusing them creates half of the consent arguments in Europe. The rest of the world mostly leans on a single law (mostly, because there are exceptions).

Transparency does not grant rights. Telling people about the collection is a duty under article 13 of the GDPR. Having the right to collect is a separate question of legal basis: consent, contract or legitimate interest. Writing it in the policy and considering the matter closed is the most common substitution. The site honestly wrote that analytics is strictly necessary and calmed down at that. But a line in a policy does not create necessity: at the very first request to prove why analytics is necessary, that defence falls apart.

Of the four parameters that carry the consent signal through the veins of the payload, only two bring “added value”: gcd and dma. gcs and npa are derived from gcd.

Google does not go quiet on a refusal, and neither do I. That “greyness” of mine is borrowed, and I take the risk knowingly. Why? Because no regulator has called it a violation yet. So my conclusion is that for now it is “allowed, but carefully”.

Refusing in the banner has to be exactly as easy as agreeing. That is probably the single most important requirement for a banner, and it is about actions, not aesthetics. One click to agree and three to refuse through the second layer is already a violation. Colour is judged case by case, and regulators explicitly forbid only one thing: a button with unreadable text or outright weak contrast.

Cookie categories (the name of a category, the axis it is cut along) are not defined anywhere. The only thing defined is granularity: there has to be a way to refuse one thing and consent to another.

Four categories (necessary, functional, analytics, advertising) are more of a tradition than a requirement. And it surprises me that this particular set is the one that stuck. Google has three separate signals for advertising:

1. ad_storage - whether ad identifiers may be written;
2. ad_user_data - whether my data may be handed to it;
3. ad_personalization - whether I may be gathered into audiences.

I see no reason to forbid a site from recording the click id I arrived with, and at the same time I do not want to end up in somebody’s audience or hand Google my email, even as a hash. These are three different decisions, and in every banner I have opened they get switched off with one click under a shared name, “marketing”.

The reason, I suspect, is banal: more toggles, lower banner conversion. But nothing stops you from splitting “marketing” into two categories and letting the person choose more precisely. I would have done exactly that if I ran ads (for now I have one solid “marketing”).

Cookie Wall. Blocking the content until the person answers is seen by regulators as coercion: a choice under pressure is not a choice. Although there is no agreement between them here: the EDPB is categorical, while in France the blanket ban was overturned by the Council of State, and cases are considered individually there.

Oh, I have this feeling that even the conclusion needs a conclusion of its own, and there is still more in my head I would like to add. But I will stop here. All in all, I am very happy with the result of this work and with how deep I got to dig. If you have questions or suggestions, please use the button below.