CONCEPT Cited by 1 source
Customer-intent-driven experience selection¶
Definition¶
The principle that a request-scoped Experience (see concepts/experience-zalando-if) is selected from explicit customer intent — what the customer asked for, where they entered the funnel — rather than from attributes of the product they happen to be looking at. Zalando's own phrasing: "The criteria for enabling an experience are based on explicit customer intent. For instance, searching for the retailer name or one of its brands will enable the elevated experience. Viewing their product details page will also enable it" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).
Contrast with product-driven selection: if the Experience were chosen from the product's brand attribute, the same brand's products would always render in the elevated style — even when a customer is doing generic catalog browsing and seeing many brands side by side. That breaks cross-brand visual consistency at the browse level.
The intent signals¶
The post names three per-backend rule families, each owned by the backend closest to the request:
| Backend | Intent signal |
|---|---|
| Search backend | Query text — e.g. searching for the retailer name or one of its brands |
| Catalog backend | Active filters — e.g. a brand filter applied |
| Product backend | Entity identity — e.g. viewing the brand's product details page |
Zalando's direct quote: "These intentions are identified by our backend systems with specific business domain rules, i.e. the Search backend will have different rules from the Product backend" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).
Why per-backend, not centralised¶
The rules for recognising intent differ so much between surfaces (text-matching for search, set-membership for filters, id-equality for PDP) that a central rule engine would either become a lowest-common-denominator type system or a grab-bag of backend- specific cases. Keeping rules in the backend that already owns the request context — same code that already parses the query / filters / entity — means intent recognition is one more local predicate rather than a cross-service abstraction.
The architectural cost: rules are distributed. The benefit: each backend evolves its rules without cross-team coordination, and the shared contract (emit the resolved Experience name) is thin.
Why this matters for consistency¶
Zalando's worked example: "while viewing the catalog without any intent for a brand distinctive experience, for the sake of consistency, all products, including ones belonging to other distribution brands have a gray background, even though the brand elevated experience may dictate, for example, a white background" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).
The explicit consistency goal — every product looks the same in a mixed catalog view — is only reachable if Experience selection ignores product identity. Customer intent is the only signal that cleanly produces this behaviour: browsing mixed catalogs without brand intent → default experience → uniform styling for all products regardless of brand.
Feeds into¶
- concepts/selection-metadata — the declarative predicate a backend evaluates to match an Experience to observed intent.
- concepts/root-entity-experience-resolution — the timing of selection (once, at root-entity time, by the domain backend owning the entry point).
- patterns/request-state-propagated-experience — what happens after selection: the resolved Experience flows to child Renderers via the Rendering Engine request state.
Seen in¶
- sources/2023-06-25-zalando-context-based-experience-in-zalando — the canonical statement of the customer-intent-over-product- attribute selection principle; worked example of the grey-vs- white packshot split hinging on how the customer entered the page.