From Sun Team to Greg: The Feed Trap
Lecture 1

The Mobile Feed Revolution

From Sun Team to Greg: The Feed Trap

Transcript

From Sun Team to Greg — that's where this story begins. A small team of engineers, once known internally as the Sun Team, handed off a prototype feed-ranking system to a product lead named Greg. Greg's first question was blunt: why does the app show me the same three content types every session? That question cracked open one of the hardest problems in modern software. Recommender systems are information-filtering tools that automatically suggest items judged relevant for a specific user, based on past interactions and preferences. Modern mobile content apps — social feeds, video platforms, news readers — rely heavily on these systems to construct personalized feeds that determine what each user sees first. The Sun Team's handoff to Greg wasn't just a product moment. It was a microcosm of a revolution happening across every major consumer platform. Now, here's what makes mobile recommendation genuinely different from anything that came before it. Think of a desktop user: they open a browser, type a query, and wait. They are pulling content toward themselves. A mobile user does the opposite. They unlock a phone, and content pushes itself at them within milliseconds. The speed of the thumb — that rapid, almost unconscious scroll — means the system must predict intent before the user consciously forms one. Mobile recommender systems are distinguished from desktop-oriented systems by constraints including limited screen space, intermittent connectivity, and strong reliance on contextual signals like location and time. That means the architecture cannot afford to be slow, vague, or wasteful. Every pixel of screen real-estate is contested. One wrong item in position one, and the user is already gone. The key idea behind handling that scale is a three-stage pipeline. Stage one is candidate generation. It narrows a corpus of potentially millions of items down to a few hundred or thousand relevant candidates using fast approximate models or heuristics. Stage two is scoring. Machine learning models assign a relevance score to each candidate, incorporating user features, item features, and contextual signals. Stage three is re-ranking. This is where business and user-experience constraints enter — diversity, freshness, and avoiding repetitive content clusters. Large-scale industrial recommender systems, like those used for video feeds, commonly separate candidate generation and ranking into distinct neural networks, improving both scalability and recommendation quality. For example, a video platform might generate two thousand candidates in milliseconds, score them with a deep neural network, then re-rank the top fifty to ensure the user doesn't see five consecutive clips from the same creator. Each stage trades some precision for speed. Together, they make the impossible feel instant. Remember that Greg's original complaint was about repetition. That problem lives in the signal layer. Mobile systems must handle implicit feedback — clicks, scrolling, dwell time, skips, watch time — far more than explicit ratings, because mobile users rarely stop to rate content manually. Dwell time and scroll depth are among the highest-fidelity signals available. A user who pauses on an article for forty seconds is telling the model something a simple tap never could. Deep neural network-based recommenders learn user and item embeddings from large-scale interaction data, then use those learned representations to predict which feed items a user is likely to engage with. Interaction data including impressions, taps, likes, shares, and watch time are logged and transformed into features that drive continuous retraining of recommendation models. One notable and surprising aspect of this loop: many systems optimize primarily for predicted engagement — clicks or watch time — which can unintentionally amplify sensational or polarizing content. Session frequency matters more than session duration here. A user who opens the app twelve times a day for two minutes each generates richer, faster feedback than one who browses for an hour once a week. The takeaway from this opening chapter is precise and worth holding onto. Mobile-specific constraints — limited screen real-estate, the speed of the thumb, and high session frequency — are not minor engineering inconveniences. They are the architectural forcing functions that shaped every design decision in modern recommendation pipelines. The three-stage structure of candidate generation, scoring, and re-ranking exists specifically because no single model can be both massive in scale and extreme in speed simultaneously. Implicit signals like dwell time exist because mobile users vote with their attention, not their words. And the feed you see when you unlock your phone is not random, not editorial, and not neutral. It is the output of a system that Greg's question helped make sharper — and that you are now equipped to understand from the inside out.