@c15t/react 3.2.0-canary.0 → 3.2.0

package/docs/integrations/salesforce-pardot.md

@@ -0,0 +1,342 @@
+---
+title: Salesforce Account Engagement
+description: Gate Salesforce Account Engagement tracking on marketing consent,
+  configure its consent API or classic Pardot snippet, and verify revocation
+  with c15t.
+seoTitle: Salesforce Pardot cookie consent with c15t
+seoDescription: Load Account Engagement only after marketing consent. Configure
+  Pardot tracking, revoke consent and verify vendor requests with c15t.
+icon: chart-line
+group: integrations
+---
+
+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.
+
+| Package manager | Command                          |
+| :-------------- | :------------------------------- |
+| npm             | `npm install @c15t/integrations` |
+| pnpm            | `pnpm add @c15t/integrations`    |
+| yarn            | `yarn add @c15t/integrations`    |
+| bun             | `bun add @c15t/integrations`     |
+
+```ts title="src/consent-scripts.ts"
+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](https://c15t.com/docs/frameworks) 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.
+
+**Next.js**
+
+Add the configuration to `scripts` in `c15t.config.ts`, next to
+`next.config.ts`:
+
+```ts title="c15t.config.ts"
+import { defineConsentConfig } from 'c15t/next';
+import { scripts } from './src/consent-scripts';
+
+export default defineConsentConfig({ scripts });
+```
+
+Keep the rest of your config, such as `mode` and `routePrefix`, in the
+same call. `ConsentRoot` reads the config in the browser, so the layout
+keeps passing only `state`. App Router, Pages Router and static export all
+read the same file. See
+[Next.js scripts and embeds](https://c15t.com/docs/frameworks/next/scripts).
+
+**TanStack Start**
+
+Import the configuration into your root route and pass it to the existing
+`ConsentRoot` as a top-level prop. Keep the loader from the
+[TanStack Start quickstart](https://c15t.com/docs/frameworks/tanstack-start/quickstart):
+
+```tsx title="src/routes/__root.tsx"
+import { scripts } from '../consent-scripts';
+
+<ConsentRoot state={consent} scripts={scripts}>
+```
+
+Import vendor helpers in the root route module, not in a server function.
+A server function's return value must be serializable, and script
+configurations carry callbacks. See
+[TanStack Start scripts](https://c15t.com/docs/frameworks/tanstack-start/scripts).
+
+**React**
+
+Add the configuration to the existing `ConsentProvider` options, next to
+`mode`:
+
+```tsx title="src/consent.tsx"
+import { scripts } from './consent-scripts';
+
+<ConsentProvider options={{ mode, scripts }}>
+```
+
+`mode` is the `manifest()` value from the
+[React quickstart](../frameworks/react/quickstart.md). Keep the banner,
+dialog and preferences link inside the provider. See
+[React scripts and embeds](../frameworks/react/scripts.md).
+
+**Nuxt**
+
+Register the scripts under the `c15t` key in `app/app.config.ts`. Adjust the
+relative import to where you created `consent-scripts.ts`:
+
+```ts title="app/app.config.ts"
+import { scripts } from '../src/consent-scripts';
+
+export default defineAppConfig({
+  c15t: { scripts },
+});
+```
+
+The Nuxt module merges this over its options in `nuxt.config.ts` and starts
+one script loader in the browser after hydration, once it has applied the
+visitor's stored choice and privacy signals. Keep `scripts` out of
+`nuxt.config.ts`, which reaches the browser as JSON and drops the vendor
+callbacks. Write the vendor IDs into `consent-scripts.ts`. See
+[Nuxt scripts and embeds](https://c15t.com/docs/frameworks/nuxt/scripts).
+
+**Vue**
+
+Pass the scripts to the existing `c15tVue` plugin call in `src/main.ts`:
+
+```ts title="src/main.ts"
+import { c15tVue, manifest } from 'c15t/vue/vue-plugin';
+import { scripts } from './consent-scripts';
+
+app.use(c15tVue, {
+  mode: manifest(),
+  scripts,
+});
+```
+
+Keep your existing `mode` and other options. The plugin starts one
+script loader when the app mounts, after it has applied the visitor's stored
+choice. Do not also call `createScriptLoader` from a component. See
+[Vue scripts and embeds](https://c15t.com/docs/frameworks/vue/scripts).
+
+**Astro**
+
+Add the scripts to the client entrypoint from the
+[Astro quickstart](https://c15t.com/docs/frameworks/astro/quickstart), `src/c15t.client.ts`,
+which the integration finds on its own. Keep `astro.config.mjs` as it is.
+If the module already exports scripts, combine the two arrays.
+
+```ts title="src/c15t.client.ts"
+import type { C15tClientOptionsExtension } from 'c15t/astro';
+import { scripts } from './consent-scripts';
+
+export default { scripts } satisfies C15tClientOptionsExtension;
+```
+
+Vendor helpers contain callbacks, and the integration options in
+`astro.config.mjs` are serialized into the page, so do not put helpers in
+the integration's `scripts` option. The integration passes the client
+entrypoint to the one runtime every page shares, including across
+`ClientRouter` navigation.
+
+**Svelte**
+
+Import the scripts in the component that owns your existing provider and
+pass them as a top-level prop:
+
+```svelte title="src/App.svelte"
+<script lang="ts">
+  import { ConsentProvider, manifest } from 'c15t/svelte';
+  import { scripts } from './consent-scripts';
+</script>
+
+<ConsentProvider mode={manifest()} {scripts}>
+  <!-- Keep your application, consent UI and preferences link here. -->
+</ConsentProvider>
+```
+
+Retain the styles and consent UI from the [Svelte quickstart](https://c15t.com/docs/frameworks/svelte/quickstart).
+The provider owns the loader and disposes it on unmount.
+
+**SvelteKit**
+
+Add the scripts to the existing `ConsentRoot` in the root layout. Keep the
+handle and the layout load from the [SvelteKit quickstart](https://c15t.com/docs/frameworks/sveltekit/quickstart).
+
+```svelte title="src/routes/+layout.svelte"
+<script lang="ts">
+  import { ConsentRoot } from 'c15t/svelte';
+  import { scripts } from '../consent-scripts';
+
+  let { children, data } = $props();
+</script>
+
+<ConsentRoot state={data.consent} {scripts}>
+  {@render children()}
+  <!-- Keep your consent UI and preferences link here. -->
+</ConsentRoot>
+```
+
+Import vendor helpers in the layout component, not in `+layout.server.ts`:
+a server load cannot send functions to the browser. Prerendered, static and
+SPA-mode pages use the same `scripts` prop. If you pass an externally owned
+`runtime` to the provider, register scripts when creating that runtime instead.
+
+**HTML**
+
+The helpers in `@c15t/integrations` are ES modules that need a bundler. On a
+page that loads the c15t script tag, paste the vendor's own snippet instead
+and keep it inert until its category is allowed:
+
+```html
+<script type="text/plain" data-c15t-category="measurement">
+  // The vendor's snippet, unchanged
+</script>
+```
+
+Use the category this guide names for the vendor. c15t runs the snippet
+once that category is allowed, and reloads the page when the visitor
+withdraws it. Helper options on this page, such as `loadMode`, do not apply
+to a pasted snippet. See [HTML scripts](https://c15t.com/docs/frameworks/html/scripts).
+
+**JavaScript**
+
+Pass the scripts to `init()` from `@c15t/browser`, next to your mode:
+
+```ts
+import { init, manifest } from '@c15t/browser';
+import { scripts } from './consent-scripts';
+
+const consent = init({
+  mode: manifest(),
+  scripts,
+});
+```
+
+Keep the mode from your quickstart. With
+`createConsentRuntime` from `c15t/runtime`, pass `scripts` to it instead.
+A kernel you create yourself needs a loader from
+`c15t/modules/script-loader`. Attach one loader per kernel. See
+[JavaScript scripts](https://c15t.com/docs/frameworks/javascript/scripts).
+
+## Options
+
+| Option       | Default                                 | Behavior                                                                                                          |
+| ------------ | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
+| `piAId`      | Required                                | Account ID from the tracking snippet, as a string or number. Must be a positive integer.                          |
+| `piCId`      | Required                                | Campaign ID from the tracking snippet, as a string or number. Must be a positive integer.                         |
+| `piDomain`   | Required in consent mode                | Verified tracker hostname, without a scheme or path.                                                              |
+| `mode`       | `consent`                               | `consent` uses the Tracking and Consent API. `classic` loads the older `pd.js` snippet, which has no revoke call. |
+| `piHostname` | `pi.pardot.com`                         | Tracker hostname in classic mode, set as `window.piHostname`.                                                     |
+| `category`   | `marketing`                             | Consent condition for the whole loader.                                                                           |
+| `scriptUrl`  | `https://<piDomain>/pdt.js?aid=<piAId>` | Loader override. Classic mode defaults to `https://pi.pardot.com/pd.js`. Blank overrides use the default.         |
+
+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](https://developer.salesforce.com/docs/marketing/pardot/guide/tracking-and-consent-getting-started.html),
+[consent functions](https://developer.salesforce.com/docs/marketing/pardot/guide/tracking-and-consent-functions.html)
+and [classic snippet](https://help.salesforce.com/s/articleView?id=000381476\&language=en_US\&type=1).
+
+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](./building-integrations.md), 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](./overview.md#vendor-switches-and-cookie-cleanup).
+
+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](./overview.md#vendor-switches-and-cookie-cleanup). The
+[consent verification guide](../guides/verify-consent.md) covers navigation,
+expiry and hosting checks.

package/docs/integrations/statable-analytics.md

@@ -0,0 +1,345 @@
+---
+title: Statable
+description: Load Statable analytics after measurement consent with the c15t
+  statableAnalytics helper, configure its ingestion endpoint, and verify
+  requests and browser storage.
+seoTitle: Statable cookie consent with c15t
+seoDescription: Keep the Statable tracker off your page until measurement
+  consent. Configure the site ID, check browser storage, and stop tracking on
+  consent withdrawal.
+icon: chart-line
+group: integrations
+---
+
+Statable describes its web analytics as cookieless. The c15t
+`statableAnalytics` helper still waits until the `measurement` category is
+allowed before it loads Statable's tracker, so no request reaches Statable
+before then.
+
+Statable has no stop API. When the visitor withdraws, c15t reloads the page by
+default, and the reload stops the running tracker.
+
+## Configure Statable
+
+Copy the numeric site ID from **Site settings > Tracking Code** in Statable,
+and replace `12345` in the example with it. This helper uses the standalone
+`/js/<siteId>/s.js` tracker, which Statable offers on paid plans. The Hobby
+plan bundles tracking inside a widget with a different loader, which this
+helper doesn't support.
+
+Delete any existing Statable script tag or tag manager copy, so it can't load
+outside c15t.
+
+| Package manager | Command                          |
+| :-------------- | :------------------------------- |
+| npm             | `npm install @c15t/integrations` |
+| pnpm            | `pnpm add @c15t/integrations`    |
+| yarn            | `yarn add @c15t/integrations`    |
+| bun             | `bun add @c15t/integrations`     |
+
+```ts title="src/consent-scripts.ts"
+import { statableAnalytics } from '@c15t/integrations/statable-analytics';
+
+export const scripts = [statableAnalytics({ siteId: '12345' })];
+```
+
+## Register the scripts
+
+Complete your [framework quickstart](https://c15t.com/docs/frameworks) 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.
+
+**Next.js**
+
+Add the configuration to `scripts` in `c15t.config.ts`, next to
+`next.config.ts`:
+
+```ts title="c15t.config.ts"
+import { defineConsentConfig } from 'c15t/next';
+import { scripts } from './src/consent-scripts';
+
+export default defineConsentConfig({ scripts });
+```
+
+Keep the rest of your config, such as `mode` and `routePrefix`, in the
+same call. `ConsentRoot` reads the config in the browser, so the layout
+keeps passing only `state`. App Router, Pages Router and static export all
+read the same file. See
+[Next.js scripts and embeds](https://c15t.com/docs/frameworks/next/scripts).
+
+**TanStack Start**
+
+Import the configuration into your root route and pass it to the existing
+`ConsentRoot` as a top-level prop. Keep the loader from the
+[TanStack Start quickstart](https://c15t.com/docs/frameworks/tanstack-start/quickstart):
+
+```tsx title="src/routes/__root.tsx"
+import { scripts } from '../consent-scripts';
+
+<ConsentRoot state={consent} scripts={scripts}>
+```
+
+Import vendor helpers in the root route module, not in a server function.
+A server function's return value must be serializable, and script
+configurations carry callbacks. See
+[TanStack Start scripts](https://c15t.com/docs/frameworks/tanstack-start/scripts).
+
+**React**
+
+Add the configuration to the existing `ConsentProvider` options, next to
+`mode`:
+
+```tsx title="src/consent.tsx"
+import { scripts } from './consent-scripts';
+
+<ConsentProvider options={{ mode, scripts }}>
+```
+
+`mode` is the `manifest()` value from the
+[React quickstart](../frameworks/react/quickstart.md). Keep the banner,
+dialog and preferences link inside the provider. See
+[React scripts and embeds](../frameworks/react/scripts.md).
+
+**Nuxt**
+
+Register the scripts under the `c15t` key in `app/app.config.ts`. Adjust the
+relative import to where you created `consent-scripts.ts`:
+
+```ts title="app/app.config.ts"
+import { scripts } from '../src/consent-scripts';
+
+export default defineAppConfig({
+  c15t: { scripts },
+});
+```
+
+The Nuxt module merges this over its options in `nuxt.config.ts` and starts
+one script loader in the browser after hydration, once it has applied the
+visitor's stored choice and privacy signals. Keep `scripts` out of
+`nuxt.config.ts`, which reaches the browser as JSON and drops the vendor
+callbacks. Write the vendor IDs into `consent-scripts.ts`. See
+[Nuxt scripts and embeds](https://c15t.com/docs/frameworks/nuxt/scripts).
+
+**Vue**
+
+Pass the scripts to the existing `c15tVue` plugin call in `src/main.ts`:
+
+```ts title="src/main.ts"
+import { c15tVue, manifest } from 'c15t/vue/vue-plugin';
+import { scripts } from './consent-scripts';
+
+app.use(c15tVue, {
+  mode: manifest(),
+  scripts,
+});
+```
+
+Keep your existing `mode` and other options. The plugin starts one
+script loader when the app mounts, after it has applied the visitor's stored
+choice. Do not also call `createScriptLoader` from a component. See
+[Vue scripts and embeds](https://c15t.com/docs/frameworks/vue/scripts).
+
+**Astro**
+
+Add the scripts to the client entrypoint from the
+[Astro quickstart](https://c15t.com/docs/frameworks/astro/quickstart), `src/c15t.client.ts`,
+which the integration finds on its own. Keep `astro.config.mjs` as it is.
+If the module already exports scripts, combine the two arrays.
+
+```ts title="src/c15t.client.ts"
+import type { C15tClientOptionsExtension } from 'c15t/astro';
+import { scripts } from './consent-scripts';
+
+export default { scripts } satisfies C15tClientOptionsExtension;
+```
+
+Vendor helpers contain callbacks, and the integration options in
+`astro.config.mjs` are serialized into the page, so do not put helpers in
+the integration's `scripts` option. The integration passes the client
+entrypoint to the one runtime every page shares, including across
+`ClientRouter` navigation.
+
+**Svelte**
+
+Import the scripts in the component that owns your existing provider and
+pass them as a top-level prop:
+
+```svelte title="src/App.svelte"
+<script lang="ts">
+  import { ConsentProvider, manifest } from 'c15t/svelte';
+  import { scripts } from './consent-scripts';
+</script>
+
+<ConsentProvider mode={manifest()} {scripts}>
+  <!-- Keep your application, consent UI and preferences link here. -->
+</ConsentProvider>
+```
+
+Retain the styles and consent UI from the [Svelte quickstart](https://c15t.com/docs/frameworks/svelte/quickstart).
+The provider owns the loader and disposes it on unmount.
+
+**SvelteKit**
+
+Add the scripts to the existing `ConsentRoot` in the root layout. Keep the
+handle and the layout load from the [SvelteKit quickstart](https://c15t.com/docs/frameworks/sveltekit/quickstart).
+
+```svelte title="src/routes/+layout.svelte"
+<script lang="ts">
+  import { ConsentRoot } from 'c15t/svelte';
+  import { scripts } from '../consent-scripts';
+
+  let { children, data } = $props();
+</script>
+
+<ConsentRoot state={data.consent} {scripts}>
+  {@render children()}
+  <!-- Keep your consent UI and preferences link here. -->
+</ConsentRoot>
+```
+
+Import vendor helpers in the layout component, not in `+layout.server.ts`:
+a server load cannot send functions to the browser. Prerendered, static and
+SPA-mode pages use the same `scripts` prop. If you pass an externally owned
+`runtime` to the provider, register scripts when creating that runtime instead.
+
+**HTML**
+
+The helpers in `@c15t/integrations` are ES modules that need a bundler. On a
+page that loads the c15t script tag, paste the vendor's own snippet instead
+and keep it inert until its category is allowed:
+
+```html
+<script type="text/plain" data-c15t-category="measurement">
+  // The vendor's snippet, unchanged
+</script>
+```
+
+Use the category this guide names for the vendor. c15t runs the snippet
+once that category is allowed, and reloads the page when the visitor
+withdraws it. Helper options on this page, such as `loadMode`, do not apply
+to a pasted snippet. See [HTML scripts](https://c15t.com/docs/frameworks/html/scripts).
+
+**JavaScript**
+
+Pass the scripts to `init()` from `@c15t/browser`, next to your mode:
+
+```ts
+import { init, manifest } from '@c15t/browser';
+import { scripts } from './consent-scripts';
+
+const consent = init({
+  mode: manifest(),
+  scripts,
+});
+```
+
+Keep the mode from your quickstart. With
+`createConsentRuntime` from `c15t/runtime`, pass `scripts` to it instead.
+A kernel you create yourself needs a loader from
+`c15t/modules/script-loader`. Attach one loader per kernel. See
+[JavaScript scripts](https://c15t.com/docs/frameworks/javascript/scripts).
+
+## Options
+
+| Option        | Default                                 | Behavior                                                                                                                                                                                    |
+| ------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `siteId`      | Required                                | Positive integer as a string or number. Trimmed. If it's missing, blank, fractional, negative, non-decimal or above the safe integer limit, c15t logs an error and never loads the tracker. |
+| `scriptUrl`   | `https://statable.com/js/{siteId}/s.js` | Loader URL override. Each `{siteId}` is replaced with the site ID. A blank value uses the default.                                                                                          |
+| `trackingApi` | Loader origin plus `/api/event`         | Full ingestion endpoint, set as the `data-tracking-api` attribute. The tracker posts to this URL as you give it. A blank value leaves the attribute off, so Statable uses its default.      |
+
+If you serve the tracker from your own CDN, and that CDN doesn't serve or proxy
+`/api/event`, set `trackingApi` to the full ingestion URL too. Replace both
+example hosts with your own:
+
+```ts title="src/consent-scripts.ts"
+import { statableAnalytics } from '@c15t/integrations/statable-analytics';
+
+export const scripts = [
+	statableAnalytics({
+		scriptUrl: 'https://cdn.example.com/js/{siteId}/s.js',
+		siteId: '12345',
+		trackingApi: 'https://analytics.example.com/api/event',
+	}),
+];
+```
+
+A custom `scriptUrl` only changes where the browser fetches the tracker. It
+doesn't proxy event requests. Statable uses the visitor's connection to the
+ingestion server for its reports, so check Statable's guidance before you proxy
+collection.
+
+## Loading and revocation
+
+When `measurement` is allowed, the helper adds a deferred script with your
+site ID in its path and in the `data-id` attribute. It doesn't create
+`window.statable` or queue events. The tracker sets up `window.statable.t`
+after it loads, and it doesn't replay events sent before then. Check the
+measurement permission and wait for that function before you send an event.
+
+The helper calls no Statable consent or stop API. On withdrawal, c15t removes
+the loader element, but the tracker's listeners and timers keep running until
+the page unloads. Keep `reloadOnConsentRevoked` enabled. If you turn it off,
+tracking continues on the current page.
+
+## Cookies and storage
+
+Statable says it sets no cookies and stores no persistent visitor ID in the
+browser. Its tracker reads the `analytics_ignore` flag in local storage. It
+sends the full page URL to ingestion, including the query and fragment.
+Statable says it strips both when it processes URLs. Keep sensitive data out of
+URLs anyway.
+
+For CSP, allow `https://statable.com` in `script-src` and `connect-src`, or
+your custom loader and ingestion hosts.
+
+## Verify Statable
+
+With measurement denied, filter the DevTools Network panel by `statable.com`
+and check that no loader or event request appears. Check Cookies, Local Storage
+and Session Storage in the Application panel for Statable entries. Allowing
+only marketing must leave Statable blocked too.
+
+After you allow measurement, expect one `/js/<siteId>/s.js` script element, and
+`typeof window.statable?.t === 'function'`. With a configured site, events post
+to `/api/event` or to your `trackingApi` URL. Statable suppresses collection
+for automated browsers, Do Not Track, Global Privacy Control and the
+`analytics_ignore` flag. A ready API alone doesn't prove that an event reached
+your dashboard.
+
+Sources: [tracking script reference](https://statable.com/docs/developers/tracking-script/),
+[JavaScript API reference](https://statable.com/docs/developers/javascript-api/)
+and [privacy policy](https://statable.com/privacy).
+
+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](./building-integrations.md), 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](./overview.md#vendor-switches-and-cookie-cleanup).
+
+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](./overview.md#vendor-switches-and-cookie-cleanup). The
+[consent verification guide](../guides/verify-consent.md) covers navigation,
+expiry and hosting checks.