How ABT Architecture Automates A/B Decision Loops on Mobile Apps

Overview

ABT intelligent decision makes the decision loop run automatically, reducing the cycle and cost of product A/B experiments and supporting business growth. To achieve this, the client ABT, data tracking, and home‑page dynamism were redesigned. The article shares technical points of the ABT transformation: client ABT architecture, ABT protocol specification, and ABT tracking.

Architecture Design

From the client perspective, the architecture is divided into: business module layer, in‑app H5, app tracking, business requests, app server, and ABT server.

ABT SDK: caches experiment decision information during its lifecycle, parses decisions for business modules, matches tracking data with experiment info, and forwards experiment data to the backend.

Tracking: collection and reporting of user behavior data.

In‑app H5: to keep consistency with app experiment decisions, the SDK passes decisions to H5 pages via UA.

App Server: forwards ABT service experiment decision lists; ApolloY configures the paths of business interfaces participating in experiments.

ABT Server: creates ABT experiments, provides raw decision information, and forwards business information of experiments.

ABT Protocol Specification

To ensure consistency across resource placement, client, app server, ABT service, and tracking services, a unified page‑module system and ABT protocol were defined. All ABT experiment types (TAC/resource placement/pure client experiments) operate on this protocol.

$(ABT protocol version)|$(page)|$(module)|$(position)|$(service ID)|$(experiment ID)|$(plan ID)

1st field: protocol version (reserved for future extensions, e.g., 1).

2nd field: page identifier (e.g., index), provided by the page‑module management service.

3rd field: module identifier (e.g., BANNER), provided by the page‑module management service.

4th field: position (e.g., 1, 2, 3), provided by the page‑module management service.

5th field: third‑party service identifier (e.g., RDC for resource placement), provided by the ABT platform.

6th field: experiment ID created on the ABT platform.

7th field: plan ID created on the ABT platform.

Example for a resource‑placement experiment on the home‑page banner slot: 1|index|banner|2|RDC|002|001 .

{
    "type":0, // 0 native experiment, 1 H5 experiment
    "groupId":"1|index|banner|2|RDC|002|001", // experiment ID
    "extend":"",
    "paths":["/api/tac/execute/index"] // list of interface paths involved in the experiment (paths without .json suffix)
}

ABT Tracking

ABT experiment tracking supports module‑level, page‑level, global‑level, and slot‑level granularity. Tracking information is automatically matched to the corresponding page module and reported together with the current tracking data.

Module‑level: only experiment info related to the module is attached to its tracking points.

Page‑level: all tracking points on a page carry the page’s experiment info, useful for cross‑module experiments.

Global‑level: all tracking points in the app carry global experiment info, supporting cross‑page experiments such as transaction‑flow experiments.

Example of ABT SDK cached decision list:

["1|index|newitem|2|TAC|002|001",   // module‑level experiment
 "1|index|newitem|3|TAC|003|004",  // module‑level experiment
 "1|NULL|NULL|2|TAC|005|006",     // global experiment
 "1|index|more|2|TAC|007|008"]      // module‑level experiment

For a click tracking point click_index_newitem_item on the home‑page new‑item module, the matched experiment info is "002_001|003_004|005_006" .

Resource‑Placement Experiment Tracking

Resource‑placement ABT experiments are transparent to the client; the experiment granularity reaches the slot level. Experiment tracking data is returned by business interfaces and directly passed to the tracking service at the corresponding slot.

Resource‑placement ABT directly accesses the ABT platform.

Resource‑placement ABT tracking: interface returns SCM tracking information.

ABT Home‑Page Implementation

For home‑page TAC experiment scenarios, the page layout and data are assembled by the backend TAC service. Therefore, the SDK must provide experiment decisions to both the client and the backend TAC service.

The decision information is passed to the TAC service via WZP Header in business requests; the TAC service uses this information to assemble the appropriate version of page data and returns it to the app.

Example of a completed experiment testing home‑page TAC layout:

Version A module order: Super Member Exclusive Benefits → Home Personalized Module → Home Popular Recommendation Module.

Version B module order: Home Popular Recommendation Module → Super Member Exclusive Benefits → Home Personalized Module.

Summary and Outlook

To date, 78 client experiments have been launched, including home‑page TAC layout experiments, TAC style experiments, resource‑placement experiments, and product‑detail experiments.

With increasing privacy regulations and improving mobile device performance, future plans aim to combine on‑device AI to fully utilize phone compute resources, reduce cloud usage, and enable decisions to be made entirely on the device in certain business scenarios.