---
title: Oracle Eloqua
description: Load Oracle Eloqua after mapped category and vendor consent,
  configure its tracking settings, and verify loading and withdrawal with c15t.
seoTitle: Oracle Eloqua cookie consent with c15t
seoDescription: Gate Oracle Eloqua on category and vendor consent with c15t.
  Configure the loader, understand withdrawal limits, and verify vendor requests
  and storage.
icon: chart-line
group: integrations
lastModified: "2026-10-27T15:50:21Z"
lastAuthor: Kaylee
---
`eloquaTracking` waits for its mapped category and vendor consent before creating vendor globals or downloading Oracle Eloqua. The default category is `marketing`.

## Configure Oracle Eloqua

Copy your site ID from Eloqua and remove the original asynchronous tracking snippet. Configure a first-party tracking hostname in Eloqua before setting `firstPartyCookieDomain`.

|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 { eloquaTracking } from '@c15t/integrations/oracle-eloqua';

export const scripts = [eloquaTracking({ siteId: 'YOUR_SITE_ID' })];
```

## Register the scripts

Complete your [framework quickstart](/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](/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](/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](/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](/docs/frameworks/react/quickstart). Keep the banner,
dialog and preferences link inside the provider. See
[React scripts and embeds](/docs/frameworks/react/scripts).

**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](/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](/docs/frameworks/vue/scripts).

**Astro**

Add the scripts to the client entrypoint from the
[Astro quickstart](/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](/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](/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](/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](/docs/frameworks/javascript/scripts).

## Options

|Option|Default|Behavior|
|--|--|--|
|`siteId`|Required|Eloqua site ID.|
|`firstPartyCookieDomain`|Unset|First-party tracking hostname configured in Eloqua.|
|`category`|`marketing`|Consent condition for the whole loader.|
|`scriptUrl`|`https://img.en25.com/i/elqCfg.min.js`|Custom or proxied loader URL. Blank values use the default.|

Missing or blank required values log an error and never load.

Custom loaders must synchronously append one matching consent response script when `elqOptIn` or `elqOptOut` runs. Preserve `pps=41` for opt-in, `pps=42` for opt-out, and the installed account's `siteid` query parameter. The response itself can complete asynchronously. A deferred or unmatched custom response leaves consent indeterminate. The helper reports the problem and blocks tracking and further consent commands until reload.

A custom dispatcher that throws also blocks tracking and further consent commands until reload, even if it appended a matching response before throwing.

## Loading and revocation

After consent, the helper creates `_elqQ`, sets the site ID and optional first-party cookie domain, and downloads the SDK. After loading, it queues `elqOptIn` and waits for its response script before `elqTrackPageView`. The page view uses the full current page URL, including its path, query and fragment, when the response completes.

The helper sends one consent request at a time. If consent changes while a response is pending, it waits for completion and then sends the latest choice. Withdrawal or disposal during opt-in sends `elqOptOut` after that response finishes and suppresses the page view only when the current owners no longer collectively permit tracking. Disposing one provider preserves the active lifecycle when at least one registered provider remains and every remaining provider still allows tracking. Regrant waits for any pending opt-out before opting in again. Failed responses do not trigger immediate retries or page views. A later consent update or remount can retry a failed request, including an opt-out that failed after disposal. Regrant and category changes preserve Eloqua's installed dispatcher while another provider retains its loader. If a surviving provider needs a new loader, the helper creates a fresh setup queue before loading another SDK. Each SDK execution receives its initial site and first-party settings, which the helper binds to its physical tag before loading. The helper keeps the resulting dispatcher with that tag. A detached download can still execute, so later provider adoption uses the tag's captured dispatcher.

Calling `eloquaTracking` again with equivalent options preserves the active consent lifecycle, including pending response handling across disposal and remount. Consent responses for the same site stay serialized when a provider is replaced, even if its category or loader URL changes. When providers share that configuration, every registered provider must allow the category and vendor before tracking starts. A denied provider that has never loaded still participates in this decision. SDK setup waits while a registered provider denies consent. Compatible providers can use different consent categories or loader URLs and still coordinate consent. Regranting either provider sends one page view after opt-in completes, provided every current owner allows tracking.

A provider can adopt an already-loaded compatible tag while another provider denies consent. Once the denying provider is removed or grants consent, the adopter can keep tracking after the original provider is disposed.

Use one site ID and first-party cookie domain per page. Hostname case and surrounding whitespace are normalized. An absent domain differs from a configured domain. Providers with a different site ID or domain conflict with the installed configuration. The helper reports the conflict, blocks the adopter's commands, and blocks tracking through the installed account while that provider remains registered, even if it starts denied. Withdrawal still targets the installed account and waits for its pending response. Removing the conflicting provider releases its blocker. Changing the installed site or domain requires reload, including after its script tag is removed.

If the stock SDK fails to append a consent response, the helper reports the dispatch failure without confirming the request. It sends no page view for a failed opt-in. A later explicit script reconciliation can retry that request; there is no automatic retry loop. A failed opt-out can leave Eloqua's previous opt-in cookie in place. The helper does not delete that cookie or claim withdrawal succeeded.

Keep `reloadOnConsentRevoked` enabled. Eloqua's opt-in and opt-out commands make asynchronous requests; opt-out does not disable every SDK request method or cancel requests already in flight. The helper orders its own consent requests and waits for the first-party opt-in response so a regrant page view does not run while the opt-in cookie still reads `0`. A request that never completes can hold up a later choice until reload. The loader stays in the DOM for same-page regrant because Eloqua replaces its array queue with a dispatcher. Reload gives the next page a fresh tracking lifecycle. Removing a script tag cannot unload the SDK.

Eloqua can set `ELOQUA`, `ELQSTATUS`, `ELQOPTOUT` and first-party `OPTIN` cookies. Oracle documents 13-month tracking cookie lifetimes. Reload does not erase every vendor cookie.

## Verify Oracle Eloqua

Use a clean browser profile for the initial-state checks.

Before consent and after unrelated consent, check for no `elqCfg.min.js`, `_elqQ`, Eloqua cookies or browser storage. Grant the mapped category, which defaults to `marketing`, and allow Oracle Eloqua as a vendor. Confirm the real dispatcher replaces the array, then revoke and inspect the opt-out request. Regrant with your configured account and verify page tracking after the asynchronous opt-in completes.

Sources: [basic tracking](https://docs.oracle.com/en/cloud/saas/marketing/eloqua-user/Help/EloquaAsynchronousTrackingScripts/Tasks/BasicPageTracking.htm), [first-party tracking](https://docs.oracle.com/en/cloud/saas/marketing/eloqua-user/Help/EloquaAsynchronousTrackingScripts/Tasks/BasicPageTrackingFirst.htm), and [opt-in and opt-out commands](https://docs.oracle.com/cloud/latest/marketingcs_gs/OMCAA/Help/EloquaAsynchronousTrackingScripts/Tasks/OptingInAndOut.htm).

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](/docs/integrations/building-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](/docs/integrations/overview#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](/docs/integrations/overview#vendor-switches-and-cookie-cleanup). The
[consent verification guide](/docs/guides/verify-consent) covers navigation,
expiry and hosting checks.