Skip to content

CONCEPT Cited by 1 source

Fallback experience

Definition

A fallback experience is a designated Zalando Experience that the Rendering Engine / domain backend resolves to when the selection-metadata rules produce an ambiguous result — typically more than one candidate Experience matching the request at once. Zalando's own framing: "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 problem it solves

Consider: a customer searches for "Nike Adidas" or applies two brand filters in the catalog where each brand independently has its own Experience. Both Experiences' selection rules match. The options for conflict resolution are:

  1. Pick one via priority — e.g. alphabetical, most-recent, highest-ranked — but any deterministic rule is arbitrary from the brand's perspective and may violate contractual expectations.
  2. Merge policies — but policy values are not generally mergeable: THEME must be a single value, and taking the intersection or union of two themed experiences produces an incoherent UI.
  3. Fallback to a neutral Experience — a named default that contains the consistency-defaulting policies (grey packshot, show-sale-prices, etc.).

Zalando chose option 3. The fallback isn't an absence of an Experience — it is an explicit Experience object whose Policies describe the neutral / default presentation.

Why an explicit fallback beats a null

If the absence of a matching Experience meant "use default styling", the default styling would live in downstream backends as branching logic ("if no experience, use grey background"). By making the fallback a first-class Experience:

  • Backends have one code path — apply whatever Experience's policies they receive. No conditional logic for the "no-experience" case.
  • The default presentation is declared as data, editable without a code change.
  • The fallback is diffable against branded Experiences — comparing Policies between a branded Experience and the fallback shows exactly what the Experience is changing.

Not disclosed

  • Whether Zalando has one global fallback or multiple fallbacks (e.g. per market, per surface).
  • The exact trigger algorithm — does any ambiguity fall through to the fallback, or are there classes of ambiguity that use priority rules instead?
  • How fallback interacts with merchant-level-global policies (the post mentions "some which were global on the merchant level" as a category of policy).
  • Whether the fallback is itself eligible to be matched via selection metadata, or only engaged as a pure default.

Seen in

Last updated · 550 distilled / 1,221 read