Consent and Tag Management

Step back from the configuration for a moment and look at what has actually been built across this module. A visitor opens a page and, without anybody watching, you learn which product they looked at, how far down they scrolled, what they put in the basket and where they gave up. That is genuinely remarkable, and familiarity makes it easy to forget how remarkable it is.

It is also, described plainly, a camera. Adobe Analytics is a very sophisticated closed-circuit system pointed at your website, recording what people do there so somebody can review the footage later.

Nobody objects to a camera in principle. What decides whether it is reasonable is where you put it.

Your website is your property, and it is not under your control

Install a camera inside your own house and no one has an argument with you. It is your property, your walls, your decision. Point that same camera at the shared garden outside, the one the whole society uses, and the situation changes completely. Same camera, same owner, same intention. Different place.

A website sits closer to the garden than to the house, and this is the part worth slowing down for.

The site is unquestionably yours. You paid for it, you built it, you decide what it says. But the moment it goes live it becomes something else as well: a space the public walks into. And a public space is owned by you without being controlled by you.

Visitors do not arrive to help you meet your targets. They arrive because they want something, and they will take whatever route to it suits them, ignoring the journey you carefully designed. If you want a property where you genuinely dictate what gets seen and which button gets pressed, that property exists. It is called an intranet, or a folder on your own disk. The instant the word public is attached, you have traded control for reach, and that trade is the whole business model of having a website at all.

Which leaves an obvious question. If it is public space, do you simply have no say over what happens there?

How the society gets its cameras anyway

Go back to the garden, because the answer is already there.

Suppose complaints start coming in. Things are going missing, there is trouble after dark, and residents want something done. So a meeting is held, the matter is discussed, and the members collectively agree to put cameras up.

The cameras go in. Nobody objects, and nothing about the space changed.

What changed is that permission was asked for and given. That is consent, and it is the mechanism by which control returns to an owner who had given it up. You do not get to monitor a public space because you own it. You get to monitor it because the people using it agreed you could.

Every technical thing in the rest of this section is machinery for that one idea. Cookies, extensions, data elements and rules are all just the plumbing that carries a yes or a no from a visitor to a tracking call.

How the industry arrived at this

It is worth knowing that this was not always the arrangement, because understanding why the rules appeared makes them much easier to work with.

In the earlier era of digital measurement, visitors had no say at all. There was also far less to have a say about. A page view, a referrer, a browser version. Useful, and hardly intrusive.

Then the systems got better. They began capturing far more, much of it invisible to the person generating it, and then they began connecting it. Behaviour on one site joined to behaviour on another, joined to a profile, joined to an advertising platform. None of that was criminal, and most of it was done by people trying to do their jobs well. It was simply happening without anyone having asked.

Regulation followed capability, as it generally does. GDPR and its equivalents around the world settled the question in the visitor's favour: the person generating the data decides who is allowed to consume it, and they are entitled to refuse outright. That right holds unless someone is doing something illegal, and your site is presumably not in that category. That assumption is doing some quiet work, but let it stand.

The middle path, and what this section is for

Two positions get argued loudly and neither is useful.

The first says collect nothing, or as close to nothing as possible. That position ends the conversation, because measurement is the entire reason Adobe Analytics is on the page. A site nobody can understand cannot be improved for the people using it.

The second says collect everything and treat the banner as a legal formality to be clicked past. That position ends differently, in a review nobody enjoys.

The middle path is the park. Ask, and act on the answer.

So the practical question, and the rest of this section, is mechanical: how the answer is captured, how it reaches Adobe, and how collection behaves once it arrives.

Three systems, three jobs, and none of them overlap

Before any of it works, one boundary has to be clear, because misunderstanding it is the most common design-stage failure.

Adobe states the boundary explicitly about its own tooling: the Opt-in service neither gathers consent preferences nor stores them. It acts on a decision that something else captured. Teams that expect Adobe to run their banner discover this late, usually after the design is signed off.

Choosing that other system is a decision in its own right, and the landscape is covered in Tag Management Systems, where consent-first vendors are one of the axes that separate the options.

What your consent platform actually hands you

Here is where the abstraction ends and something concrete arrives, because a consent platform does not send you a message. It writes a cookie, and your job is to read it.

OneTrust, which is the one you are most likely to meet, writes a first-party cookie named OptanonConsent. Decode it and the useful part looks like this:

groups=C0001:1,C0002:0,C0003:1,C0004:1

Four categories, each with a 1 for granted or a 0 for refused. That single string is the visitor's answer, and every consent decision your tags make comes from reading it.

The mapping is the part that matters and the part most often done carelessly. An analytics beacon is measurement, so it belongs to Performance. A marketing pixel is advertising, so it belongs to Targeting. Gating your Adobe Analytics call on the Targeting category means a visitor who accepted measurement but declined advertising vanishes from your reports, which is both a data loss and a misrepresentation of what they agreed to.

