Backend Development 12 min read

Technical Architecture and Practices of Youku's Demand‑Side Platform (DSP)

This article explains how Youku built and iterated its Demand‑Side Platform, covering business goals, system architecture, channel integration, bidding and frequency strategies, material selection, smooth budget delivery, retargeting, algorithmic recall, data monitoring, and conversion‑funnel optimization to drive user growth.

DataFunTalk
DataFunTalk
DataFunTalk
Technical Architecture and Practices of Youku's Demand‑Side Platform (DSP)

The rise of real‑time bidding (RTB) advertising has pushed many companies to build their own Demand‑Side Platforms (DSP) for user acquisition. Youku has been developing and continuously iterating its DSP, focusing on technical explorations, pitfalls, and solutions.

Business Goal : Increase user growth by acquiring new users and recalling inactive ones, segmenting users into new, low‑active, medium‑active, high‑active, and churned groups, and prioritizing recall for the low‑ and medium‑active segments where acquisition cost and ROI are favorable.

System Architecture : The DSP is organized around four main capabilities—channel, strategy, algorithm, and real‑time monitoring. The architecture diagram (see image) illustrates how these components interact.

1. Channel Capability : Evaluate and select high‑volume, low‑cost RTB ad exchanges (ADX) such as Baidu, NetEase, Guangdiantong, Tanx, etc. Key metrics include install‑rate, user‑layer distribution, cross‑media overlap, daily reachable users, click‑through and conversion rates, and budget allocation. The goal is to build a quality‑aware channel pool and optimize media combinations.

2. Strategy Capability

• Frequency Control : Control participation in bidding, impression, click, and app‑switch frequencies. Different media may require distinct limits to avoid over‑exposure.

• Material Horse‑Race : Dynamically allocate traffic to higher‑CTR creatives while reducing exposure for low‑CTR ones, using a 15‑minute evaluation window and an 80/20 traffic split between the best material and the rest.

• Smooth Budget Delivery : Distribute budget over time based on performance (e.g., higher spend during peak CTR periods) rather than exhausting it in the first minutes.

• Retargeting : Show ads to users who have visited but not converted, increasing conversion rates by presenting relevant products at the right moment.

3. Algorithm Capability : Integrate multiple recall models to personalize out‑of‑app ads:

Playback‑record recall with time decay.

Hot‑program recall (e.g., newly released series).

User‑preference recall (stars, genres).

In‑app behavior recall (favorites, clicks, searches).

4. Data & Monitoring Capability

Define a conversion funnel (see image) and intervene at each stage—bidding participation, winning bids, impressions, clicks, app‑switches, playback, and next‑day retention. Detailed real‑time metrics (e.g., bidding latency, impression volume, CTR, ROI) are monitored to detect anomalies early.

Conclusion : Building a robust DSP requires (1) channel integration, (2) refined bidding and material strategies, (3) algorithmic personalization, and (4) comprehensive monitoring. Future work will address traffic‑value estimation and bidding algorithms.

For collaboration, contact alitvdev‑[email protected]‑inc.com.

advertisingAlgorithmbackend architectureReal-Time BiddingDSPdata monitoring
DataFunTalk
Written by

DataFunTalk

Dedicated to sharing and discussing big data and AI technology applications, aiming to empower a million data scientists. Regularly hosts live tech talks and curates articles on big data, recommendation/search algorithms, advertising algorithms, NLP, intelligent risk control, autonomous driving, and machine learning/deep learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.