Server-side A/B Testing

Overview

Server-side A/B Testing provides a lightweight and robust framework to run A/B experiments directly inside Drupal, without relying on external SaaS platforms.

The module serves different content variants at the server level, before the final HTML is delivered to the browser. This makes it suitable for teams that need stronger control over performance, caching, SEO, and experiment logic than client-side testing approaches usually provide.

Key features

• Server-side execution: variants are selected before rendering, reducing flicker and avoiding client-side layout shifts.
• Content-based experimentation: use existing Drupal nodes as experiment variants.
• Explicit experiment model: each experiment is defined by a Main Page, a Control Page, and Alternative Variants with weights.
• Sticky assignments: users remain in the same variant throughout the experiment.
• Cache-aware delivery: integrates with Drupal cache contexts.
• GA4 / GTM integration: exposes experiment data through drupalSettings and triggers analytics events.
• SEO-safe behavior: canonical handling and redirects help avoid duplicate-content problems.
• Drupal-native administration: experiments are managed as Drupal entities.

How it works

1. A visitor requests the Main Page.
2. The module detects whether that page belongs to an active experiment.
3. The visitor is assigned to the Control Page or to one of the configured Alternative Variants.
4. The assigned node is served transparently.
5. Experiment metadata is attached for analytics and cache variation.

Experiment model

• Main Page: the entry point URL that triggers the experiment.
• Control Page: the baseline version of the content.
• Alternative Variants: additional nodes with weighted distribution.

Experiment statuses

• Active: assignment is applied on the Main Page. Direct access to a variant redirects to the Main Page.
• Paused: no assignment is performed on the Main Page, but variant URLs still redirect to the Main Page.
• Draft / Finished: no assignment or redirect logic is applied.

Assignment and persistence

• Anonymous users: identified by a long-lived cookie and persisted in the database.
• Authenticated users: assignments are persisted by user ID.
• Anonymous to authenticated migration: existing assignments are migrated automatically after login.
• Deterministic persistence: database constraints ensure stable assignments.

Why use this instead of other A/B testing modules?

This project fills a different niche from existing Drupal A/B testing options:

• Compared to A/B Test JS (abjs): this module is server-side and node-based, while abjs is primarily a JavaScript-driven testing framework based on condition and experience scripts.
• Compared to mida: this module keeps experiment logic inside Drupal, while mida is an integration with an external A/B testing platform.
• Compared to A/B test (abtest): this module includes an editorial/admin model and content-based experiments, while abtest is a lower-level developer API for implementing tests in code.
• Compared to A/B Test UI (abtestui): this module serves variants internally on the server and models explicit control/variant content, instead of rotating internal URLs around a base URL.
• Compared to Simple A/B: this module is page/node-oriented and cache-aware, while Simple A/B is focused on simplicity and currently emphasizes block-level testing.
• Compared to A/B Paragraphs: this module operates at page/node level on the server, while A/B Paragraphs is a frontend Paragraphs-based approach.
• Compared to Smart Content A/B SSR: this module is built around explicit experiment entities and page-level node routing, while Smart Content A/B SSR focuses on Smart Content SSR block-level personalization/testing.

Performance considerations

• Indexed lookups are used for main and control pages.
• Variant resolution is optimized with request-level caching.
• The module is intended for a moderate number of concurrent active experiments.

Requirements

• Drupal 10 or 11
• Optional analytics integration via GA4 or GTM

Use cases

• Landing page experiments with a stable canonical URL
• Editorial A/B testing with existing Drupal content
• Experiments where frontend flicker must be avoided
• Sites that need Drupal-native control over routing, caching, and analytics exposure