Active Cookie Consent Implementation Skill

---
name: active-cookie-consent
description: Detect, implement, and validate Dynamic Yield Active Cookie Consent on a website using its existing CMP, a pre-load DY.userActiveConsent value, and later DY.userActiveConsent updates. Use when asked to add or review DY consent, including OneTrust, custom banners, and late opt-in or opt-out.
---

# Active Cookie Consent

Use this skill only for websites implementing Active Cookie Consent with the Dynamic Yield client-side script. Customers using a DY out-of-the-box CMP integration do not use this skill. Work on the site the developer names; do not change unrelated sites or replace their CMP. Read the current [DY client-side guide](https://dy.dev/docs/active-cookie-consent) before recommending implementation details. `DY.userActiveConsent` is the documented API for both the initial value and later changes; the DY client script observes assignments to it.

## 1. Discover before changing anything

Inspect the site's HTML/layout, script insertion points, CMP configuration, consent persistence and change hooks, and any existing DY or tag-manager integration. Identify:

- CMP (OneTrust, Usercentrics, another vendor, custom, or none), the **actual** consent signal and when it becomes available. Read the CMP's state rather than inferring consent from its name.
- Rendering model (SPA, SSR/hydrated, multi-page, tag manager), including every page/head path and whether a full navigation reloads the bootstrap.
- Existing DY script, existing `DY.userActiveConsent`, and any competing writers or listeners. Preserve working integrations; avoid duplicate script loads and handlers. Determine when DY initializes relative to the CMP callback; do not infer live consent from the property alone.
- Preserve the existing DY page-context integration. Do not add or change page context as part of this consent implementation.
- The CMP purpose/group that authorizes **DY personalization and data collection**. A generic "necessary" category, `true`-looking string, or unknown/partial preference is not proof of consent. Ask the developer to confirm an ambiguous category mapping rather than guessing.
- Identify whether you are adding Dynamic Yield Active Consent or editing an implementation that already uses it. Do not check or change DY's Active Consent enablement setting.

Report evidence (file paths/behavior), confidence, and missing information in a few lines. If the DY section ID/script or purpose mapping is absent, explain the next specific input needed; you can implement a safe bootstrap without inventing credentials, but do not claim an end-to-end integration is complete.

## 2. Implement initial and live consent

Preserve the existing CMP and use its stored state plus update events. Distinguish unresolved consent from confirmed rejection: leave `DY.userActiveConsent` unset while consent is unresolved, and assign `false` for confirmed rejection or withdrawal. Do not treat missing or unparseable state as confirmed acceptance. If there is no CMP/consent mechanism or the purpose mapping is unresolved, stop before asserting acceptance. Tell the developer what to configure/confirm and why. Do not create a fake consent choice.

Leaving consent unset preserves DY's existing DYID-cookie fallback. Do not read DYID cookies yourself or treat them as proof of CMP consent. The current client-side guide recommends `false` for unknown consent but does not explicitly address initialization while the CMP is loading or describe this fallback.

A site may use different CMPs by region, domain, or language. Follow the site's existing rules to identify the applicable CMP, and use only its stored consent and update events for DY. Do not mix signals from different CMPs. If the applicable CMP is unknown or not ready, do not assign a consent value until confirmed.

Establish a synchronous head bootstrap before the DY script **and before any async/deferred tag manager can inject it**. Ensure the initial consent bootstrap runs before DY initializes through every script-loading path identified in the codebase.

Before DY loads, read stored consent using the site's existing CMP integration. Set `DY.userActiveConsent` only when acceptance or rejection is confirmed. If consent is unresolved, leave it unset to preserve DY's fallback.

Read the CMP's actual persisted signal synchronously before DY initializes when available; do not await React/Vue/Angular hydration, a promise, or an effect to set the initial value. If consent cannot be read synchronously, leave `DY.userActiveConsent` unset, then update it with the confirmed value when the CMP resolves. Do not delete or overwrite a previously confirmed value merely because the CMP is temporarily unavailable. Never use `Boolean(rawString)` for a consent value; `"false"` is truthy. An initial `false` is a real opt-out at DY initialization, not a neutral placeholder. Verify that stored acceptance is read correctly on the first load, not only after a reload.

**After DY initializes**, propagate every authoritative CMP grant, denial, or withdrawal (including rejection after acceptance and acceptance after rejection) by assigning a new `window.DY.userActiveConsent = { accepted: accepted === true }` object. Use only this public property to update DY consent; do not call DY's internal functions. Do not mutate the old object or redefine the `DY.userActiveConsent` property.

Because the same assignment works before and after DY initializes, the bootstrap-to-initialization race is simple: keep writing the latest confirmed CMP state to `DY.userActiveConsent` without waiting for a DY-ready signal. Do not add a separate storage key for DY consent or gate the DY script behind opt-in. Make sure fresh page loads and route changes retain correct state without duplicate subscriptions.

When working in SSR, keep browser storage reads on the client but place the initial browser bootstrap in server-rendered head markup in the correct order; a late client component effect alone is insufficient. Account for CSP nonces/hashes and tag-manager ordering without weakening an existing policy. Do not assume browser storage or third-party cookies will be available (including Safari/private contexts); unreadable state remains unresolved, not confirmed acceptance. Report storage-read failures using the site's existing error-reporting pattern. Consent to DY does not automatically authorize unrelated tags.

## 3. Validate and report

Validate that unresolved consent causes no assignment, stored acceptance and rejection are assigned before DY initializes, and later acceptance, rejection, or withdrawal updates DY. Verify DY's fallback with and without existing DYID cookies using the deployed build; do not infer its behavior from the property alone. Check reloads and navigation. Fix any issues and briefly report the result.

If you added new Dynamic Yield Active Consent implementation, show the message below. If you only made changes to existing dynamic yield implementation, summarize what you changed instead. If the work is incomplete, explain why.

> The Dynamic Yield Active Consent implementation is complete. Next steps:
>
> 1. In **Experience OS > Settings > Data Privacy > Active Cookie Consent**, click **Preview** to experience the site as if active cookie consent is enabled.
> 2. After successful verification, enable active cookie consent in the same settings page.