A recommender system looks like a prediction machine. It estimates what a user will click, watch, buy, read, like, or share.

But deployment turns prediction into intervention. The system decides what the user sees. The user reacts to what was shown. The logs record that reaction. The next model trains on the logs. After a few cycles, the data no longer describe a passive user choosing freely from a catalog. They describe a user interacting with a policy.

That difference is the whole problem.

Thesis: recommendation data are not preference data. They are exposure-conditioned outcomes. A click answers "what happened after this item was shown here by this policy?" not "what did the user want from the whole catalog?"

This is not just a technical annoyance. Recommenders shape music taste, news consumption, job discovery, dating pools, shopping behavior, scientific attention, political information, and creative markets. If exposure changes preference, then the recommender is not only finding demand. It is participating in demand formation.

The Items Nobody Saw

In causal notation, the observed click is

\[Y_i(1) \quad \text{only for items that were exposed.}\]

For unshown items, the system does not observe \(Y_i(1)\). It observes nothing. The missingness is not random. It is caused by the previous recommender policy, the user’s past behavior, item popularity, position in the interface, and business rules.

Steck made this point early in recommender evaluation: ratings are missing not at random, and this matters for training and testing recommender systems.1 Schnabel, Swaminathan, Singh, Chandak, and Joachims made the causal version explicit by treating recommendations as treatments and adapting propensity-based estimators from causal inference to debias learning and evaluation.2

The core identity is simple. If item \(i\) is exposed with probability \(p_i\), then inverse propensity weighting estimates an average outcome by upweighting rare exposures:

\[\widehat{R}_{\text{IPS}} = \frac{1}{n}\sum_i \frac{E_i Y_i}{p_i},\]

where \(E_i\) indicates exposure. The formula is not magic. It says the logging policy matters. If you do not know how an item came to be shown, you cannot interpret the click as a clean preference sample.

A Click Has a Position in It

Clicks are useful. They are cheap, timely, user-centered, and abundant. They are also biased.

Position bias is the obvious example. A result near the top of a page gets more attention than the same result lower down. Joachims, Swaminathan, and Schnabel derive an unbiased learning-to-rank framework for biased click feedback using counterfactual risk minimization and propensity-weighted ranking losses.3 The lesson generalizes beyond search: presentation changes measurement.

Implicit feedback also has a positive-unlabeled structure. A click is some evidence of interest. A non-click may mean dislike, lack of attention, bad timing, bad position, or no exposure at all. Treating every missing click as a negative label quietly turns the current exposure policy into the definition of relevance.

That is how systems learn their own shadow.

Taste Moves While You Measure It

The psychology matters because preferences are not always fixed parameters waiting to be discovered. Zajonc’s mere exposure work showed that repeated exposure can increase positive affect toward a stimulus.4 Slovic’s work on constructed preference argues that many preferences are assembled in context rather than retrieved as stable, pre-existing facts.5

This does not mean “users are manipulable” in a crude way. It means the interaction loop is part of the object being measured. A recommender can make a category familiar, make alternatives invisible, and then observe that the user chooses the familiar category.

The click is real. The interpretation is the dangerous part.

The Loop Is the Product

Chaney, Stewart, and Engelhardt call this algorithmic confounding: systems are often trained and evaluated on data generated by prior recommendation policies, creating feedback loops that can homogenize behavior without increasing utility.6 Mansoury, Abdollahpouri, Pechenizkiy, Mobasher, and Burke study popularity-bias amplification under feedback loops and show how repeated recommendation can shift exposure toward already-popular items, reduce aggregate diversity, and change the representation of user taste.7

Here is the causal picture:

  1. The policy allocates exposure.
  2. Exposure affects clicks.
  3. Exposure may affect future preference.
  4. Click logs update the policy.
  5. The next policy allocates more exposure based on the changed logs.

There is no point in that loop where the log is a neutral survey.

A Small Feed That Learns Its Shadow

The simulator below creates a catalog with six content categories. A user has an initial taste vector. Each policy repeatedly shows slates of items, observes position-biased clicks, and updates its beliefs. Exposure can also shift the user’s short-run taste toward what has been repeatedly shown, mimicking familiarity and constructed preference.

The chart compares five policies:

  • random, which provides a baseline exposure policy;
  • popularity, which mostly follows catalog popularity;
  • click-only, which exploits observed click rates;
  • causal audit, which reserves randomized traffic and uses propensity-aware category estimates;
  • diversity guardrail, which combines the audit estimate with a category exposure cap.

The Audit tile is a code contract, not a product endorsement. The lab runs 20 deterministic checks over parameter bounds, catalog generation, policy ledgers, click-rate arithmetic, position-bias attenuation, zero-feedback drift, catalog-skew exposure, exploration overlap, and the click-only/diversity tradeoff. Those checks keep the toy feedback loop honest enough for the visual argument below; they do not make it a calibrated recommender benchmark.

Click rate Latent value Diversity Preference drift

Deterministic simulation. The audit checks simulation contracts. Latent value scores the shown items against the user's original taste, while click rate is measured under the post-exposure interaction loop.

The static-site audit runner replays the default programming desk and checks the policy ledger against deterministic outputs:

