Adobe Gives You a Consent Switch. Most Teams Ignore It.
Adobe Analytics is different from a lot of the tags you gate. The modern Adobe Web SDK, the library that ships as the alloy function, has a genuine consent mechanism built in. You can tell it to hold everything until a visitor decides. Yet plenty of implementations still drop the library on the page with consent wide open, collect a full session, and only then show a banner. That's a compliance gap you can close with two commands, so let's close it.
Two things need to be true before Adobe Analytics is lawful in the EU. The ePrivacy rule (Article 5(3) of Directive 2002/58/EC) requires prior consent before any non-essential cookie or identifier is stored on or read from a device. The GDPR requires a lawful basis for processing the personal data that follows. Adobe's analytics cookies and the Experience Cloud ID are not strictly necessary, so both rules point to the same place: get consent first, then collect.
What Adobe Actually Stores
The Web SDK writes an Experience Cloud ID (the ECID) into a first-party cookie named with a kndctr_ prefix, plus a handful of state cookies. The legacy AppMeasurement library sets the older AMCV_, s_cc, and s_sq cookies. None of these are essential for the site to work. They exist to recognize the visitor and stitch a session together, which is exactly the kind of identifier Article 5(3) covers.
| Identifier | Set by | Purpose |
|---|---|---|
| kndctr_... (ECID) | Web SDK / alloy | Experience Cloud ID that identifies the visitor across Adobe products |
| AMCV_... | AppMeasurement (legacy) | Stores the Marketing Cloud visitor ID |
| s_cc | AppMeasurement | Checks whether cookies are enabled |
| s_sq | AppMeasurement | Records the previous link clicked, for ClickMap |
The Web SDK Way: defaultConsent and setConsent
The clean approach uses two Web SDK commands. When you configure alloy, set defaultConsent to pending. That value accepts only three settings: in, out, or pending. With pending, the SDK queues events in memory instead of sending them, and it holds off on the identifier until the visitor chooses. When your banner records a decision, you call setConsent. Grant it, and the queued events flush to Adobe. Deny it, and the queue is discarded.
// 1. Configure the SDK to wait for a decision.
alloy("configure", {
datastreamId: "YOUR_DATASTREAM_ID",
orgId: "YOUR_ORG_ID@AdobeOrg",
defaultConsent: "pending" // hold events, no ECID yet
});
// 2. When your banner captures the choice, resolve it.
function onConsentDecision(granted) {
alloy("setConsent", {
consent: [{
standard: "Adobe",
version: "1.0",
value: { general: granted ? "in" : "out" }
}]
});
}
// granted === true -> queued events send, ECID is set
// granted === false -> queued events are dropped"Pending" Queues, It Doesn't Persist
Two details trip people up. The queued events live in memory and do not survive a page reload, so if a visitor clicks through to a second page before deciding, the first page's queued hits are gone. And defaultConsent itself does not persist between page loads, only the resolved decision from setConsent does. So you set defaultConsent: pending on every page and replay the stored decision as soon as your banner reads it back from storage.
The Legacy AppMeasurement Way: Block the Load
If you're still on the older AppMeasurement library, or Adobe Analytics deployed through the classic Analytics extension in Adobe Tags, there is no in-memory pending queue to lean on. The library starts working the moment it runs. So the reliable pattern is the one you use for any tag with no native consent mode: don't put the script on the page until consent exists, then inject it. A consent platform blocks the request and releases it on acceptance, or you fire the Analytics tag in Adobe Tags (or Google Tag Manager) on a rule that checks your consent state. Either way, AMCV_ and its siblings never get written to a device that hasn't agreed. For the broader pattern, see why cookie banners fail compliance.
The ECID Leaks Through the Edge Too
Adobe's data collection runs through an edge network, and the ECID can be set server-side at the edge, not through the browser cookie alone. If you gate the browser but forward events from a server or through server-side Adobe Tags, you can still process an identifier for a visitor who declined. Read the consent decision wherever the event originates and skip the send when general consent is not in. A client-side scanner won't see a server forward, which is exactly why it slips past reviews. See server-side consent enforcement.
Connecting It to Your Banner (or a CMP)
Adobe documents the wiring for a consent management platform directly. The pattern is always the same shape: the CMP owns the decision and the record, and it calls setConsent when the visitor accepts or rejects. If you run the IAB Transparency and Consent Framework, the Web SDK also accepts the IAB TCF standard in setConsent, so you can pass the TC string instead of the Adobe general flag. Pick one model and be consistent, because sending both an Adobe-standard and a TCF signal that disagree is a good way to get unpredictable behavior.
Adobe Analytics Consent Checklist
Web SDK is configured with defaultConsent set to pending
No ECID and no sent hits until the visitor decides.
setConsent runs on every page with the visitor's stored decision
defaultConsent does not persist; the resolved decision does. Replay it early.
Legacy AppMeasurement is blocked until consent, and configuring it isn't enough
The old library has no pending queue, so gate the script load itself.
No kndctr_ or AMCV_ cookie exists before acceptance
Clear cookies, load the page, leave the banner alone, check the Application tab.
Edge and server-side forwards respect the same decision
The ECID can be set at the edge; gate the send there too, not the browser alone.
Doing It With CookieBeam
If you use Adobe's native consent commands, CookieBeam's job is to own the decision and hand it to setConsent, then prove the gate holds. Its scanner detects the Web SDK, the ECID cookie, and the legacy AppMeasurement cookies during an audit, so you can confirm nothing is written before acceptance rather than trusting that defaultConsent: pending was configured everywhere. For the legacy library, CookieBeam blocks the script until the visitor accepts analytics and injects it after. Categorize Adobe Analytics under analytics, wire the toggle to setConsent, and verify with a scan that the cookies really are absent on first load.
Related Guides and Sources
Continue with Is Google Analytics GDPR compliant, Google Tag Manager consent setup, and Matomo cookie consent. Primary sources: Adobe's defaultConsent and setConsent command references, Adobe's implement consent with a CMP tutorial, and the ePrivacy Directive Article 5(3).