Spotify ML Recommendation Engine
Spotify's ML recommendation system: collaborative filtering, NLP analysis, and personalized playlist generation.
What is Spotify's recommendation architecture?
Spotify's recommendation architecture is the system that chooses a small set of songs, artists, podcasts, or playlists for one listener from a catalog far too large to inspect one item at a time. It combines long-term listening history with the listener's current session, then returns results quickly enough to feel immediate.
In plain language: the system first finds plausible music, then decides what belongs near the top, and finally applies product rules such as diversity and availability. The central design problem is not just predicting a click. It is balancing a familiar, low-risk next play with worthwhile discovery while keeping the response fast and explainable.
Recall
Retrieve a few thousand
Use several inexpensive sources, such as listening similarity, audio similarity, follows, and local popularity, so relevant tracks enter the pool.
Precision
Rank the current moment
Score a bounded pool using listener history, session signals, and the product surface rather than treating every context the same.
Policy
Shape a healthy slate
Remove ineligible results and prevent repetition so one artist, mood, or already-known track does not dominate the experience.
Define the decision before the model
This case study focuses on a personalized music surface such as a home shelf, Daily Mix, radio queue, or discovery playlist. A recommendation request needs an ordered slate, not a single prediction: a listener can skip the first track, continue listening, save a song, or leave the product.
The first version should answer these questions explicitly:
- Who is the listener and what is the moment? Account history, session sequence, device, locale, time, and surface intent can change what is relevant.
- What outcome matters? Completion and saves are useful positive signals; rapid skips, hides, and repeated exposure are negative signals. Longer-horizon satisfaction needs separate measurement.
- What is in scope? Candidate retrieval, ranking, slate policy, event logging, and fallback serving are in scope. Licensing, catalog ingest, playback delivery, and payments remain upstream dependencies.
- What must never happen? Do not return unavailable content, repeat an item already played in the session, or let an experimental model bypass listener safety and product policy.
An impression is a training fact. Log the candidates, their positions, the selected slate, policy decisions, and model versions before interpreting a play or skip as preference.