Salesforce Account Engagement

Account Engagement, formerly Pardot, tracks visitors and prospects for Salesforce B2B marketing. The c15t pardotTracking helper waits for marketing consent before it creates Pardot globals or downloads the tracker. The default mode uses Account Engagement's Tracking and Consent API. The helper also supports the classic pd.js snippet.

When the visitor withdraws, consent mode calls pdt('revokeConsent'). Classic mode has no revoke call. In both modes, c15t reloads the page, and the reload stops the running tracker.

Configure Salesforce Account Engagement

Turn on the Tracking and Consent API in Account Engagement before you use consent mode, and use its verified tracker domain. Copy piAId and piCId from the generated tracking snippet as they are. They already include Salesforce's +1000 offset, and the helper doesn't add it again. Then remove the original tracking snippet.

npm install @c15t/integrations

pnpm add @c15t/integrations

yarn add @c15t/integrations

bun add @c15t/integrations

import { pardotTracking } from '@c15t/integrations/salesforce-pardot';

export const scripts = [
	pardotTracking({
		piAId: '123456',
		piCId: '654321',
		piDomain: 'pi.pardot.com',
	}),
];

Replace pi.pardot.com in the example with your verified tracker domain.

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

The helper logs an error and never loads the tracker when a required value is missing or blank, when an ID isn't a safe positive integer, when a tracker domain isn't a hostname, or when mode isn't consent or classic.

Loading and revocation

Consent mode starts after hydration, even when the visitor allowed marketing on an earlier visit. It waits for the client loader to confirm the SDK is ready before it turns tracking on. Classic mode can start from the server-rendered HTML.

After consent, the helper creates the pdt.cq queue and configures the tracker with numeric IDs. It hides Salesforce's own consent banner without changing consent, and starts with setOptIn(false). After the SDK loads, it calls setOptIn(true) and sends one page view. Changes to other categories don't send another view. A detached in-flight load can't turn tracking on.

On withdrawal, the helper calls pdt('revokeConsent'). It doesn't call clearTrackingCookies, because that also deletes the cookie that records the refusal, so later page views could be tracked. On a new grant, the helper reuses the tracker configuration and sends a new page view through the loaded SDK. The consent-mode loader stays in the DOM, because downloading pdt.js again replaces its configured dispatcher. If you call pardotTracking again with the same options, the helper keeps the tracker configuration across the new grant. Classic mode can't stop its running SDK through this helper.

Keep reloadOnConsentRevoked enabled in both modes. Clearing consent makes vendor requests, and late in-flight responses can restore cookies. Removing a script doesn't stop pending requests. The next page doesn't load Pardot while its consent is denied.

Cookies and storage

Pardot can set visitor_id<id>, visitor_id<id>-hash, pi_opt_in<id>, lpv<id> and pardot cookies. A cookie suffix can be the account ID minus 1000. The reload doesn't erase vendor cookies.

Verify Salesforce Account Engagement

Before consent, check that there is no pdt.js or pd.js request, no pdt or piAId global, and no vendor cookies or browser storage. Allow an unrelated category and check again. Allow marketing to load the consent dispatcher, then withdraw it. Confirm that the refusal cookie stays until your own cleanup or its expiry. Allow marketing again and check for one new page view with your own account.

Sources: Salesforce's setup guide, consent functions and classic snippet.

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.