Overview
What is Server-Side Testing?
Server-side testing is a method of A/B or multivariate testing where the experiment logic (including variation assignment and tracking) is handled on the server (backend) rather than in the browser or mobile app (client-side).
Instead of rendering different variations via frontend scripts, the server determines which variation a user should see and delivers it as part of the API response or backend-rendered HTML.
Key Concepts
Variation Assignment: Each user is assigned a variation (e.g., control or variant) based on a consistent bucketing mechanism using a unique user identifier.
Experiment Key: A unique ID that identifies a test.
Sticky Bucketing: Ensures the same user consistently sees the same variation.
Event Tracking: Custom goals (e.g., purchase, signup) are tracked by sending event data from the server using SDK methods or APIs.
SDK Integration: Lightweight SDKs in supported languages help abstract variation assignment, bucketing logic, and event tracking.
When to Use Server-Side Testing
Use Case | |
Algorithm Testing | You want to test recommendation models, pricing logic, or search algorithms |
Backend Response Variation | Changes to response payloads or business logic |
Performance-Sensitive Environments | You want to reduce front-end dependency and render pages faster |
Non-UI Changes | Testing that does not impact UI but affects backend behavior (e.g., coupon logic, shipping rules) |
While server-side testing is powerful, there are specific cases where client-side testing is a better fit. Here’s when you should avoid server-side:
1. UI Layout or Copy Changes
If you’re only testing visual elements—like the color of a button, the order of homepage sections, or alternate marketing headlines—there’s no need to run logic on the backend.
2. Quick Marketing Experiments
For rapid tests on pages like landing pages, product announcements, or CTAs, server-side setup may be too heavy.
3. Tests Needing Front-End Targeting
If your experiment needs targeting based on front-end behavior, such as Scroll depth, time on page, UI interactions etc
Server-Side vs Client-Side Testing
Server-Side Testing | Client-Side Testing |
Logic runs on the backend | Logic runs in a browser or app |
Better for business logic tests | Better for UI or layout changes |
Harder to detect /block by ad blockers | May be blocked or flicker-prone |
Supports API & backend-driven apps | Best for web-first or hybrid experiences |
How It Works: FullStack A/B test workflow
The diagram below outlines the lifecycle of a typical server-side A/B test using our Full Stack SDK. Each stage will be covered in detail in the following sections.
SDK Initialization: Set up the SDK using app and environment keys.
User Request: Backend receives a user interaction (e.g., page load, API call).
Assign Variation: SDK uses user ID to assign a variation.
Experiment Logic: App logic changes based on variation assigned.
Visitor Details: Optional user attributes sent for audience targeting.
Event Tracking: Goals like purchases or clicks are tracked via SDK.
Report: Data is sent for analysis and shown in the reporting dashboard.