Design and Implementation of Strategy Engine 2.0 for Fine‑Grained Operations

The first version of the overseas strategy engine (1.0) was launched at the end of last year to support fine‑grained operations for the Phone backend. It offered simple backend configuration, real‑time audience segmentation, and fast response times, but its design was tightly coupled with the IQCard system and could not keep up with evolving business needs.

To address growing pain points—long development cycles for new tags, low configuration efficiency, and lack of data isolation—a comprehensive redesign (Strategy Engine 2.0) was undertaken with goals of high efficiency, stability, flexibility, extensibility, and business isolation.

Project Pain Points

Long development cycles caused by the need to write code for every new tag.

Low configuration efficiency due to mixed data from different business units without isolation.

Project Goals

Achieve fully configurable tags.

Enable business line isolation for both data and traffic.

Overall Architecture

The engine consists of two main modules: a management backend (for tag, rule, and strategy management) and a strategy‑matching service (for real‑time audience matching). The system is modularized to allow independent evolution of each component.

Tag Management Backend

Tags are defined with seven attributes: data type, owning business unit, group, supported operators, optional values, source field from DMP, and transformation logic. Tags can be either “generic” (direct mapping to user profile data) or “complex” (requiring custom transformation code). The backend stores both configuration data and references to the actual user profile fields.

Example of tag attributes:

Data type (e.g., date, boolean, numeric, string)

Business owner

Group classification

Supported operators (exists, <, <=, =, >, >=, interval variants)

Optional values (static list, third‑party service, manual input, time picker)

DMP source field

Transformation logic

Strategy Management Backend

Strategies are composed of multiple rules; each rule ties a tag to a specific operator and value(s). A strategy matches a user only when all its rules are satisfied.

Data Storage

Strategy data records tag name, operator, and configured values. Because different operators require different numbers and types of values, the storage format uses arrays to hold one or multiple values, e.g., a single value for equality or two values for a closed interval.

Strategy Matching Service

The service receives a user’s UID, device ID (QYID), and the list of strategies to evaluate. It performs four steps:

Strategy query – retrieve strategy details by ID.

Feature query – fetch user profile features from DMP or other sources.

Logical transformation – map strategy rules to actual feature values.

Strategy hit – evaluate all rules; a strategy hits only when every rule matches.

Two types of strategy groups are supported:

Non‑logical group: List<String> of independent strategy IDs.

Logical group: Map<String, List<String>> where the key is a group ID and the value is a list of strategy IDs. The group can be evaluated with AND or OR logic.

Performance and Scalability

Because the matching service may call many third‑party services and handle large rule sets, the design includes:

Global thread pool to reduce thread‑creation overhead.

Parallel execution of independent steps.

Business‑line isolation to prevent one line’s traffic spikes from affecting others.

QPS limits and circuit‑breaker mechanisms per business unit.

Conclusion and Outlook

After a quarter of operation, Strategy Engine 1.0 revealed several operational pain points. Strategy Engine 2.0 addresses these with configurable tags, business isolation, and performance optimizations. Future work will continue to incorporate user feedback, iterate on the platform, and support more business lines while maintaining real‑time, fine‑grained audience segmentation.