Boosting Repeat Purchases: Taobao’s Cumulative Order Feature for Grocery Pickup

Overview

The cumulative‑order mechanism is a precise marketing solution for Taobao Buy‑Vegetables’ next‑day pickup service, designed to increase repeat purchases among price‑sensitive users. It uses the "X天下Y单发Z权益" activity model, supplemented by lotteries, to deliver personalized incentives and significantly raise platform DAC (daily active customers).

Project Background

In mid‑2022, the next‑day pickup service lacked incentives for low‑frequency buyers. The interactive domain’s sign‑in channel already showed higher activity, so the business introduced the cumulative‑order task to encourage daily ordering and higher spend.

Milestones and Business Process

Since its launch in November 2022, the feature has progressed through four versions, each adding flexibility and operational depth.

1.0 Phase – Dark Box

Core gameplay: When users meet certain criteria on the sign‑in page, a task layer appears showing "accumulated amount" and "already saved amount". Daily orders increase the saved amount, and once the target is reached, the system issues a grocery‑money red‑packet.

2.0 Phase – Light Box

The difficulty and reward conditions are exposed, allowing users to see how many more orders are needed for the final reward, making the task transparent.

3.0 Phase – Lottery

A lottery layer is added to increase fun and randomness. Different prizes and probabilities control cost, while a top prize of 100 CNY attracts participation.

4.0 Phase – Full‑Link Guidance + Process Rewards

To improve exposure, the task is integrated into multiple entry points (home page, post‑purchase page) and linked to a unified rights‑supply pool. The system shifts from "cumulative return" to "order‑by‑order return", rewarding users for each qualifying order.

Technical Thinking and Implementation

The cumulative‑order task is abstracted as a special task type within the interactive platform, which serves as the middle‑end for all interactive activities. The platform provides task acquisition, progress, completion, and reward logic.

Architecture Evolution

First stage (1.0‑3.0) featured a lightweight front‑end + middle‑end split, enabling rapid iteration. The second stage (4.0) introduced a unified rights‑supply interface, allowing various front‑ends to request task rendering with configurable parameters.

Task Rendering Process

Query task templates based on scene and type.

Retrieve corresponding rule templates.

Match rules against user context.

Aggregate matched results.

Handle match failures by checking existing instances.

Collect all valid tasks.

Fetch task records.

Fetch reward issuance records.

Convert models for front‑end consumption.

Task Acquisition Process

Front‑end calls gateway to claim task.

Validate task template.

Check if user already has an active instance.

Validate acquisition rules.

Create a generic task instance.

Populate cumulative‑order specific fields.

Persist instance to DB.

Return instance data to front‑end.

Task Advancement Process

When a user places an order, the transaction system sends a message that triggers the following steps:

Receive order message.

Build order event for the interactive domain.

Check idempotency against existing task instances.

Validate advancement rules.

Apply priority rules for multiple tasks.

Calculate progress contributed by the current order.

Update task instance.

Record the order‑task link.

Determine if a reward should be issued.

Issue reward via downstream service.

Execute lottery‑specific post‑processing if applicable.

Notify downstream systems for user‑side display.

Conclusion and Outlook

The cumulative‑order product has grown from a simple “order X times to earn money” concept into a versatile platform supporting multiple reward types and full‑link deployment across the app. Technical iterations have kept the system lightweight while improving scalability and maintainability. Future work will continue to enrich gameplay, abstract flexible product functions, and further empower fine‑grained user operations.