A fifth category for social media appears in some configurations, and organisations are free to define their own. Read the categories your own consent platform is configured with rather than assuming the defaults, because they are set by whoever implemented the banner and that was often not the analytics team.

Building it in Launch: one data element, then a condition

Now the practical work, and it is smaller than people expect. Two pieces of Launch machinery you already know do the whole job.

First, a data element whose only responsibility is to answer one question: has this visitor granted the Performance category? Custom Code type, returning a boolean.

var raw = document.cookie
  .split('; ')
  .filter(function (c) { return c.indexOf('OptanonConsent=') === 0; })[0];

// No cookie means the visitor has not answered yet.
// Treat that as "no", never as "yes".
if (!raw) { return false; }

return decodeURIComponent(raw).indexOf('C0002:1') !== -1;

That is the entire integration. One data element, readable by anybody, with the consent platform's specifics contained in a single place rather than scattered through twenty rules.

Second, a condition on the rule that sends the beacon. Rules already makes this case: a condition turns a rule into something self-policing, running only when permission is present.

Repeat the pattern per category rather than per tag. One data element for Performance gates every page view and link tracking rule you own. One for Targeting gates the marketing pixels. When the consent platform changes, and it will, you edit two data elements instead of auditing the property.

Ship this the way you ship anything else. A consent change is precisely the kind of edit that deserves a full pass through development and staging environments before it reaches production, because the failure mode is invisible in reports and the publishing workflow exists for changes with exactly this risk profile.

The window before anybody has answered

The condition approach is correct and it has one limit, which is timing rather than logic.

A condition can only evaluate what exists at the moment it runs. On a first visit, when the page-load rule fires, the banner is still being displayed and the visitor has not touched it. The cookie is absent, the data element returns false, the rule does not run. Four seconds later they click Accept, and nothing goes back for the page view that was skipped.

Settling the window at the library level

Conditions enforce a decision that already exists. Something else has to govern the period before one does, and both Adobe collection paths provide it.

The Web SDK declares a default consent level, configured on its extension, which tells the library how to behave while it waits.

Pending is the value worth understanding, because it is the only one that does not force a choice between the obligation and the data. Nothing leaves the browser without permission, and nothing is discarded before the visitor has spoken. Accept, and the queued page view is released. Refuse, and it is dropped without a request ever being made.

The value can come from a data element rather than a fixed setting, which is how a single property serves several jurisdictions: pending in the European Union, in where prior consent is not required.

Implementations still on AppMeasurement have the older equivalent: the Opt-in service, a library bundled with the Experience Cloud ID service, exposed as adobe.optIn and configured through its own extension. Its distinguishing feature is granularity, gating Analytics, Target and Audience Manager separately, which maps neatly onto the category structure your consent platform already uses.

The setting that is wrong by default for a large part of the world

One radio button carries more risk than everything else in this section combined.

The permissive default collects events before the visitor has agreed to anything. It produces complete data, it makes a new implementation look like it is working, and for any jurisdiction requiring prior consent it is the wrong choice. Adobe's own guidance for organisations needing explicit consent is to use Out or Pending.

What refusal does to your numbers, and to your bill

Two consequences follow from a visitor declining, and both are worth predicting before somebody asks.

The first is identity. No consent generally means no cookie, no cookie means no persistent identifier, and no identifier means the visitor cannot be recognised on the next page, let alone the next visit. Every page view becomes a first visit by a new person. A site with a strict posture and a high refusal rate will show unique visitors climbing, visits per visitor stuck near one, and journeys collapsing into single-page sessions. That is not a tagging fault, it is the arithmetic of identity that was never allowed to persist, and the mechanism sits in Experience Cloud ID (ECID) and First-Party Cookies.

The second is cheerier. A call that never fires is a call you never pay for. Unlike bot traffic, which is filtered only after Adobe has received and metered the hit, consent enforcement happens in the browser before anything is sent. Refusals genuinely reduce your server call volume, which is the rare case where doing the right thing also shows up on an invoice.

What you have now

The camera is not the problem and never was. Where you point it, and whether the people in front of it agreed, is the whole question. A website is property you own and do not control, and consent is the mechanism that hands a measure of that control back, exactly as it does for a society that wants cameras in its shared garden.

Underneath that idea the machinery is unremarkable, which is the good news. Your consent platform writes a cookie. One data element reads the category you care about and answers true or false, defaulting to false when nobody has answered. Conditions on your rules honour it. A library-level setting governs the seconds before an answer exists, and Pending is the value that refuses to choose between the obligation and the data.

The failure modes are quiet, as they usually are here. A rule that declines to run reports nothing. A permissive default produces beautiful, complete, unpermitted data. Neither shows up in a dashboard, so neither is found by looking at one.

That closes the Launch story. From the property that holds everything through to the visitor's permission to be measured at all, the implementation is now built, shipped, and allowed to run. What it produces is a stream of tracking calls, and understanding exactly what those calls contain, what they cost and how they identify a person is where Page View Tracking begins.