Client-side versus server-side A/B testing

WHAT THIS TESTS This checks that you understand the execution boundary between browser and server and how that boundary affects test integrity, performance, and security. It rewards concrete reasoning about flicker, tampering, and where business logic lives.

A GOOD ANSWER COVERS In a client-side test, the page loads with default content, then JavaScript fetches the assignment and rewrites the DOM. This causes a flash of original content, adds latency, and can be blocked by ad-blockers or tampered with by users who edit the page. In a server-side test, the server decides the variant during request handling and returns the already-correct response. There is no flicker, the assignment logic and variant code never reach the client, and it works for non-UI changes. Server-side is strongly preferred when the change is in backend logic: pricing rules, search ranking, recommendation algorithms, or API responses, because that logic must run on the server anyway and must not be exposed or bypassable.

COMMON WRONG ANSWERS Reversing the definitions. Claiming client-side is fine for pricing experiments. Ignoring the flicker and SEO downsides of client-side. Forgetting that client-side variants are visible in the browser and thus leak unreleased features.

LIKELY FOLLOW-UPS How do you avoid flicker in a client-side test. How do you keep bucketing consistent across server and client. What are the deployment costs of server-side tests.

ONE CONCRETE EXAMPLE You want to test a new recommendation ranking on a product page. This must be server-side: the ranking algorithm runs in the backend, depends on data the client lacks, and must not be inspectable or manipulable. The server reads the user's bucket, runs the assigned ranking, and returns the ordered list. A client-side approach would require shipping competing algorithms and data to the browser, leaking intellectual property, adding latency, and allowing tampering, so it is clearly the wrong layer.