Skip to content

CONCEPT Cited by 1 source

Viewer-friend closeness

Definition

Viewer-friend closeness is the ML-estimated strength of relationship between two connected users on a social product, used as a ranking / retrieval signal when deciding which of a viewer's friends' interactions are relevant enough to surface in a recommendation context (e.g. "show a friend bubble on this Reel because friend X liked it").

Closeness is distinct from:

  • Connection strength — a raw graph-structural feature (mutual friends, interaction count, time-known). Closeness uses these features but outputs a learned score calibrated against direct closeness labels.
  • Interaction probability — P(user clicks | impression) — a lower-level per-event prediction closeness is often an input to.
  • Affinity / engagement score — a generic relevance score; closeness is specifically the social-relationship axis.

Canonical wiki reference

Meta Friend Bubbles (sources/2026-03-18-meta-friend-bubbles-enhancing-social-discovery-on-facebook-reels, 2026-03-18) uses two complementary closeness models:

  1. Survey-trained closeness model — the canonical ground-truth anchor:
  2. Labels come from a "lightweight binary survey" asking randomly selected users "whether they feel close to a specific connection in real life."
  3. Structured as a binary close-vs-not-close prediction problem, refreshed regularly to keep labels current.
  4. Survey includes proxy questions for offline relationship strength (e.g. "how often two people communicate").
  5. Features: social-graph features (mutual friends, connection strength, interaction patterns) + user attributes (user-provided location, number of friends, number of posts shared — Meta calls this set "a broader set of signals").
  6. Production inference scale: weekly inference over "trillions of person-to-person connections across Facebook friends." This is the single disclosed number in the post and places closeness firmly in the precomputed feature category — suitable for a feature store online lookup at request time, not a per-request model call.

  7. See patterns/survey-trained-closeness-model for the pattern.

  8. Context-specific closeness model — adapts to the specific surface:

  9. Trained on on-platform activity signals — "real interactions that occur when bubbles are shown (for example, likes, comments and reshares)."
  10. Captures closeness in context — how likely a viewer is to value content recommended by someone in their friend graph based on platform-mediated interaction.
  11. Meta's framing: the survey model is the foundation; the context-specific model picks up the "relationship dynamics behind friend-driven recommendations" that the foundational model doesn't capture.

How the two models compose (additive? re-ranker? adjustment term?) is not disclosed in the post.

Why surveys as labels

Closeness is not directly observable from platform activity — two close real-life friends might interact rarely on the platform, and two platform-heavy-interacting accounts might be weak ties. Survey labels answer the question "do you actually feel close to this person?" — the underlying latent variable the platform wants to approximate for downstream ranking.

Survey labels are:

  • Expensive — require asking users.
  • Sparse — only a subset of user-friend pairs are surveyed.
  • Noisy — self-reported, subject to framing + recency effects.

Counterbalancing those costs, surveys are the only label source that directly encodes the target quantity. Proxies (interaction counts, message volume, tagged photo overlap) are cheaper but optimise-to-proxy failure modes when used as training labels directly. Meta's architectural choice: use interactions as features, use surveys as labels.

Usage in the ranking pipeline

Closeness is used in two places in the Friend Bubbles pipeline:

  1. Retrieval — close-friend pairs above a threshold drive candidate sourcing (expand top of funnel with friend-interacted content). See concepts/retrieval-ranking-funnel.
  2. Ranking features — closeness scores become features in the MTML ranking models, both directly and as part of the conditioning on P(engage | bubble impression) via patterns/conditional-probability-ranking-objective.

Prevalence gating: Meta sets a "conservative threshold for which friends are eligible to appear" so bubbles only show when the closeness signal is strong. Prevalence is not the optimisation target; engagement quality is.

Scale of precomputation

Meta's disclosure — "trillions of person-to-person connections" inferred "weekly" — implies:

  • Rough order-of-magnitude: 10¹² connection pairs × weekly cadence ≈ 10¹² scores/week.
  • Storage + serving via online feature store; closeness is lookup-fast at request time.
  • Refresh frequency balances label staleness (relationships drift) vs compute cost (full-fleet weekly inference is expensive).

Context-specific closeness likely has finer refresh cadence (driven by live bubble-click events), but this is not specified.

Caveats

  • Only "foundational" survey model is deeply described. Context-specific model architecture + composition rule not disclosed.
  • Survey framing matters. "Do you feel close to this person in real life" is a binary — loses information about degree and about the type of closeness (family / romantic / professional / social). The post does not discuss label richness.
  • Privacy / self-targeting risks. Closeness over trillions of pairs is a sensitive derived signal. Meta's Privacy Aware Infrastructure + concepts/purpose-limitation posture covers the generic case; closeness-specific privacy controls are not discussed in this post.
  • Cold start is unsolved. Users with limited friend graphs are listed as future work — the current system doesn't handle low-connection cases well.
  • Closeness ≠ content affinity. Two users with high closeness may still have divergent taste. The conditional-probability ranker (P(engage | bubble)) is what bridges closeness to content relevance — closeness alone is insufficient.

Seen in

Last updated · 319 distilled / 1,201 read