Server-Side Testing | Split Test Pro

Everything else in these docs runs in the browser: the pixel assigns each visitor a variant and changes the page. Server-side testing moves the decision to your backend. Your server asks Split Test Pro “what should this user get?”, branches on the answer, and reports what the user saw and whether they converted. The results land in the same Results tab, computed by the same Bayesian engine as pixel tests.

Server-side testing is included in every paid plan — Core, Pro and Agency.

The Pieces

Feature flags — a list of named on / off switches in Settings → Feature flags. Each flag is on, off, rolled out to a percentage of users, or killed. Your backend checks a flag before showing the feature it guards. See Feature Flags.
Server API keys — secret keys your backend sends with every call, created in Settings → API keys. See Server API Keys.
The evaluation API — a REST API your backend calls from any language: read the flag config, evaluate flags for a user, record exposures and conversions. See Evaluation API.
The Node SDK — @splittestpro/node, a thin client with caching and background event delivery. See Node SDK & Hybrid Tests.

Flags on Their Own

A flag doesn’t need an experiment. Wrap a new feature in a flag, ship the code with the flag off, then turn it on for 10% of users, 50%, everyone — no deploy. If something goes wrong, Kill turns it off for everyone straight away. That’s a gradual rollout and a kill switch in one.

Experiments Compose Flags

An experiment can set flag values per variant, the way a pixel variant carries CSS or JavaScript changes. In the experiment’s Variants step, each variant has a Feature flags block: pick a flag, set it on or off. The control shows the flags the variants set, read-only at off — “Control serves the current values” — so the control is the experience you have today.

While the experiment runs, every user your backend asks about is placed in a variant (respecting traffic allocation and variant weights), and each flag returns that variant’s value. A flag can be used by one running experiment at a time; starting a second one that sets the same flag is refused with “Flag <key> is already used by the running experiment <name>. Stop that experiment first.”

When the experiment ends and you roll out the winner, the winning variant’s values are written into the flags themselves — a flag the winner set on is turned on for 100% of users, one it set off is turned off — so the winning experience keeps serving after the experiment stops. Delete the flag from your code when you’re ready; the flag outlives the experiment until you do.

How a Flag’s Value Is Decided

Every evaluation walks the same order, and the first rule that applies wins:

Killed — the flag serves false, whatever else is true.
A running experiment sets this flag — the user’s variant decides the value. Users outside the experiment’s traffic allocation fall through to the next rule.
The flag is on — users inside its rollout percentage get true.
Otherwise — false.

false is always the safe answer: a killed flag, an off flag, a user outside the rollout, a key that doesn’t exist and a workspace without a paid plan all serve false. Write your code so that false means “the experience you have today”.

The same user always gets the same answer for the same configuration: assignment is a deterministic hash of the user’s id, not a coin flip per request.

Where Does This Test Run?

The experiment wizard’s General step asks Where does this test run?

On your site (the default) — the pixel serves the experiment in the browser, as it always has. Its variants may also carry flag values: that makes it a hybrid test (below).
Server-side — the pixel never runs this test. “Your backend evaluates feature flags for each user. The pixel does not run this test.” Activation, event name, delay and sticky options are hidden because they are pixel concepts, and each variant’s Feature flags block replaces the visual editor.

A server-side test needs at least one flag value on a variant before it can launch. Because no pixel sees the user, your backend records the exposure — the moment the user actually experiences the variant — and the conversions, through the API. The experiment page shows a Server-side badge and a Results note: “Exposures and conversions arrive from your server through the API”.

Hybrid Tests

A hybrid test is served by the pixel (On your site) and its variants also set flag values, so your backend can branch on the variant the browser was assigned — for example, a new checkout page whose layout the pixel changes and whose pricing logic your server changes. The browser hands your server the pixel’s visitor id and assignment string (window.SplitTestPro.getVisitorId() and getAssignments()); your server passes both to the evaluate call and gets the same variant back. The pixel records the exposure, so your server doesn’t. See Node SDK & Hybrid Tests.

Billing and Results

A server exposure counts toward your plan’s tested sessions exactly like a pixel visitor: once per distinct user per month. A user exposed by both the pixel and your server under the same id counts once.
At the enrollment freeze (see Billing & Plans) no new users enter experiments, and the evaluate response says "frozen": true. The server keeps no record of past assignments, so only a user whose assignment string you pass in keeps their variant (the pixel’s string does this for hybrid tests); every other user gets the flag’s own value, and exposures are answered "recorded": false with the reason frozen.
Server events have device type Server, which the Results device filter offers alongside Desktop, Mobile and Tablet. They carry no page URL and no new-or-returning tag, so URL-based goals never fire from them and they don’t appear in the New / Returning views.

Getting Started

Create a flag in Settings → Feature flags — Feature Flags.
Create a key in Settings → API keys and store it in your server’s environment — Server API Keys.
Evaluate the flag from your backend — Node SDK & Hybrid Tests for Node, Evaluation API for any other language.
To test it, create an experiment, choose Server-side under Where does this test run?, set the flag per variant and launch.