Event Activation

By default, an experiment activates the moment a visitor lands on a matching page. Event activation lets you defer activation until a specific event fires — useful when the test only matters after the visitor interacts with the page in some way.

When to Use Event Activation

Reach for event activation when:

• The experiment changes something that only matters after a click, scroll, or form interaction — a test of a “Step 2” form that only renders after someone advances from Step 1.
• You want to reduce variant exposure to visitors who’d never reach the relevant part of the page anyway. Counting all pageviews as exposed dilutes your conversion rate; counting only those who triggered the event tightens the signal.
• You’re testing a delayed UI element that the page renders asynchronously and you want activation timing to align with rendering.
• You want to fire the variant from your tag manager or analytics layer based on existing event tracking you already have wired up.

If your experiment changes something visible on initial page load (a hero color, a CTA above the fold), you don’t need event activation — the default page-load activation is right.

Setting Up Event Activation

Activation lives on the General step of the experiment wizard.

1. Change the Activation dropdown from On page load to Custom event.
2. Type the event name in the Event name field (up to 60 characters). Use a snake_case name like cta_click or step_2_viewed — anything you’ll remember. Leaving it empty shows Event name can’t be blank.
3. Two more dropdowns appear, Delay and Sticky — see Delay and stickiness below. The defaults (no delay, sticky by visitor ID) suit most tests.
4. Click Save Draft or Continue.

The experiment is now configured to defer activation until that event fires. You can change activation while the test is a Draft or Paused.

How Deferred Activation Works

Even with deferred activation, assignment still happens immediately on page load (this describes the default Sticky setting, by visitor ID):

1. The visitor lands on the page.
2. The script picks which variant the visitor belongs to and stores the choice in the cookie. The variant is locked in — they’ll always see the same variant on this and future visits.
3. The variant CSS/JS is not yet applied. The page renders as the control would.
4. Analytics events for the experiment are not yet recorded.
5. When the named event fires, the script applies the variant’s changes and records the page-view event.

This means a session that never fires the event doesn’t count toward the experiment — neither in the exposure number nor in the conversion rate denominator. Only sessions that activate are measured. Once a visitor has activated, their later conversions count even on pages where the event doesn’t fire again.

Delay and stickiness

Delay and Sticky appear only for a Custom event. Switching back to On page load stores the defaults again.

Delay

Delay waits a moment after the event fires before the variant is applied: 0ms (the default), 250ms, 500ms, 1s or 2s. Use it when the element you change renders a little after the event — a drawer that animates in, a widget that loads late.

The assignment cookie is still written at once; only applying the variant and recording the exposure wait. A visitor who leaves the page before the delay runs out is never exposed and isn’t counted.

Sticky

Sticky decides how long a visitor keeps the variant they were assigned:

Option	What it does
Yes — by visitor ID	The default. The visitor sees the same variant on every page and every visit.
Yes — for this session	The visitor keeps one variant for the browser session and may get a different one next session.
No — re-evaluate each page view	Every page view draws a variant afresh.

Choosing the last option shows the note Visitors may see different variants on different pages. Results are still counted per visitor. With session or page-view stickiness one visitor can see more than one variant, so the Results tab shows an Exposure filter (All visitors, Single-variant only, Mixed only) that separates single-variant visitors from mixed ones — see Segmenting Results.

Firing the Event

There are two ways to fire your activation event from your site. Both work; pick whichever fits your existing tooling.

Option 1: JavaScript API

Call SplitTestPro.activate() from anywhere in your code:

// When the visitor clicks the "Get started" button
document.querySelector("#get-started").addEventListener("click", () => {
  window.SplitTestPro.activate("cta_click");
});

This is the simplest path if you control your site’s JavaScript directly.

Option 2: DOM Custom Event

Dispatch a CustomEvent with the same name on document:

document.dispatchEvent(new CustomEvent("cta_click"));

This works well when you’re firing events through Google Tag Manager, a third-party analytics SDK, or any system that already speaks DOM events. The script registers a listener for your event name and activates the moment it fires.

First-Fire-Wins

Once an experiment activates, subsequent fires of the same event name are no-ops for that experiment. The variant has already been applied and the page-view recorded; firing the event again won’t double-count or re-apply.

This means it’s safe to fire the event from multiple places — for example, both on a button click and on a scroll-into-view trigger — without worrying about duplicate activations.

Multiple Experiments, Same Event

If you have several experiments configured to activate on the same event name, they all activate when the event fires. This is useful for coordinating a group of experiments that should all measure the same downstream interaction.

Combining Event Activation With Other Targeting

Event activation runs after page, device and audience targeting. The flow is:

1. Visitor lands on a page.
2. Page rules, devices and audience rules filter — does this visitor match? If not, no assignment, no activation, ever.
3. If yes, assignment happens.
4. Activation defers until the named event fires (or activates immediately if no custom activation is configured).

So cta_click activation on a /checkout/*-targeted experiment means: only visitors on checkout pages who also click the CTA will be measured.

Common Mistakes

• Forgetting to fire the event from your site. The script can’t infer when to activate — it needs your code (or your tag manager) to call SplitTestPro.activate() or dispatch the event. If you set up custom activation but never wire up the firing code, no visitor will ever be exposed and your experiment will collect zero data.
• Firing the event before the script loads. A SplitTestPro.activate() call made after the script has loaded but before it finishes setting up is remembered and applied once it’s ready. A DOM event dispatched before the script has loaded at all is missed, and calling window.SplitTestPro.activate() before then fails because the object doesn’t exist yet. If you load the script with async or fire very early, dispatch the event in a DOMContentLoaded handler at the earliest.
• Using a generic event name that conflicts with another DOM event. Avoid names like click, submit, change, load — use a custom snake_case name unique to your experiments (e.g., stp_step_2_viewed).
• Expecting activation to retroactively apply on past pageviews. It doesn’t — activation only matters on the current page session. If the event never fires this session, this session isn’t counted.

Verifying Activation

To confirm everything’s wired up, open your site in DevTools and watch the console:

// In the DevTools console:
window.SplitTestPro.activate("cta_click");

You should see the variant’s CSS/JS take effect immediately. If nothing changes, check:

1. Is the experiment’s status badge Running?
2. Does the page match the experiment’s targeting? Open the page with the preview link (Copy preview link on the Variants step, see Screenshots and Preview) and check that the preview bar’s badge reads Active.
3. Is the visitor in the right variant? Check document.cookie for splittestpro-experiment and confirm the variant ID matches the one with the change.
4. Does the event name in the call exactly match the event name configured on the experiment? Casing matters.
5. Did you set a Delay? The change appears only after it runs out.

Next Steps

• See where event activation fits among the targeting controls: URL Targeting, Device Targeting and Audience Targeting.
• For multi-experiment behavior on the same page: Running Multiple Experiments.
• Learn how custom events can also drive conversions (a separate feature): Custom Events.