CONCEPT Cited by 1 source

Experience (Zalando Interface Framework)¶

Definition¶

An Experience in Zalando's Interface Framework is a named bundle of (policies, selection rules) resolved once per request from the customer's context and then applied to every data-fetch made by every Renderer on the page. Zalando's own phrasing: "Experiences are simply a collection of policies that we need to apply, and a list of selection rules" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).

It is not a page template, not a Renderer, not a theme by itself. It is request-scoped presentation context that sits orthogonal to the Entity tree — Entities describe structure, Experience describes context.

Canonical JSON shape¶

{
  "id": "XP_ID",
  "name": "XP_NAME",
  "policies": [
    {
      "name": "THEME",
      "value": { "name": "THEME_NAME", "theme_config1": [] }
    },
    {
      "name": "PRODUCT__FLAGS__HIDE_SALE",
      "value": true
    }
  ],
  "selection_metadata": [
    {
      "name": "experience_brands",
      "type": "brand_code",
      "value": ["BRANDNAME"]
    }
  ]
}

(Source: sources/2023-06-25-zalando-context-based-experience-in-zalando.)

Two halves:

Policies — what to apply. Each policy is a named, valued directive (THEME, PRODUCT__FLAGS__HIDE_SALE, …) that domain backends read and honour when shaping their GraphQL response.
Selection metadata — when to apply. See concepts/selection-metadata. The selection metadata is a declarative predicate the domain backend evaluates against request context.

Why it exists¶

The motivating problem: the same product must render differently depending on how the customer arrived. A selective-distribution brand's outfit card gets a grey background in the Zalando-default catalog (for cross-brand consistency), but a white background when the customer is inside the brand's elevated experience. Pre- Experience, this would either require (a) duplicating Renderers per variant (explosion of components), or (b) threading context through every GraphQL query by hand (broken invariants when teams forget).

The Experience mechanism picks the right bundle once, stores the name in the Rendering Engine request state, and has FSA pass it to every backend so the backend — which already owns the data shape — applies the right policies.

Resolution and propagation¶

See concepts/root-entity-experience-resolution for the root-entity-time selection step and patterns/request-state-propagated-experience for how the resolved Experience flows to child Renderers. Summary:

Resolve at root: Rendering Engine asks FSA for the root entity; FSA queries the owning Catalog/Search/Product backend; that backend matches request context against all Experiences' selection_metadata and returns the best match.
Stash in request state: the resolved Experience name lives in the RE request state for the lifetime of the request.
Propagate to children: each child Renderer queries FSA independently; the query includes the resolved Experience; downstream backends apply policies from the Experience.

Multi-match conflict: fallback¶

"How to decide which experience to choose when two brands belong to different experiences? … Our approach to solving some cases is to define Fallback experiences, to be able to catch these use-cases" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando). The conflict-resolution primitive is the concepts/fallback-experience — a named bundle that wins when the rule engine can't confidently pick a single candidate.

What "policy" does¶

Policies are not all cosmetic. The post names two examples explicitly:

Policy name	Effect
`THEME` (with a nested `{name, theme_config1, …}`)	Presentation (e.g. packshot background colour)
`PRODUCT__FLAGS__HIDE_SALE` (boolean)	Behavioural — affects catalog admission

The HIDE_SALE example and the post's note that "some brands are only to be shown in the product catalog when the brand or its products are explicitly requested" establish that an Experience can gate product visibility, not just tweak presentation. The policy surface is broader than "theme".

Relationship to other IF primitives¶

Entities — the structure axis. Unchanged by Experience.
Entity→Renderer mapping — unchanged by Experience. Same Entity → same Renderer.
Policy — the thing that changes: which Policies the Renderer's backend call applies.

Seen in¶

sources/2023-06-25-zalando-context-based-experience-in-zalando — canonical introduction of the Experience primitive with the JSON shape, selection-rule semantics, and the worked example of selective-distribution-brand elevation.