Split Test Pro
Advanced 5 min read

Event Activation

Defer an experiment so it doesn't activate until a specific event fires — useful for tests that only matter after a user interaction. Set it up in the Targeting tab and trigger via SplitTestPro.activate() or a DOM event.

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

In the experiment’s Targeting tab, find the Activation section.

  1. Change the Event dropdown from Page load (default) to Custom event.
  2. Enter the event name in the Event name field. Use a snake-case name like cta_click or step_2_viewed — anything you’ll remember.
  3. Click Save.

That’s it. The experiment is now configured to defer activation until that event fires.

How Deferred Activation Works

Even with deferred activation, assignment still happens immediately on page load:

  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.

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 URL and device targeting. The flow is:

  1. Visitor lands on a page.
  2. URL and device targeting 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. The Split Test Pro script loads from <head> synchronously, so this is rarely an issue. But if you’re using async loading or firing the event extremely early, the script might not have registered its listener yet. Easy check: 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 status Started?
  2. Does the page URL match the experiment’s URL targeting? (Set the experiment’s Preview URL and use the match banner to confirm.)
  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? Whitespace and casing matter.

Next Steps

Ready to start testing?

Install Split Test Pro and run your first experiment today.

Install on Shopify