Design and Evolution of Vivo's Points Task System
This article details the conception, architectural evolution, and technical implementation of Vivo's points task system, covering its business model, Fogg behavior model, multi‑stage development, behavior SDK, data collection, rule engine, system stability measures, and future enhancements.
The article introduces the points system as a common marketing tool and explains how Vivo's internet business has rapidly expanded its capabilities, focusing on the points task subsystem that drives user engagement and business loops.
It defines a points system, cites examples like Taobao coins and JD beans, and outlines Vivo's three main components: the Points Mall, Task Center, and Activity Center, emphasizing their role in enhancing user motivation.
Using the Fogg Behavior Model—motivation, ability, and trigger—the article explains how tasks are designed to encourage valuable user actions and describes the three development phases of the system.
Phase 1: Exploration involved analyzing the business model, defining task models, cycles, and states, and setting system goals such as rapid task configuration and status recording. The initial design relied heavily on manual logic, leading to high development costs.
Phase 2: User Behavior Incentive System addressed pain points like long cross‑project cycles and low operational efficiency. It introduced a behavior SDK for configuration pulling, event reporting, filtering, and user notification, and added experiment capabilities for A/B testing and user‑tag targeting.
The behavior reporting flow is illustrated, showing SDK activation on app start, event filtering, server‑side calculation, and UI feedback via toast or snackbar.
Phase 3: Expanding Data Sources and Interaction Forms tackled limited data sources and simple notification methods by extending data collection to databases, message queues, and APIs, and enhancing delivery via custom dialogs and message pass‑through.
The system architecture is divided into three services: Event Collection Service (ingestion, filtering, storage), Event Calculation Service (computation, notification), and Task Service (task evaluation, reward distribution, user interaction).
Stability measures include service degradation, circuit breaking, cluster isolation, and asynchronous execution of non‑core functions.
Future directions aim to improve platform extensibility, expand reward types beyond points, support composite sequential events, and enhance real‑time processing to reduce latency.
The article also addresses privacy concerns, clarifying that SDK‑collected data originates from user‑initiated actions and complies with regulations.
Code example for data cleaning and rule calculation:
// 数据清洗过滤
originEvent.pay_status == 1 && string.contains("11,12,13,14,15,16,92,93,95", originEvent.product_type + "")
// 规则计算
let value = eventObject.value / 100;
let success = value >= 1;
return seq.map('success', success, 'data', value);Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.