Skip to content

SYSTEM Cited by 1 source

Pinterest UFR (Unified Feature Registry)

UFR is Pinterest's feature registry — the configuration surface that declares which features are onboarded into which serving path for ads ranking. It governs feature availability across at least two distinct pipelines:

  • The L2 Feature Store used by L2 ranking at request time.
  • The L1 embedding build path that compiles features into Pin embeddings for the ANN index consumed by L1 ranking and retrieval.

Why UFR matters for online-offline parity

Before the 2026-02 post's fix, onboarding a feature for L2 did not automatically make it visible to L1 embeddings. A feature could be:

  • Present in training logs (the ML team's offline view).
  • Present in the L2 Feature Store (request-time serving view).
  • Absent from L1 embedding usage (serving artifact consumed by retrieval + L1).

This three-way split created a silent class of online-offline discrepancy: models trained on rich logged features would unknowingly rely on signals that weren't actually present in the L1 embedding pipeline at serving time. Pinterest found entire high-impact feature families had never been onboarded into L1 embedding usage — targeting-spec flags, offsite conversion visit counts (1/7/30/90 days), annotations, MediaSage image embeddings.

The documented fix

Two changes from the 2026-02-27 post:

  1. Onboard the missing features into L1 embedding usage via UFR config. Online feature-coverage dashboards (feature coverage dashboard) were the ground-truth signal that coverage had recovered.
  2. Change the UFR default so that "features onboarded for L2 are automatically considered for L1 embedding usage." This moved the bug class from a recurring manual onboarding gap to a default-safe behavior.

This is a canonical instance of fixing a class-of-bugs at the tooling-default layer rather than case-by-case — matching the same general pattern as other "change the default so the safe path is the lazy path" fixes on the wiki.

Caveats

The post describes UFR only in terms of its role in the feature O/O story:

  • UFR internals (config schema, validation, deploy model) are not disclosed.
  • Whether UFR extends to engagement models, non-Pin signals, or user-side features is not stated explicitly (though the fix improved "both CVR and engagement models, especially on shopping traffic").
  • The full set of serving paths UFR governs is unclear — at minimum L2 Feature Store + L1 embedding; possibly more.
  • Name disambiguation: UFR is a registry / metadata layer, not the feature store itself.

Seen in

Last updated · 319 distilled / 1,201 read