What "The Algorithm" Actually Is on Your Feed
There is no single algorithm, and knowing that changes how you read a feed

Contents
People talk about “the algorithm” the way earlier generations talked about weather gods — a single, mysterious, faintly malevolent force with opinions about what you deserve to see. I ran a small self-hosted RSS reader for years specifically to get away from that framing, and the thing that finally made feed ranking make sense to me was realising there isn’t one algorithm at all. There’s a candidate pool, a scoring model, and a set of business rules layered on top, and each of those three pieces changes independently, on a different schedule, for different reasons. Once you separate them, “why did I see this” stops being a mystery and starts being a fairly mechanical question with a fairly mechanical answer.
Step One: Candidate Generation, Not Ranking
Before anything gets ranked, most of the content that could theoretically appear in your feed is already thrown out, and this filtering step matters more than people give it credit for, because a post that never enters the candidate pool can’t be ranked highly no matter how good the ranking model is. Candidate generation typically pulls from a few sources: accounts you follow or have engaged with, content similar (by embedding or topic tag) to things you’ve previously engaged with, and content currently spiking in engagement within your rough geographic or interest cluster. This step is usually cheap and approximate on purpose — the goal is to narrow millions of possible items down to a few hundred or few thousand candidates quickly, not to find the perfect answer.
This is the layer most people never think about, and it’s also the layer where “the algorithm doesn’t show me things I follow” complaints usually originate. If an account you follow posts something and it never makes the candidate pool for your specific feed request — because the recency window closed, or because a scoring pass upstream deprioritised low-engagement accounts before ranking ever runs — no amount of “engaging more” fixes that, because the post was never a candidate to rank in the first place. Distinguishing “wasn’t shown because it scored low” from “wasn’t shown because it wasn’t a candidate” is the single most useful mental model for understanding feed behaviour, and almost nobody outside the companies building these systems draws that line explicitly.
Step Two: The Scoring Model
Once there’s a manageable candidate pool, a ranking model scores each item for a specific target, and that target is rarely “what you’d say you want to see” — it’s almost always a predicted probability of some measurable action: will you watch this to the end, comment, share, or spend a certain number of seconds looking at it before scrolling past. These are supervised machine learning models, trained on historical engagement data, predicting a number per candidate per user, and the feed you see is mostly just those candidates sorted by that predicted number, sometimes with several predicted numbers combined with different weights.
| |
That last negative term matters — every major feed ranking system includes some penalty for predicted negative signals (hiding a post, reporting it, unfollowing after seeing it), and tuning the weight on that penalty relative to the engagement weights is most of what a “platform update” actually consists of when a company announces one. Turn the negative weight up and the feed gets calmer and less viral. Turn the positive engagement weights up and it gets louder and more addictive. Nobody outside the ranking team sees these weights change, but users absolutely feel the difference within days, which is why “the algorithm changed” complaints cluster around real internal tuning cycles even when the complaint itself is imprecise about what actually moved.
The model doesn’t know what’s true, interesting, or good for you in any human sense — it only knows what correlates with the specific action it was trained to predict, on a training set drawn from past behaviour on that same platform. This is why outrage and conflict content historically over-performs in unconstrained ranking systems: anger reliably predicts engagement (comments, shares, time spent arguing) even when it doesn’t predict satisfaction, and a model trained purely on engagement will happily learn that correlation and act on it, with no concept that engagement and satisfaction have quietly diverged.
Step Three: Business Rules Bolted on Top
After scoring, a layer of hard-coded rules adjusts the ranked list before it reaches you — diversity constraints so you don’t see five posts from the same account in a row, boosts for content types the platform is currently trying to grow (a new video format, a new feature), demotions for content flagged by trust-and-safety systems, and paid promotion inserted at fixed slots regardless of its organic score. This layer is why two accounts with near-identical engagement can get visibly different reach in the same week — one might be caught by a diversity cap, or a temporary demotion for a borderline moderation flag, that has nothing to do with the underlying ranking model’s opinion of the content’s quality.
This layer is also the one that changes fastest and most opaquely, because it’s implemented as configuration rather than a retrained model, so it can be adjusted in an afternoon in response to a PR problem, a growth target, or an advertiser complaint, with no announcement and no paper trail a user could find.
Why This Explains the Common Complaints
“I only see the same three accounts” is usually a candidate generation effect — your engagement history has trained the candidate pool to over-represent whoever you engage with most, and the loop reinforces itself because more views produce more chances to engage, which reinforces the pool further. “The algorithm buried my post” is usually a scoring effect from early low engagement — most systems weight the first few minutes or hours after posting heavily, because that’s the cheapest available signal before a human reviewer or slower quality signal kicks in, and a post that starts slow rarely recovers because it stopped clearing the bar to stay in later rounds of ranking. “Why am I suddenly seeing ads for something I just talked about” is neither of these — it’s a separate recommendation system, usually built on different signals (search history, purchase data, third-party ad-network data) than the organic feed ranking model, coincidentally converging on the same topic.
It’s Not One Model, It’s Thousands of Running Experiments
The other piece people miss is that “the algorithm” isn’t a single stable thing running the same way for everyone at the same time — large platforms run continuous A/B tests, meaning you and someone sitting next to you scrolling the same platform may genuinely be on different ranking configurations at that exact moment, with different weight values, different candidate-pool rules, or an entirely different experimental model competing against the production one for a slice of traffic. This is standard practice for any system operating at that scale: change one weight, route a small percentage of sessions through the new version, measure whether the predicted metrics actually move in production the way offline evaluation suggested, and only then decide whether to ship it to everyone.
This is a meaningfully different situation from, say, a website changing its layout, because the experiment surface here directly shapes what content billions of individual decisions get exposed to, and by the time an experiment is deemed a failure and rolled back, it’s already influenced what got engagement, which then feeds back into the training data the next model version learns from. A ranking system trained on outcomes that were themselves shaped by a previous ranking system’s choices has a feedback loop baked into its own training data — what looks like a stable, discoverable pattern in your feed today may be a temporary artefact of last month’s experiment leaving its fingerprints on this month’s training set. This is part of why definitively reverse-engineering “the algorithm” from the outside is a fool’s errand: there is no fixed target sitting still long enough to reverse-engineer, only a moving population of models and rules under constant, deliberately staggered revision.
The practical consequence is that any advice claiming to have found “the trick” that beats the current ranking is very likely describing a correlation that held during a specific experiment window and may already have decayed by the time you read it. Posting times, hashtag counts, “engagement bait” opening lines — these occasionally correlate with better reach during a given period, then stop working with no announcement, because the model that rewarded them got retrained or the experiment that happened to favour them concluded. Chasing that moving target is a much worse use of time than producing something a candidate pool would surface on its own merits.
Reclaiming Some Control
Self-hosted, chronological alternatives sidestep all three layers by removing them entirely — an RSS reader like Miniflux or FreshRSS shows you everything a source publishes, in the order it was published, with no candidate generation step deciding what you’re allowed to see and no scoring model deciding what order you see it in. It’s less “smart,” and that’s the entire point — a chronological feed can’t surprise you with something engineered for engagement, because nothing in the pipeline is optimising for engagement at all. I moved most of my daily reading to exactly this setup a few years ago and haven’t missed the “smart” version since; what I lost in serendipitous discovery I gained back entirely in not feeling like a variable in someone else’s optimisation problem.
Troubleshooting: Reading Feed Behaviour Correctly
If a post underperforms, check whether it’s a candidate-pool problem — did the people who’d normally see it actually get it in their pool at all — before assuming it’s a scoring problem; these have different causes and conflating them wastes effort chasing the wrong fix. A quick diagnostic: ask a few regular followers directly whether the post appeared in their feed at all, rather than whether they engaged with it. If it never appeared, no amount of rewriting the caption will help, because the problem happened before scoring ever ran.
If a whole account’s reach drops suddenly and stays down across many posts rather than one, look for a business-rule explanation first — a moderation flag, a diversity cap, a platform-wide push toward a new content format that’s temporarily being boosted at the expense of everything else — before assuming the core scoring model changed for everyone. Rule changes of that kind are far more common, far cheaper to make, and far faster to roll out than a full model retrain, which is a multi-week undertaking most platforms don’t repeat more than a handful of times a year even though users perceive “the algorithm” as changing constantly.
If you want to genuinely opt out rather than just understand the mechanism, chronological RSS remains the most complete opt-out available, precisely because it has no candidate pool, no scoring model, and no business-rule layer sitting between a publisher and a reader — the entire three-stage pipeline this piece describes simply doesn’t exist in that setup, by design rather than by omission.
Is It Worth Understanding This?
Yes, mostly because the mental model of “an inscrutable algorithm decides” is both wrong and disempowering, and the actual mechanism — candidates, then scoring against a specific predicted action, then business rules, all sitting on top of a constantly shifting experiment layer — is simple enough to reason about and occasionally push back against. It won’t make you go viral on demand, but it will stop the platform’s ranking choices feeling like weather, and it’ll save you from chasing engagement tricks that were already stale by the time someone wrote them up. If you’d rather sidestep the whole system, how search engines rank you, roughly covers the closest cousin to this problem in a different domain, and self-hosting a reader is a smaller project than it sounds.




