In 2022 we developed a unique partner experience that speaks to dedicated requirements from selective distribution brands and retailers around visual representation, brand storytelling and protecting brand equity. Our solution provides dedicated brand exposure across the experience and at the same time respects special requirements to secure brand equity. In order to achieve consistency with other articles, a general context-aware mechanism needed to be implemented.

We derived a plan to create distinction and elevation in the experience. 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. 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.

To date, the Fashion Store was based solely on domain-specific data. These new rules, defined on customer intent and context, introduced new challenges in Zalando, and required a new solution. For instance, the same product can behave differently depending on that context. 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.

In order to achieve this we needed to identify what we should apply for each use case, meaning what are the brand's requirements, and when they should be applied - which rules should be checked in order to understand the customer's context or intent.

Brand requirements can be a complicated matter. We identified some which were global on the merchant level; for instance, let's say one of the distribution brands are required to have different packshot images, with white backgrounds, whilst we typically use gray backgrounds in Zalando. Other requirements are brand-specific. Some brands are only to be shown in the product catalog when the brand or its products are explicitly requested to be shown by specific search queries or via catalog filters.

In order to support different kinds of requirements, we use the concept of experiences. Experiences are simply a collection of policies that we need to apply, and a list of selection rules.

For example, a policy may be the theme configuration that needs to be applied, or whether we are allowed to show the product under certain conditions. The selection rules define the criteria that enable the experience, e.g. selection by brand codes. This means that selecting a specific brand in the brand filter will change the experience to the one that has been configured for that brand.

{
  "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"]
    }
  ]
}

Selection rules can be another complicated matter. For instance, how to decide which experience to choose when two brands belong to different experiences? Thinking about the right use cases to support the business needs, whilst keeping simplicity is the key. Our approach to solving some cases is to define Fallback experiences, to be able to catch these use-cases.

As mentioned in other posts here in Zalando Engineering Blog, Zalando has many microservices, and even our Frontend’s architecture is based on micro frontends. We defined the general data structure to understand the experience, but how can we orchestrate it across Zalando's ecosystem?

In order to get into that, we need to break down the flow into two steps. The first one is the Experience Resolution step. This starts very early during the root entity resolution.

Let's say that a customer browses a catalog page. This will send a request to Rendering Engine, which will resolve the root entity by sending a request to the Fashion Store API (GraphQL), which will then query the Catalog backend system. The catalog has its own business logic to understand the customer’s intent and it will find the best matching experience, using its selection_metadata.

The resolved experience name is then stored in the Rendering Engine request state.

At this point we have only resolved the root entity. We don’t yet know which renderers (micro-frontends) are required. During this process, we start the second step, where each one of them will query Fashion store API independently, only this time the query will use the previously resolved experience. In the catalog, we have product cards, whose data is populated by a different backend, the Product backend. As we have already resolved the experience, the Product backend can now understand which policies are required. For Zalando’s experience it will select the gray background images with the watermark, instead of the white ones.

Using this new mechanism, we successfully managed to introduce new concepts to Zalando. It has opened a door for so many new possibilities that we can leverage to further enhance the customer experience.

We're hiring! If you're passionate about similar challenges, join one of our Frontend teams!