Designing a Scalable Frontend AB Testing Framework: From Config to Runtime

Background

Previously front‑end teams had to call client‑provided library functions for AB experiments, which caused three main pain points: developers spent a lot of effort handling AB logic, client‑side experiments were limited to the app and could not cover mini‑programs or PC scenarios, and data granularity was insufficient because both server‑side and client‑side experiments only provided page‑level metrics.

Design Goal

To create a standardized, simple, and efficient AB testing pipeline.

AB Testing Architecture

The pipeline is divided into two parts that form a closed loop:

Experiment Configuration Chain – handles creation, storage, grouping, publishing, and real‑time traffic splitting of experiment configurations.

Experiment Data Chain – handles data tagging, filtering, calculation, and reporting.

Experiment Configuration Model

Configurations are organized by Application (a front‑end project). An application contains one or more Scenes , which are independent traffic entry points (e.g., a home page or a specific feature). Configurations are pushed to a CDN and read by the JSSDK at runtime to perform real‑time traffic splitting.

Experiment Data Model

Each Business defines a set of metrics. Experiments under the same business can associate with these metrics, which are collected, calculated, and displayed in experiment reports.

Design Solution

The solution is split into platform side and runtime side.

Platform Side

First‑time users register a workspace that includes:

Application – manages experiment configuration aggregation and publishing.

Business – manages experiment‑related data metrics.

Scene – defines the traffic‑splitting model.

After workspace creation, the core experiment creation flow reads basic information, sets bucket allocation, and automatically generates front‑end integration code to lower the entry barrier for developers.

Runtime Side – JSSDK

The JSSDK runs inside the front‑end project, reads experiment configurations, performs real‑time traffic splitting, and reports both split results and associated metric data.

To keep the core logic independent of any front‑end DSL, the JSSDK is divided into two packages:

Core – implements generic logic such as configuration caching, experiment lifecycle control, and traffic‑splitting algorithms.

Coupler – a bridge for a specific DSL (e.g., React, mini‑program, Node FaaS). It implements an interface defined by the Core, handling DSL‑specific operations like storage access and component rendering.

The Core first checks a version‑control strategy to see if remote configuration has changed; if not, it uses the locally cached version. After confirming the experiment is within its active period, the Core triggers the splitting algorithm and returns the result to the Coupler.

The Coupler uses the split result to render the appropriate business component, reports the split to the platform (so real‑time dashboards can verify correct triggering), and invokes a generated reporting hook to upload metric data (with a log key, experiment ID, release ID, and metric UID).

Extensibility

Because the Core does not depend on any DSL, new DSLs can be supported by implementing the Coupler interface. This design enables low‑cost extensions to React, mini‑programs, Node FaaS, etc., while maintaining good maintainability.

Traffic‑Splitting Model

Within a scene, experiments are organized into layers . Layers are orthogonal to each other, while experiments inside the same layer are mutually exclusive. A special Launch Layer holds experiments that have been rolled out to 100 % traffic, bypassing the splitting algorithm.

Data Back‑Flow

Each newly created metric receives a unique UID. When the front‑end component renders after a split, it triggers a reporting hook that sends a log entry containing the log key, experiment release ID, group ID, and metric UID. A scheduled data task on the platform extracts these logs, aggregates UV/PV per metric, and generates the AB experiment report.

Conclusion

Front‑end AB testing remains an under‑exploited area. By providing a standardized, extensible framework and a scientific approach to validation, front‑end engineers can make data‑driven decisions for every iteration.