Server-side testing is the practice of running experiments in backend code rather than in the browser. The server determines which variant a user should see and delivers the appropriate experience directly, before the response reaches the client. This means the experiment logic lives in your application layer, not in an injected script.
Server-side testing is the default for product experimentation at scale. When Spotify runs over 10,000 experiments per year across 300+ teams, the vast majority are server-side: the assignment decision happens in the application, and the client receives a fully resolved experience. There's no flicker, no extra JavaScript, and no dependency on a third-party script loading in the browser.
How does server-side testing work?
The flow has three steps.
First, the application evaluates a feature flag to determine which variant the user should see. This evaluation uses a deterministic hash of the user ID and a salt, so the same user always gets the same variant without storing state. In Confidence, this evaluation happens in-process at 10 to 50 microseconds with no network call. A Confidence outage doesn't affect flag evaluations because the SDK resolves flags locally.
Second, the application uses the flag value to branch its logic. This might mean rendering a different UI component, running a different algorithm, querying a different data source, or applying different business rules. The branching happens in your code, which means server-side testing can modify anything your server controls.
Third, the assignment and exposure are logged for analysis. Confidence writes assignment data and exposure logs directly to your data warehouse (BigQuery, Snowflake, Redshift, or Databricks), where the statistical analysis runs.
What can server-side testing do that client-side testing can't?
The key advantage is scope. Client-side testing is limited to what JavaScript can modify in the browser after the page loads: DOM elements, styles, copy, layout. Server-side testing can modify anything the server controls.
Backend logic. Recommendation algorithms, search ranking, pricing rules, eligibility checks, rate limits. These can't be tested from the browser because the browser doesn't control them.
API responses. If your product is a mobile app or a single-page application that consumes APIs, the experiment variant is delivered through the API response. The client receives the resolved data and renders it. No client-side experiment framework needed.
Cross-platform consistency. A server-side experiment delivers the same variant to a user regardless of which client they use: web, iOS, Android, smart TV. Client-side experiments need separate implementations per platform.
Performance-sensitive experiences. Because the variant is resolved before the response is sent, there's no flash of original content (FOOC) or layout shift. Users never see the control version flicker into the treatment. For pages where load time matters, eliminating the client-side script also removes a performance dependency.
What are the tradeoffs?
Server-side testing requires engineering involvement. A marketer can't create a server-side experiment from a visual editor because the experiment logic is in the application code. This means server-side testing is typically slower to set up for simple visual changes (headline copy, button color) where the overhead of a code change feels disproportionate to the test.
The practical solution most teams adopt is to use server-side testing for product experiments (new features, algorithm changes, backend logic) and reserve client-side testing for marketing optimization on web surfaces where speed-to-test matters more than scope. Many organizations eventually consolidate on server-side as their experimentation maturity grows, because the limitations of client-side testing become more painful as experiment complexity increases.
Confidence is built around server-side evaluation. SDKs are available for every major platform (server, web, iOS, Android), and all of them evaluate flags in-process. The same flag can control both a server-side algorithm change and a client-side UI treatment, keeping the experiment coordinated across surfaces.