Every recommendation system answers the same question: given this viewer, what should they watch next? Point the signals at a person, rank the catalogue against their taste, serve the top of the list. It is one of the most worked-on problems in software, and on a creator platform we built a feed that does exactly this, well.
But a feed solves the viewer's problem. It does nothing for the person the whole platform depends on, the creator, who wakes up with a harder and lonelier question: what should I make next?
Creators ask it constantly, and they mostly answer it with vibes. A guess, a trend they half-noticed, a thing that worked once. Meanwhile the platform is sitting on the exact data that would answer it properly, and pointing all of that data in the wrong direction, at the viewer, never at the maker.
So we turned the arrow around.
Same data, opposite direction
A recommendation engine takes a person and finds content for them. Affinity takes a creator and finds content ideas for them, out of the behaviour of the people who already watch them.
The mechanism is almost embarrassingly direct once you say it out loud. Take everyone who watches a given creator. That is their cohort, the audience they have actually earned, not a demographic guess. Now look at what else that cohort watches, across the whole platform. The topics that get a lot of attention from your audience, but that you have never covered yourself, are the gap. That gap is the recommendation, and it is pointed at the creator instead of the fan.
It is the same raw material a feed uses, the same views and signals, read backwards. A feed asks "what does this person like, so I can show them more of it." Affinity asks "what does this creator's audience like, that this creator isn't giving them." One serves the next video. The other serves the next idea. Same data. Opposite direction.
The output is not a vague mood board. It is a short, specific list: here are topics your own audience clearly cares about, ranked by how much attention they give them elsewhere, filtered down to the ones you have not made. A creator can read it in ten seconds and know where their next video should probably point. It replaces a guess with a measurement, which is the entire job.
Weak signals must stay weak
The honest difficulty is that not all evidence is equal, and if you pretend it is, you will hand creators confident nonsense.
A view where we can see the person watched most of the way through is strong evidence of real interest. A view where all we know is that the video started is much weaker, it could be a scroll-past, a misclick, a second of curiosity. Both are "views." Only one means anything.
So weak signals count weakly. A view without progress data still contributes, because throwing it away would waste real information, but it is down-weighted so it can never masquerade as a finding. The rule I hold to is that missing data must never be able to impersonate a strong signal. The moment thin evidence gets to speak as loudly as thick evidence, your recommendations start inventing demand that is not there, and a creator spends a week making the wrong video on your advice. Weighting is not a tuning detail here. It is the difference between a tool creators trust and one they learn to ignore.
Privacy floors that configuration can only tighten
Here is where inverting the arrow gets genuinely dangerous, and where most of the engineering care actually went.
A feed points data at the person it came from, which is privacy-preserving almost by accident: I am telling you about yourself. Affinity points one person's data at someone else. I am telling a creator about their audience. Do that carelessly and you have built a machine for de-anonymising viewers, where a creator with a small enough audience could read "what my cohort watches" and effectively read what specific, nameable people watch. That is not a feature with a privacy risk. That is surveillance with a nice dashboard.
So the protection is not a policy, it is a floor built into the code. There is a minimum cohort size and a minimum per-topic audience size, below which the system simply does not report. If your audience is too small, or too few of them watch a given topic, you get nothing back for it, full stop, because anything we told you would be about identifiable individuals rather than an aggregate.
And the direction of that floor only goes one way. Configuration can make the thresholds stricter. It can never make them weaker. There is no setting, no flag, no quiet deploy that turns the safeguard down. If someone ever wanted to loosen it, they would have to change the code and have that change reviewed, in the open, as the deliberate act it is. The floor is the default and the floor is the minimum; the only knob available points toward more privacy, never less.
I care about that asymmetry more than I care about the feature. Features drift. People add a config option "just for this one partner," and six months later the safeguard is off everywhere and nobody remembers deciding that. A floor that configuration can only tighten cannot drift in the dangerous direction. The worst a careless change can do is make the tool more cautious. That is the kind of mistake I am happy to let the system make.
The question worth stealing
The lesson generalises past video. Most products run their intelligence in one direction, toward the consumer, because that is who the recommendation literature is about. But there is almost always a second party, the maker, the seller, the supplier, asking the mirror-image question and answering it blind. The data to help them is usually already in the building, pointed the other way.
Recommendation asks what someone should consume. Turn it around and ask what they should create, put a hard privacy floor under it so "help the maker" never becomes "expose the audience", and you have built something the consumer-facing version never could: a tool for the people who make the thing worth recommending in the first place.