Load Ours Privacy experimentation through the Web SDK, Tag Manager, or a synchronous script tag. Pick the path by what you are running, including redirect experiments and SPA frameworks.
Use this page to load the Ours Privacy experiment runtime on your site. The runtime is a small JavaScript file that evaluates experiments, assigns variants, applies DOM changes, and runs redirects, all before the page finishes rendering.
Already running Ours Privacy? Add your experiment token to your existing install and publish. You do not need a second script.
Pick how to load it
There are three ways to load experimentation. They share the same runtime and the same experiment token, so the right choice depends on what you are running, not on capability.
Ours Web SDK or Ours Tag Manager: one install for tracking and experiments. The simplest path, and the right default for content experiments and personalization.
A synchronous script tag: loads the runtime directly in the page <head>. Best for redirect experiments, because the runtime evaluates and redirects before the original page renders, which minimizes flicker.
All three keep visitor identity aligned: experimentation reads the same visitor ID cookie the rest of Ours Privacy uses, so assignments, impressions, and conversions stay tied to the same visitor.
Option 1: Ours Web SDK
If you already use the Ours Privacy Web SDK, add your Experiment Token to the existing init options:
The Web SDK loads the experiment runtime and starts it with your shared visitor ID. No extra script tag is required.
Option 2: Ours Tag Manager
If you already use the Ours Privacy Tag Manager, there is no code change. Experimentation is configured in the dashboard:
Open Experiment settings in the dashboard and copy your Experiment Token.
In Tag Manager, open your Ours init tag and paste the token into the Experimentation token field.
Publish the tag manager container.
The tag manager loads the runtime and starts it with the shared visitor ID automatically.
Option 3: Synchronous script tag
Load the runtime directly when you want it to evaluate as early as possible. This is the recommended path for redirect experiments: a synchronous script in the <head> runs before the original page renders, so the redirect fires immediately instead of flashing the original page first.
Add the script to the <head> of every page where experiments run, ahead of your other scripts. Both tokens are on the dashboard: the experiment token on the experiment settings page, the CDP token on your Web SDK install.
<!-- In <head>, before other scripts. Synchronous: no async attribute. --><script src="https://YOUR_CUSTOM_DOMAIN/experiment-init?token=YOUR_EXPERIMENT_TOKEN"></script><script> window.ours_experiments.init({ cdpToken: 'YOUR_CDP_TOKEN' });</script>
Replace YOUR_EXPERIMENT_TOKEN with the token from your experiment settings page, YOUR_CUSTOM_DOMAIN with your configured custom domain (recommended; without one, use https://cdn.oursprivacy.com), and YOUR_CDP_TOKEN with your Ours Privacy tracking token.
The cdpToken is what lets the runtime record the variant assignment on its own, so a redirect is tracked reliably even when it fires before the rest of Ours Privacy has loaded.
Identity is shared, and you do not create it. Experimentation uses the same visitor ID as the rest of Ours Privacy. A first-time visitor has no ID yet, and you do not need to set one up: the runtime creates an ID on first contact and reuses it on every visit after (find or create). The one thing to get right is that every page agrees on where that ID lives, which for the default install is automatic.
Using a custom device-id cookie name? This is the one case where the standalone script needs more than the token. The runtime reads the visitor from the ours_device_id cookie by default. If you set a custom cookie_names.device_id in your Web SDK, pass the same name so identity stays joined:
Note: You still run Ours Privacy for event tracking. Experiment results are measured against events already in your CDP (a goal like trial_started), so keep your Web SDK or Tag Manager install in place for conversions. The synchronous script handles assignment and the redirect; your existing install handles tracking.
Consent: Because the synchronous script records the assignment directly, the impression does not pass through the CDP's consent layer. That is safe here: impressions are internal to your experiment results and are never forwarded to destinations. If you need experiment impressions to honor CDP consent gating, load experimentation through the Web SDK or Tag Manager instead.
init() options
window.ours_experiments.init({ cdpToken: 'YOUR_CDP_TOKEN', // lets the runtime record impressions on its own // Identity: pass ONE of these, not both. visitorId: 'YOUR_VISITOR_ID', // the identity itself, or visitorCookieName: 'your_device_cookie', // the cookie to read it from (defaults to ours_device_id) ingestDomain: 'https://YOUR_CUSTOM_DOMAIN', // where the runtime sends impressions (optional)});
cdpToken: your Ours Privacy tracking token. The runtime's own impression delivery uses it to record assignments against the standard ingest endpoint, so redirect impressions are captured even before the rest of Ours Privacy loads. Without it, impressions are recorded only once the Web SDK is ready. Loading through the Web SDK or Tag Manager passes this for you.
visitorId and visitorCookieName are two ways to express the same thing, the visitor's identity, so pass one or the other, not both:
visitorId: the identity itself. Set it when your page already knows the visitor. The Web SDK and Tag Manager pass it for you.
visitorCookieName: the name of the cookie to read the identity from when you are not passing visitorId. Defaults to ours_device_id. Set it on a standalone install when you configured a custom cookie_names.device_id, so experiment identity stays joined to your tracking.
ingestDomain: the origin the runtime sends impressions to. It accepts a bare host (metrics.example.com) or a full origin. Defaults to the origin the experiment script was loaded from, so you rarely need to set it.
SPA frameworks (React, Vue, Next.js)
After init() runs once, the runtime handles client-side navigation automatically. When the visitor moves to a new route (via pushState or replaceState), it re-evaluates URL targeting and applies any matching experiments. No extra configuration is required.
For framework-controlled UI, prefer a headless experiment: read the assignment from the SDK and render the variant in your own components. Automatic DOM changes are most reliable on pages that are not constantly re-rendering the same nodes.
The script exposes window.ours_experiments as soon as it loads, but assignments are not ready until init() runs. In framework code, call init() first, then read assignments or subscribe with on('assigned', cb).
Verifying installation
After the runtime loads and init() has run, open your browser's developer console and run:
An empty object {} means either no active experiments target the current URL, or the visitor is outside the traffic allocation. Check the experiment's targeting rules and traffic allocation in the dashboard.
