Dada Platform Data Collection Migration: Value, Process, Architecture, and Technical Highlights

Using the group's unified data‑collection capability and platform, the migration of 43 site applications across seven Dada business lines was completed, reducing self‑developed tool and platform development costs, lowering machine expenses, opening data pipelines, and creating greater data‑analysis value.

Data analysis value: Integration with JD traffic data aligns metrics, connects user information (device_id, pin/supplier_id), and enables comprehensive flow analysis.

Reduced iteration/maintenance manpower: Saves approximately 0.5 person‑year, decreasing platform iteration and traffic transmission maintenance costs.

Machine and middleware cost savings: Eliminates two cloud hosts and saves around ¥20,000 per year in middleware fees.

Project schedule:

Solution research and selection: Two migration plans were evaluated; after comprehensive assessment, Plan 1 was chosen for minimal migration cost.

Implementation flow:

Technical architecture considerations: Stability and efficiency were prioritized; a direct replacement was infeasible, so an aspect‑interception approach was adopted, allowing a single interception point to replace numerous embedded data‑collection calls.

Design example (client side): The original framework’s three independent stages (collection, storage, reporting) were modified by inserting an aspect between collection and storage to transform data, as shown in the diagram

and the old framework architecture image.

Implementation grouped projects by platform (Android, iOS, mini‑program, H5), reducing dozens of projects to a unified solution, saving substantial development effort.

Technical highlights: 1) Aspect‑interception migration saves manpower; 2) Unified encapsulation enables cross‑platform reuse and consistent data‑collection standards; 3) Data‑warehouse layer consumes JD real‑time topics, aligns data structures, and achieves seamless downstream migration with minimal impact.

Pitfalls and solutions: iOS background reporting unsupported (added unlimited background config); iOS network permission issue (provided SDK without 2‑minute limit); reporting strategy too sparse (adjusted to 2 s/2 events); UID empty for new users (generated encrypted placeholder ID); mini‑program batch reporting mismatch (SDK now supports batch); H5 high‑volume data drop (removed session_id limit in data‑warehouse).

END