Dynamic Yield

The c15t dynamicYield helper loads Dynamic Yield after experience consent. It sets DY.userActiveConsent before loading api_dynamic.js, then loads api_static.js after the first script finishes. No Dynamic Yield global, preconnect, loader request or storage is created before the helper's consent gate opens.

Dynamic Yield recommends synchronous scripts directly in the page's <head> to avoid flicker. Waiting for consent and loading the scripts in sequence changes that timing, so visitors can see the original page before a campaign applies. Check your campaigns and page rendering with Dynamic Yield before using this helper for experiments that need to run before paint.

Configure Dynamic Yield

Copy the section ID and data center from your section's installation snippet. Enable Active Cookie Consent with Dynamic Yield Support. Preview mode lets you check it first. Dynamic Yield ignores the consent API until this setting is enabled for your section.

Remove existing Dynamic Yield snippets, tag-manager tags and preconnects. c15t gates only the scripts registered with it.

npm install @c15t/integrations

pnpm add @c15t/integrations

yarn add @c15t/integrations

bun add @c15t/integrations

import { dynamicYield } from '@c15t/integrations/dynamic-yield';

export const scripts = [
	dynamicYield({
		recommendationContext: { lng: 'en_GB', type: 'HOMEPAGE' },
		region: 'eu',
		sectionId: 'YOUR_SECTION_ID',
	}),
];

Register the scripts

Complete your framework quickstart first. Keep its Inth endpoint, policy, styles and consent UI. Remove the vendor's original script, SDK initializer or tag-manager entry, so the vendor loads only through c15t.

The vendor pages put the helper in src/consent-scripts.ts. If your framework quickstart already has a scripts array, such as the one in c15t.config.ts in the Next.js guide, add the helper to that array instead of creating a second file. The scripts export is a configuration, not an initializer. Add it to the c15t provider you already have, at the registration point for your framework below. These are edits to that provider, not a second provider.

import { defineConsentConfig } from 'c15t/next';
import { scripts } from './src/consent-scripts';

export default defineConsentConfig({ scripts });

Options

recommendationContext.type accepts HOMEPAGE, CATEGORY, PRODUCT, CART, POST and OTHER. data contains the category hierarchy, product SKUs, post ID or page identifier. lng selects a feed locale such as en_GB. Match values to the section's product or content feed. See Dynamic Yield's page context guide.

The helper seeds the initial context. Your application owns context updates on client-side navigation. Follow Dynamic Yield's context implementation guide and check consent before making your own Dynamic Yield calls.

Loading and revocation

Before consent, neither loader runs and window.DY stays absent unless another part of your app created it. Granting the mapped consent creates DY if needed, sets DY.userActiveConsent = { accepted: true }, and starts the dynamic loader. The static loader starts after the dynamic loader finishes.

Equivalent helper options reuse the same scripts across framework renders. Registrations that share the dynamic loader also share its static loader. Sharing is scoped to the same section ID and region; different sections or regions request their own loader URLs. Dynamic Yield's consent and page context still use the page-global window.DY, so configure one section and region per page.

The consent signal is page-global too. It stays granted while any Dynamic Yield registration has consent, including registrations with different sections or regions. Revoking or removing one registration keeps both loader elements while another granted registration uses the same URLs. When a section's last granted registration is revoked or removed, the helper removes its loader elements. When no registration on the page has consent, it sets DY.userActiveConsent = { accepted: false }.

If consent is withdrawn while the dynamic loader is downloading, the helper skips the static loader. Granting consent again starts a new loader sequence.

The SDK's consent setter applies only when Active Cookie Consent is enabled for the section. It changes data collection and personalization behavior. It does not unload the SDK or guarantee zero requests from code that already ran. Keep c15t's default reloadOnConsentRevoked behavior enabled.

Dynamic Yield's denied mode can serve limited experiences. This helper waits for consent before loading either script, so it does not use denied-mode campaign delivery before consent. There is no alwaysLoad option.

Cookies and storage

Dynamic Yield's cookie and storage inventory includes these cookies. Your section and campaigns determine which appear.

Dynamic Yield caps cookie storage at 365 days. Its browser storage also includes _dyuss_, _dy_tsrc, _dyaud_nchc, _dyaud_page, _dy_device, _dycst, _dy_csc, _dyrc, _dybatch, _dy_cs_session_items and _dy_cs_local_items. _dyaud_sess uses session storage. Check the vendor inventory and your browser for the keys used by your section.

The helper does not delete previously stored cookies or browser storage. Configure cleanup for your deployment and verify it after withdrawal.

Verify Dynamic Yield

Filter DevTools Network by dynamicyield.com. Grant experience and check that api_dynamic.js finishes before the helper appends api_static.js. Inspect DY.userActiveConsent.accepted and your page context. Revoke consent and check the next page makes no Dynamic Yield request. Test vendor-specific switches and the category override if your app uses them.

Sources: Implement the Dynamic Yield script, Active Cookie Consent API, Active Cookie Consent mode and limited experiences, and cookies and local storage.

Test in a private window with an opt-in policy. Open DevTools Network, disable the cache and filter by the vendor's domain:

1. Load the page. No request goes to the vendor before you choose.
2. Click Reject, then reload. There is still no vendor request.
3. Open Privacy settings and allow the helper's category. The vendor script loads without a page reload.
4. Turn the category off again and save. c15t reloads the page, and the new page makes no vendor request.

c15t reloads on revocation because removing a script element does not stop code that already ran. The vendor's listeners, timers and queued events stay alive until the page unloads. If you set reloadOnConsentRevoked: false, stop the vendor yourself. Register a callback-only script whose onConsentChange calls the vendor's opt-out API, as shown in custom integrations, and check the permission before each of your own event calls. The reload does not delete cookies the vendor already set; see clear on revocation for your framework.

The helper lists its vendor by name in the preference dialog, so a visitor can turn it off inside an allowed category. See vendor consent for your framework. The consent verification guide covers navigation, expiry and hosting checks.