The Set Consent action in the Web SDK Tags extension

When you need this

Any implementation engineered to comply with GDPR, CCPA/CPRA, or a similar consent regime needs Web SDK to know the visitor's actual choice before it decides what to collect and where that data can be activated - that's exactly what Set Consent communicates. It's also the piece that's easy to get technically present but functionally wrong: an extension installed and configured, wired to a CMP event that fires on page load with a default "yes" instead of the visitor's real, later choice.

It matters for any audit of an existing implementation, too - confirming Set Consent is wired to the CMP's actual consent-change event, not just installed, is one of the first things worth checking when consent governance is in scope.

How to work with it correctly

1. Trigger Set Consent from the CMP's own consent-change event, not a fixed page-load rule. Most consent management platforms fire a JavaScript event or callback when a visitor accepts, declines, or updates their choice - a Tags rule listening for that event (often via a Direct Call trigger the CMP integration invokes) is the correct trigger, not a rule that just runs once per page.

Trigger: Core > Direct Call (name: "cmp-consent-updated")
  # Fired by your CMP's own integration/callback, not by Tags on page load

Action: Adobe Experience Platform Web SDK > Set Consent
  General collection consent: %cmp.consent.analytics%   (in / out / pending)
  Data collection default (for the underlying instance config)

2. Set a genuinely restrictive default before consent resolves, not an optimistic one. Between page load and the visitor's actual choice, Web SDK needs a starting posture - configure the extension's default so collection doesn't proceed as if consent were already granted during that window, and let Set Consent update it once a real choice exists.

3. Re-fire Set Consent whenever the visitor changes their preferences, not just on first load. A visitor who opts out mid-session, or updates preferences from a "manage consent" link, needs the same Direct Call trigger to fire again with the new value - a Set Consent action that only ever runs once per session will serve a stale consent state for the rest of the visit.

4. Map every category your CMP exposes to the corresponding Web SDK consent purpose deliberately. Don't collapse a CMP's separate analytics/personalization/advertising categories into a single flag inside Set Consent - each purpose Web SDK understands should reflect the specific category the visitor actually consented to.

How to verify it worked

• With the CMP set to a decline/opt-out state, the Network tab shows no Edge Network beacon leaving the browser (or one explicitly marked consent-denied) - not a full-payload beacon sent regardless.
• Changing the CMP choice mid-session and re-checking the Network tab shows collection behavior actually change in response - proving Set Consent re-fires on updates, not only on initial load.
• The AEP Debugger's rule log shows the Direct Call trigger firing at the moment the CMP banner is interacted with, and the Set Consent action's resolved values matching the choice made - confirming the wiring, not just the presence of the extension.

Illustrative, not a measured result: an audit might find a Set Consent action installed but wired to a page-load trigger with a hardcoded "in" value - correcting the trigger to the CMP's real consent-change event would be the actual fix, not touching the action itself.

Consent purpose names and default-collection settings vary by Web SDK extension version - verify current field names against Adobe's own Web SDK documentation and your CMP vendor's integration guide.

FAQ

Does Set Consent replace the need for a consent management platform?

No - Set Consent is how Tags communicates a decision to Web SDK; it doesn't collect the decision itself. A CMP (or an equivalent consent-collection mechanism) is still required to obtain and store the visitor's actual choice; Set Consent is the bridge that carries that choice into Adobe's collection behavior.

What happens if Set Consent never fires?

Web SDK falls back to whatever default consent posture the extension is configured with - which is exactly why that default matters and should be reviewed deliberately, not left at whatever value shipped with the extension's initial setup.