node - <<'NODE'
const lab = require("./assets/js/recommender-lab.js");
const EXPECTED_AUDIT = { checked: 20, failureCount: 0, ok: true, passed: 20 };
const EXPECTED_DEFAULT = [
  "45:65:12:55:35:420:180:audit",
  "random=0.318452/0.647758/0.923030/0.028446/0.561905/1070",
  "popularity=0.467262/0.757217/0.084343/0.661456/1.000000/1570",
  "click=0.458929/0.728437/0.000000/0.699110/1.000000/1542",
  "audit=0.442560/0.778053/0.250127/0.624133/0.942857/1487",
  "diversity=0.346131/0.713017/0.976728/0.083837/0.471131/1163"
].join(":");

function fixed(value) {
  return Number(value).toFixed(6);
}

function sameJson(actual, expected) {
  return JSON.stringify(actual) === JSON.stringify(expected);
}

const audit = lab.runAudit();
const result = lab.evaluate({
  feedback: 45,
  positionBias: 65,
  exploration: 12,
  catalogSkew: 55,
  familiarity: 35,
  sessions: 420
});
const auditShape = {
  checked: audit.checked,
  failureCount: audit.failures.length,
  ok: audit.ok,
  passed: audit.passed
};
const paramsShape = [
  result.params.feedback,
  result.params.positionBias,
  result.params.exploration,
  result.params.catalogSkew,
  result.params.familiarity,
  result.params.sessions,
  result.catalog.length,
  result.bestValue.key
].join(":");
const policyShape = result.results.map((row) => `${row.key}=${[
  row.clickRate,
  row.latentValue,
  row.diversity,
  row.drift,
  row.headShare,
  row.clicks
].map((value, index) => index === 5 ? String(value) : fixed(value)).join("/")}`).join(":");
const defaultShape = [paramsShape, policyShape].join(":");

if (!sameJson(auditShape, EXPECTED_AUDIT) || defaultShape !== EXPECTED_DEFAULT) {
  throw new Error(JSON.stringify({ auditShape, defaultShape }, null, 2));
}

console.log(`${audit.passed}/${audit.checked} recommender intervention checks passed`);
NODE

Try increasing feedback strength and catalog skew. The click-only policy often looks better by click rate while losing diversity and drifting farther from the initial taste profile. Increase exploration. The audit policy gets cleaner evidence because it sees more of the catalog under known propensities. Increase position bias. Naive click learning becomes less trustworthy because top-slot attention is masquerading as preference.

The point is not that exploration or IPS solves everything. Propensity methods need overlap. Randomized traffic has product costs. Preference drift raises normative questions that a statistical estimator cannot answer. But the causal framing makes the hard parts visible.

Log the Policy, Not Just the Click

A serious recommender system should log more than item ids and clicks:

  1. The exposure policy and the probability of each displayed item.
  2. Position, layout, notification, and timing context.
  3. Randomized exploration slots with known propensities.
  4. Non-click outcomes: hides, skips, dwell time, returns, complaints.
  5. Long-run user-level diversity and novelty, not only session clicks.
  6. Exposure distribution across creators, topics, and catalog age.
  7. Preference-drift diagnostics relative to user-declared or historical anchors.

The last item is uncomfortable but important. If a system changes what users come to prefer, the evaluation question is not only prediction accuracy. It is whether the induced preference trajectory is one the user would endorse with distance and reflection.

Better Feeds Need Causal Product Metrics

The next frontier is not merely better ranking. It is causal product measurement for adaptive preference systems.

That means combining three traditions that are too often separated:

  • recommender engineering, which knows how to serve and update at scale;
  • causal inference, which knows why logged outcomes are policy-dependent;
  • psychology, which knows that preference can be context-sensitive and constructed through interaction.

The practical research program is clear:

  • treat recommendations as treatments with logged propensities;
  • reserve enough randomized exposure to preserve overlap;
  • estimate short-run clicks and long-run welfare separately;
  • measure diversity, novelty, creator exposure, and user fatigue as first-class outcomes;
  • build dashboards that distinguish revealed behavior from induced behavior.

A recommender system is not a mirror. It is a steering wheel with a mirror attached. The click log tells us where the wheel has been pointed.

Source Notes

  1. Harald Steck, “Training and Testing of Recommender Systems on Data Missing Not at Random,” KDD 2010. DOI. ↩

  2. Tobias Schnabel, Adith Swaminathan, Ashudeep Singh, Navin Chandak, and Thorsten Joachims, “Recommendations as Treatments: Debiasing Learning and Evaluation,” ICML 2016. PMLR. ↩

  3. Thorsten Joachims, Adith Swaminathan, and Tobias Schnabel, “Unbiased Learning-to-Rank with Biased Feedback,” WSDM 2017. arXiv. ↩

  4. Robert B. Zajonc, “Attitudinal Effects of Mere Exposure,” Journal of Personality and Social Psychology, 1968. PDF. ↩

  5. Paul Slovic, “The Construction of Preference,” American Psychologist, 1995. PDF. ↩

  6. Allison J. B. Chaney, Brandon M. Stewart, and Barbara E. Engelhardt, “How Algorithmic Confounding in Recommendation Systems Increases Homogeneity and Decreases Utility,” RecSys 2018. arXiv. ↩

  7. Masoud Mansoury, Himan Abdollahpouri, Mykola Pechenizkiy, Bamshad Mobasher, and Robin Burke, “Feedback Loop and Bias Amplification in Recommender Systems,” CIKM 2020. arXiv. ↩