Design and Implementation of a New Event‑Tracking Framework for Dada Delivery

With rapid business growth, Dada Delivery found its existing event‑tracking data unreliable, prompting a complete reconstruction of the tracking framework.

The old framework suffered from inaccurate data (loss, duplicate and infinite reporting), low reporting success (around 70%), and poor portability due to tightly coupled modules.

The reconstruction goals were to eliminate data loss, raise the success rate above 99%, and make the SDK highly portable for other apps.

To reduce coupling, the new framework splits the tracking process into three independent functional modules: collection, storage, and reporting. Each module runs in its own single‑thread pool, preventing thread‑blocking issues and improving performance.

The overall SDK is organized into three layers:

Interface layer – exposes SDK initialization, code‑based tracking APIs, and configuration to external business code.

Business core library – contains a management module and three subsystems (data collection, storage, and reporting). Each subsystem handles its own logic while the management module coordinates initialization and interaction.

Underlying library – provides the basic utilities and common libraries required by the SDK.

Two reporting modes are provided: real‑time reporting for time‑critical events and scheduled reporting for less urgent data. Real‑time failures are retried by the scheduled task, ensuring no data is lost.

Real‑time reporting flow: the app triggers a code point, data is validated and merged with common device/user info, then handed to the storage subsystem, which formats it, creates a storage task, and simultaneously forwards it to the reporting subsystem. Reporting tasks are queued in a single‑thread pool limited to 128 entries; excess tasks are dropped to avoid OOM. After reporting, the management module updates the upload count or deletes the record.

Scheduled reporting runs a periodic task that batches pending records, reads a fixed number per batch, and reports them sequentially to prevent memory overload. Successful reports delete the data; failures increment the upload count, and records exceeding a predefined limit are also removed.

To avoid re‑reporting data that is already being processed, the framework maintains a timestamp of the last successful real‑time report; only records older than this timestamp are considered for scheduled retries.

Each log entry receives a unique tag generated from device information and a timestamp, allowing the system to distinguish duplicate reports from rapid user actions.

An uploadCount field limits the number of retries for a single log; exceeding the limit triggers deletion, and the field is used to compute average retry rates.

A daily statistics table records the number of events sent and successfully reported per device, enabling success‑rate calculations.

Results: the new framework increased event volume by 20%, achieved a 99.912% success rate with a 1.2% retransmission rate, and demonstrated high portability—both merchant and rider apps integrated the SDK with roughly 50 lines of configuration and two days of effort per team.

Future plans include adding event‑list and search features, integrating tracking into common UI components, and applying SPM concepts to improve design and development efficiency.

Overall, the new event‑tracking framework delivers reliable, high‑throughput data collection while being easy to adopt across multiple mobile applications.