Reasons expose data sources and can make users feel tracked

What it is

“Because you watched this at 2 a.m.” is often scarier than the item — what scares is not the row, it is the system speaking a behaviour the person thought was private. Tracking leakage through reasons is explanation, in the name of being specific, laying out source, time, device, or cross-site behaviour, so the user realises for the first time that they are being continuously recorded. The unease then attaches to personalization as a whole, not to this one row.

Specificity is a virtue of reasons. Leakage is specificity’s side effect.

Why it happens

People’s model of collection is often “it remembers what I tapped.” Once a reason names a timestamp, another app, an abandoned search, a device that was listening, the model upgrades to “it watches throughout.” The upgrade is a surveillance schema, not stronger predictability. Unease targets the grain of the source, not whether the sentence is faithful.

Cross-surface leakage is sharpest: shopping citing search, content citing location, a notification citing playback that was muted. Each teaches that a record made here will speak there. People then stop producing citable behaviour, or they turn off recommendation entirely, including the parts they actually used.

Studying it

Hold the basis fixed; rewrite source grain: category only, exact title, time, device, cross-app. Measure felt surveillance, usefulness of the reason, willingness to keep producing that kind of behaviour. Independent variables: source kind (in-product playback / cross-site / location / abandoned search), whether that source can be switched off. Dependent variables: creepiness-style scales, usefulness, later behavioural contraction.

Usefulness and unease can both be high. Do not net them into one score. Report which source grain turns “aid for open/skip” into “I am being watched.” Writing an inferred identity on the interface is another disclosure layer; the stimulus here is naming the behavioural source.

Where it stops holding

Citing an act just completed in this session (“because you searched screwdriver”) usually sits inside expectation. When law or safety requires naming a source, unease is not a reason to drop the notice, but the wording should stay neutral. Children separate “recommendation” from “a parent is watching” less well; leakage hurts more. This entry does not treat reasons as persuasion, and it does not treat repeated sentence templates as leakage.

Applying it

• By default, cite only sources the user expects: explicit plays, follows, and purchases inside this product. Cross-app, exact time, location, and abandoned search stay out of the reason by default.
• Give a per-source switch: after “do not use my search to explain recommendations,” search terms must not appear in the rail.
• Check: show reasons about to ship to people who do not work on the product, and ask “what else does the system know about you?” If answers go beyond voluntary in-product acts, grain has overshot. Drop those sentences to category level and retest whether unease falls.

Related

• Same group: L6.07.1 A reason helps the user decide whether an item is worth opening, not to persuade them to open it · L6.07.2 Reasons must come from the actual ranking basis; a post-hoc story is another kind of hallucination · L6.07.4 Reasons make recommendations rebuttable, so users can correct a wrong profile · L6.07.5 The same sentence on every item conveys no information
• Nearby: L6.06 Inferred Preferences and Their Limits · L6.01 Recommendation Reasons · L5.05 The Moderation Principle of Transparency
• Search terms: tracking leakage through reasons · creepy recommendations · explanation privacy