Building a Scalable Growth Operations Platform: User Grouping, Dynamic Queries, and Automation

Author: Yan Hao, Growth Operations Engineer at Dada‑JD Daojia, responsible for building the growth data platform and optimizing operational tools.

Story : To boost order volume, the operations team planned a coupon campaign targeting users who hadn't placed an order in the past week, but to reduce cost they focused on users whose last order was over a week ago and tested different coupon amounts in two cities.

The process involved extracting user lists from the data team, uploading them via a file‑upload feature in the coupon tool, sending the coupons, and later evaluating conversion data.

Although the story is fabricated, similar scenarios occur daily.

Apparent Issues : Operations rely on a toolbox built by developers (coupons, notifications, SMS, dynamic banners, ads, etc.) and on user‑profile tags provided by the data team, often delivered as intermediate tables or files.

In early, coarse‑grained operations this works, but as business scales the required user‑profile dimensions increase, rules become more granular, and cross‑department data hand‑offs introduce delays and approval processes, creating efficiency bottlenecks.

Problem Decomposition and Focus

From a fine‑grained operations perspective, efficiency ties to conversion rate and relevance; for example, targeting users who churned within seven days yields higher revisit rates than targeting those who churned six months ago. Therefore, the first problem is to find the right users and quickly integrate them into business systems .

This requires two prerequisites: (1) the data must exist, and (2) many dimensions must be available, implying a focus on mid‑to‑late‑stage lifecycle users (registered, retained, paid, invited, or recalled) and data spread across multiple systems.

The second problem is that regular operational rules need to be reusable and automated , because many rules are periodic or recurring.

These two problems lead to a general workflow: identify the target users, then execute an operational rule.

Solution Exploration

Problem 1 Solution – User Description as Groups : Define “appropriate users” as user groups, turning operational concepts (e.g., active users, high‑value users) into concrete data queries. Dynamic queries consist of three parts: data routing, query generator, and group reuse.

1. Data Routing : Provides the location (database table or Elasticsearch index) and type of each field, enabling the front‑end to generate appropriate UI controls.

Example: a matchmaking platform with buyer and seller roles, order and seller tables, and front‑end event logs stored as JSON in Elasticsearch. Routing maps fields to their sources, allowing queries such as “buyers with order count X” or “sellers registered before a certain date.”

With routing data, the UI can automatically generate condition panels; users define groups by selecting field values. Multiple groups are combined with union logic, while conditions within a group use intersection.

2. Query Generator : After groups are defined, the back‑end translates the front‑end configuration into SQL or Elasticsearch queries, executes them, and performs set operations (union, intersection, difference) to produce the final user list.

3. Group Reuse : Groups can be persisted either statically (saving a fixed list of user IDs) or dynamically (storing the defining conditions and recomputing the list at runtime). Dynamic groups handle time‑sensitive criteria such as “registered within the last 7 days.”

Problem 2 Solution – Configurable and Automated Operational Rules : Once user groups are available, rule configuration becomes straightforward: combine a user group, a delivery channel (push, SMS, coupon), and an execution schedule (e.g., a Cron job). This enables fully automated daily activation campaigns for “users registered within 7 days but not ordered,” which can be set up in about five minutes.

Data and Application Scope Expansion

The solution puts pressure on underlying data stores and relies heavily on OLAP workloads, requiring a separate read‑only replica. Real‑time requirements introduce latency challenges; many conditions are processed with a T+1 batch, while time‑sensitive data uses a Lambda architecture with a batch layer and a speed layer.

The batch layer computes historical views (often via MapReduce‑style jobs), while the speed layer updates real‑time views in memory or temporary tables. Service requests merge both sources to achieve near‑real‑time results, typically within minutes.

With improved real‑time data, groups can drive not only proactive campaigns but also reactive features such as dynamic ad slots that automatically open or close based on user behavior without code changes.

To Be Continued

The group‑centric solution has already improved operational efficiency, but many areas remain, including normalizing rule execution feedback and automatically optimizing rules based on performance metrics, which are essential for a complete closed‑loop system.