Skip to content

CONCEPT Cited by 1 source

Selection metadata (Zalando Experience)

Definition

Selection metadata is the declarative predicate a Zalando Experience carries to tell the domain backend when this Experience is eligible. It is the mechanism by which customer intent gets matched to a concrete Experience bundle.

Zalando's canonical shape (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando):

"selection_metadata": [
  {
    "name": "experience_brands",
    "type": "brand_code",
    "value": ["BRANDNAME"]
  }
]

Three fields:

  • name — an identifier for the metadata slot (experience_brands). Allows the backend to route different kinds of matching logic by slot name.
  • type — the domain type of the value list (brand_code). Tells the backend how to interpret entries — e.g. treat brand_code values as brand-attribute matches on catalog entries.
  • value — the list of allowed / accepted values. Membership in this list (paired with the type's matching semantics) is what makes the Experience eligible.

Only brand_code is named in the post as an example type; the post's "Search backend will have different rules from the Product backend" framing makes clear other types exist for other surfaces (query text, filter value, entity id).

Evaluation semantics

The post does not specify the full evaluation algorithm, but the post's description of selection is consistent with:

  1. Domain backend observes request context (query text / active filters / entity id).
  2. For each Experience it knows about, it evaluates every selection_metadata entry against the context using the entry's type to decide what "match" means.
  3. An Experience with all (or any — unspecified) entries matching is eligible.
  4. If exactly one is eligible, it wins.
  5. If multiple are eligible, see concepts/fallback-experience.

Why declarative rather than code

Three reasons:

  • Safe for non-engineers to edit. New brand codes, new campaign windows, new market inclusions can be added by merchandising / partnership teams without a code deploy.
  • Backend-agnostic. The same shape describes rules whether Search evaluates them against query text or Catalog evaluates them against filters; only the type's matcher differs.
  • Auditable. An Experience's eligibility rules are inspectable as data, which is essential for selective-distribution-brand partnerships where "when does the elevated view activate?" is a contractual question with the brand.

Not disclosed

  • Whether all entries in selection_metadata must match (AND semantics) or any (OR semantics).
  • Whether the same type can appear multiple times.
  • The full list of supported types.
  • Whether selection metadata supports negation (not-this-brand).
  • How rules compose with brand-specific vs global merchant- level requirements — the post notes Zalando has "some which were global on the merchant level" (e.g. white packshot backgrounds for all products from one distribution brand) and others that are more narrowly scoped, but doesn't disclose whether they live in the same Experiences structure.

Seen in

Last updated · 550 distilled / 1,221 read