Slates, Page Layout, and Position Interactions

A page is not a list. Position, row identity, card design, screen size, scrolling, repetition, and neighboring items all influence attention and choice. Item-level scores therefore do not fully determine slate value or observed feedback. Building a page may require row-level objectives, deduplication across modules, business rules, and optimization that accounts for how the items interact on screen. And logging must preserve the page as it was actually shown. Otherwise none of it can be checked afterwards.

Attention on a page is scarcer than a ranked list makes it look, and the scarcity has been measured in production. Google replaced the myopic engagement score in YouTube's ranker with a long-term-value estimate and ran it on live traffic for three weeks. The system had O(10^9) users and O(10^8) corpus items. The change produced statistically significant aggregate engagement gains over the production myopic baseline. The 2019 SlateQ paper states the arithmetic of the surface being optimized: “Top 3 positions account for approximately 95% of engagement.”

Read that number back into the ranking problem. A model scores a corpus of O(10^8) items and emits a sorted table. In terms of what users experience, it is choosing three slots and disposing of the rest. The decision is the slate.

Different models power different rows of the Netflix homepage. A row is a decision unit with its own model, not a slice of one global ranking. Netflix set out how that page is built in a 2021 case study, and named the catch that comes with it. Each model is trained on user actions collected under the recommendations previously shown. So a feedback loop amplifies the presentation and position biases already sitting in the logged interaction data.

“This is due to presentation bias, where users are more likely to interact with items shown more prominently by the system,” the Netflix authors write.

The symptom they report turns up in the release process rather than in a paper: a notable mismatch between offline and online metrics. The offline number is computed on interactions the previous layout produced. The online number is produced by the layout that ships. The gap between them is the loop, arriving disguised as a measurement problem.

Attention is scarce and a page is not a list. Candidate relevance ranks the items and estimates their value for the current context. The container decides what each row is for — continue, discovery, trending, sponsored, task-specific — before any item is scored for it. That is why different models power different rows of the Netflix homepage. Position allocation then hands out the slots people actually look at. Those slots are few. SlateQ measured approximately 95% of engagement in the top 3 positions; the Commission's decision put approximately 95% of generic clicks in the ten highest-ranking results on page 1. Cross-item interaction controls redundancy, complementarity, pacing and visual competition among the items that share a slate. Creative and explanation comes last. It is what keeps a team from reading a good thumbnail as a good item.

Duplicate modules are visible on the page the day they ship. Layout migration is invisible and slower. A redesign quietly invalidates the historical interaction and calibration assumptions every model on the surface was fitted under.

Between those two sits the failure that hides in the denominator. “Impression” is an event a client can fire without anybody having looked at anything. The advertising industry stopped accepting that definition more than a decade ago. The Media Rating Council's viewable ad impression guidelines, issued in 2014 and updated in 2015, set the test for a viewable display impression: “Pixel Requirement: Greater than or equal to 50% of the pixels in the advertisement were on an in-focus browser tab on the viewable space of the browser page, and • Time Requirement: The time the pixel requirement is met was greater than or equal to one continuous second, post ad render.” The pixel test must be satisfied before the timer starts. Large display ads, of 242 500 pixels or larger, are held to 30% of pixels instead. A viewable video ad impression requires 2 continuous seconds of play.

A recommendation surface is not obliged to adopt those exact numbers. It is obliged to have numbers.

Specify the layout unit first: rows, cards, slots, scroll behavior, and what visibility actually means on this page. Then assign module purposes, separating continue, discovery, trending, sponsored and task-specific roles. Then control cross-module duplication with priority and user-state rules. Then log presentation — position, container, creative, viewport, and interaction timing. The final step treats a redesign as what it is: a change of policy and a change of data distribution, arriving together.

Step four is where the contract is usually lost. There is a published production example of both the loss and the repair. Deezer's swipeable homepage carousel holds L = 12 playlist cards drawn from 862 curator-made playlists. Only L_init = 3 of them are visible before the user swipes. What the app can record is not what the user saw. “As a consequence, the card display information is ambiguous, and is technically hard to track with accuracy,” Deezer's engineers wrote in 2020.

The repair is to model the ambiguity instead of overwriting it. Their cascade-based update treats unswiped cards as unseen rather than as zero rewards. Policies using it beat their no-cascade variants at the 1% significance level, in 100-round simulations and in an industrial A/B test run on the live app in February 2020. They also released a public simulation dataset built on 974 960 fully anonymised Deezer users, each represented by a 97-dimensional feature vector. Deciding what an unswiped card means is a modelling decision with a measured price. It is not a logging detail.

Use position-aware metrics, viewport exposure, row interaction, scroll depth, duplicate rate, slate diversity, and task outcomes. A page-level gain should also be checked for module cannibalization. Moving clicks from one row to another is not incremental product value.

The evidence that a click carries its rank is old, and it is direct. An eye-tracking study at Cornell, reported in 2005, watched students use Google while a proxy silently altered the ranking before the results reached the screen. Phase I recruited 34 undergraduates, 29 of them with usable gaze data. Phase II recruited 22 more, 16 usable, split across a 'normal' condition (6 subjects), a 'swapped' condition (5) and a 'reversed' condition (5). In the normal condition, users clicked the more relevant of the top two abstracts in 19 of the 20 cases where it was ranked first. Where it was ranked second, they did so in only 2 of the 7 cases. The same bias toward link one persisted when the top two results were swapped. Joachims and his co-authors name the effect in their introduction: “First, we show that there is a “trust bias” which leads to more clicks on links ranked highly by Google, even if those abstracts are less relevant than other abstracts the user viewed.”

Three years later, in 2008, Craswell and three co-authors put the competing explanations against each other. They tested four hypotheses about position bias against a logistic regression baseline. The data came from deliberately perturbing the ranking of a major search engine. Simple attention-decay and indiscriminate-rank-1-clicking models did not fit it. What did: “A ‘cascade’ model, where users view results from top to bottom and leave as soon as they see a worthwhile document, is our best explanation for position bias in early ranks.” A click at rank one and a click at rank ten are not the same measurement. The user reached rank ten only by declining everything above it.

Randomized position experiments are the clean way to separate presentation from item effects. They are not free. The standard identification device is the Swap(1,k) intervention, which randomly moves the rank-1 result into position k. A 2019 paper by Agarwal and colleagues prices it: “While this provides provably consistent propensity estimates for the PBM, it degrades retrieval performance and user experience [29] and is thus costly.” It is also statistically inefficient. Their alternative is to harvest intervention data from historic logs of several different ranking functions, and they evaluate the resulting extremum estimator on two live systems, arXiv Full-text Search and Google Drive Search. A team that has shipped more than one ranker has already run part of the experiment.