Adobe Target

Adobe Target runs A/B tests and personalizes page content. The c15t adobeTarget helper waits for experience consent before it creates Adobe globals or requests the SDK. Pick one mode per page: your self-hosted at.js file or Adobe Experience Platform Web SDK.

On withdrawal, the helper denies Target through Adobe's Opt-in service for at.js, or sends setConsent with 'out' for Web SDK. Neither undoes content Target already changed, so keep reloadOnConsentRevoked enabled.

Configure Adobe Target

Remove the original loader, any Adobe Tags rule and any Web SDK prehiding snippet for this installation. A separate Adobe installation can make requests before c15t has permission. Without the prehiding snippet, visitors see the original page first, then Target's changes once consent allows the SDK to load.

npm install @c15t/integrations

pnpm add @c15t/integrations

yarn add @c15t/integrations

bun add @c15t/integrations

at.js

Download at.js from Administration > Implementation in Adobe Target, then host the file on your own site. Adobe provides no shared CDN URL for at.js. Use at.js 1.7.0 or 2.1.0 and later for Opt-in support. Adobe excludes 2.0.0 and 2.0.1 from this support.

import { adobeTarget } from '@c15t/integrations/adobe-target';

export const scripts = [
	adobeTarget({
		mode: 'atjs',
		scriptUrl: '/scripts/at.js',
		targetGlobalSettings: { secureOnly: true },
	}),
];

The helper writes window.targetGlobalSettings before it appends the loader and forces optinEnabled: true. Pass the rest of your supported settings in targetGlobalSettings. The helper replaces any previous settings object.

Adobe's Opt-in service is part of the Experience Cloud ID (ECID) service. If that service is on the page, the helper calls adobe.optIn.approve(adobe.OptInCategories.TARGET) before it loads at.js and adobe.optIn.deny(adobe.OptInCategories.TARGET) on revocation. It leaves the permissions for ECID and other Adobe products alone. The helper doesn't load or configure the ID service. Any ID service deployment needs its own consent gate and Adobe configuration.

Without that service, optinEnabled alone gives no runtime stop API. c15t still gates the at.js download, but only the page reload stops an at.js that is already running.

Web SDK

As an alternative to at.js, enable Adobe Target on your datastream in Adobe Data Collection. Copy the datastream ID and organization ID, then choose an exact Web SDK version of 2.21.0 or later from Adobe's release notes.

import { adobeTarget } from '@c15t/integrations/adobe-target';

export const scripts = [
	adobeTarget({
		datastreamId: 'YOUR_DATASTREAM_ID',
		mode: 'websdk',
		orgId: 'YOUR_ORG_ID@AdobeOrg',
		version: '2.30.0',
	}),
];

Version 2.30.0 is an example. It doesn't update itself. The helper loads the minified library from Adobe's CDN for the version you pass. Versions before 2.21.0 need edgeConfigId instead of the datastreamId key this helper configures. Older versions, ranges, aliases and prerelease versions log an error and skip the loader.

Once consent allows the loader, the helper creates the alloy base code. After the SDK loads, it calls alloy('configure') with your IDs and defaultConsent: 'pending'. Once configuration succeeds, it sends alloy('setConsent') using Adobe 1.0 consent with the latest permitted state. If consent was withdrawn during configuration, that state is 'out'.

Consent updates run one at a time. If the choice changes while a command is pending, the helper sends the latest choice after that command settles. A rejected setConsent logs an error and can retry on a later consent change. The helper schedules no automatic retries and can't recover an operation stalled inside Adobe. Reload if commands stay pending. A failed configuration also logs an error and needs a page reload. Web SDK keeps a rejected configuration, so another configure call on the same instance can't recover it.

The helper configures the SDK and updates consent. It doesn't send a page view, request offers or render decisions. Keep your own sendEvent personalization code behind the same consent condition and vendor switch, and run it after SDK configuration. Calls to alloy before the helper creates it fail.

Web SDK consent applies to every service on this SDK instance. Use a Target-only datastream when you map it to experience. If the datastream also sends analytics or advertising data, choose a consent condition that covers those purposes. Don't share this helper's window.alloy installation with a separate Adobe Tags or Web SDK initializer.

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

A missing or blank required value logs a configuration error and skips the integration. The helper stays listed in the preference dialog. It doesn't check whether your IDs, SDK version or self-hosted file exist.

Loading and revocation

Before the first permitted grant, neither mode creates Adobe globals, requests a loader or writes Adobe storage. Rejecting the mapped consent keeps it that way. The Adobe Target vendor switch can also block loading inside an allowed category.

When several loaders share the same helper options, every registration must permit Adobe Target before the shared runtime opts in. An initially denied registration counts toward that decision too.

After the first grant, at.js stays installed. On revocation, the helper calls the Opt-in service's Target denial API if it's available. A later grant approves Target again without downloading or running a second copy of at.js. The denial doesn't cancel in-flight requests, remove existing offers, restore page content or erase cookies. Without the Opt-in service, only a page reload stops the installed runtime.

After its first grant, Web SDK stays installed so the helper can send setConsent with value.general: 'out' on revocation. A later grant sends 'in' again without configuring or downloading the SDK again. If consent is withdrawn during the initial download, the load callback doesn't configure the SDK or send an 'in' signal. It can initialize after a later grant.

The helper checks current consent when configuration finishes. It doesn't leave an earlier opt-in waiting in Adobe's configuration queue. Once the helper hands a command to Adobe, the SDK can still finish that command or an in-flight request after revocation. Its consent API doesn't unload listeners or restore rendered decisions. Keep c15t's default reload on revocation.

Removing the last c15t registration sends a denial to the installed SDK when its consent API is available. It can't unload Adobe's runtime. Reload the page before you mount the helper again after its last registration was removed, even with the same options. Web SDK allows configuration only once per instance. Also reload before you change IDs, versions or deployment mode.

defaultConsent: 'pending' is a configuration default, not a replacement for c15t's loading gate. Adobe can use consent saved on an earlier page instead. The helper resends the permitted state after loading on each page. Web SDK persists consent, including an opt-out, in kndctr_<orgId>_consent, and its consent update can contact Adobe. Adobe replaces @ with _ in the organization ID when it names the cookie.

If you use Adobe Analytics to load an Adobe Tags property, every rule in that property starts under its configured measurement gate. Remove Target and Web SDK rules from that property when you use this helper. Registering this helper can't constrain another loader.

Cookies and storage

Actual storage depends on your Adobe deployment and settings. Adobe documents these names:

Revocation doesn't delete cookies already written. Check Adobe's Target cookie reference and the SDK's actual storage in your browser before you configure cleanup.

Verify Adobe Target

For at.js, filter Network by your self-hosted file URL and by tt.omtrdc.net. After a grant, check that targetGlobalSettings.optinEnabled is true and that your Target activities load. If you use Adobe Opt-in, check that only its Target permission changes when you revoke.

For Web SDK, filter Network by cdn1.adoberesources.net and edge.adobedc.net. Confirm there is no alloy global before consent. After a grant, check that alloy.q.push is no longer the array's native push method. The SDK keeps the alloy function when it activates, so the function's presence alone doesn't prove the SDK loaded. Use a real Target-enabled datastream to check offer delivery and server-side consent persistence.

Sources: Target privacy and Opt-in support, at.js settings, self-hosting at.js, Adobe Opt-in API, Web SDK base code, Web SDK library URL, Web SDK datastream ID and version support, Web SDK default consent and Web SDK setConsent.

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.