At Zalando, serving engaging content across the user journey has become increasingly important for multiple teams within the company. This required a scalable, feature-rich and easy-to-use solution, that was flexible enough to adapt to the ever-changing requirements for rich content.

In this post, George and Daniel describe the product that was built to serve this purpose - its problem space, the solution design process, the technological context and how the product evolved to include new use-cases, such as the Zalando Sustainability topic.

Problem Space: The need for a flexible content solution

The Zalando Fashion Store is first and foremost a platform to help our customers find the products they want, and it employs various strategies to personalise the experience for each customer. Zalando also aims to inform and inspire, and many of our internal teams and brand partners sought to do this by telling stories, via editorial content.

This is where "editorial landing pages" come in as static, self-contained web pages on the Zalando site containing a range of content. Landing pages are often tied in to products and brands, but not always with conversion as the primary focus. They include awareness campaigns from key brands, inspiration for a clothing category like outdoor, or informative pages for key Zalando initiatives like Pre-owned, or sustainability in fashion.

When George's team first started working on the topic of landing pages for Zalando Marketing Services (ZMS) campaigns, there was a legacy tooling for the creation & management of such pages already in place. However, it had many limitations affecting scalability. Also, it was based on Zalando's "Mosaic" system architecture, which was being phased out in favour of the newer Interface Framework. So the team decided to build a new tool to replace the old, overcome the feature and scalability related shortcomings, on top of this new architecture.

Core Requirements

The shortcomings and pain-points of the previous tool became the basis of the requirements for what the team would build:

• Ease of Use / Scalability - The previous solution required significant engineering effort to set up each page, before Content Managers could upload the content. This was ineffecient and a clear bottleneck to scalability. Therefore, the new tool should allow Content Managers to create pages, upload and publish content with no engineering involvement.
• Content Flexibility - With the previous tooling, once a page was set up, the layout could not be changed without resetting it, which would cause any content uploaded to be lost, creating a lot of repeated work. The new tool should allow the flexibility to change the layout, add and remove content, whilst preserving existing content.
• Parity with the Zalando App - In the previous tooling, web and Zalando app pages were entirely separate - they had different content formats that looked quite different with content for each being uploaded separately. This created a lot of duplicate work, both in asset creation and upload. The new tooling should allow for a single source of content, and mirror its appearance across web & app.
• Localisation - Zalando operates in 25 different markets, requiring content for a given page to be localized into several languages. The previous process for this was cumbersome and confusing, effectively repeating the content-upload for each language. Our goal was to streamline this into an efficient, user-friendly process.
• Extensibility - Creating new, engaging experiences was a key part of the ZMS use case, so we wanted a setup that would facilitate the development of new content formats. After the initial rollout, other teams also showed an interest in this capability, so creating a streamlined contribution model became a priority.
• Interface Framework - To integrate the tool with Zalando's new architecture and design system, to leverage its capabilities and scale with it.

Solution Design

The first decision to make was whether to build a new CMS from scratch, or use an existing, third-party solution. We needed something flexible enough to adapt to our precise requirements, but we were also conscious that trying to reinvent the wheel by building our own CMS could grow into a project with limitless scope that we would never finish.

After researching many third-party CMS solutions we decided to go with Contentful, a headless CMS - 'headless' since it is agnostic about the 'how' of presenting content to the end user. Instead, it focuses on making the content management process as easy and intuitive as possible. The content is delivered via an API to the presentational layer, e.g. directly to an app, a static site generator such as next.js or any user consumer channel, such as Zalando's micro-service-based architecture in our case. What won us over was how flexible and scalable it is in terms of what content could be served, as well as the ease with which the CMS UI could be extended with custom apps. It also had strong multi-language support out of the box, and enabled collaboration in bigger teams.

System Architecture Context

Let's have a closer look at the technology context into which our solution needed to fit and how a request to a landing page would be processed, finding its way from the content consumer all the way to Contentful:

• There are two main consumer platforms: web and app. Our Skipper routing service takes care of matching the request URL with the correct internal service endpoints and HTTP header enrichment:

• Both platforms are serving a requested landing page via our Rendering Engine, which fetches data for each UI element via a GraphQL query using our GraphQL aggregator, the Fashion Store API (FSA).

• To enable data fetching for our landing pages, George's team built a data proxy service. This sits between FSA and Contentful's API, and handles content mapping & caching. This approach also ensures resilience and that the aggregation layer calls directly only Zalando-operated APIs.
• To integrate additional content from Zalando services into the Contentful CMS, a simple content aggregator was built.

Content Data Model

The actual content of a landing page is managed within Contentful as "entries"; each entry-type having its own data schema definition, validation rules and a content-upload UI for the content editors.

The main entry is the landing page itself. It has basic fields like the page title, the URL path and SEO related metadata. It also has a reference list to sub-entries or "modules" - preset content formats such as banners, text blocks, a product carousels etc, or more bespoke formats such as list of sustainability certifications with background information. These can be composed using a drag-and-drop UI to build a landing page layout, and then the necessary content can be uploaded for each one. They can be rearranged/edited at any time, without then need to re-upload existing content.

When a landing page request reaches FSA, it in turn calls the Contentful proxy service, which returns the data for the page and each of its modules. These are map to corresponding 'renderers' in the Rendering Engine, which render the UI components.

A sustainable solution: extensibility and contributions from other teams

The Sustainability Team was one of the first interested parties to reach out to George's team early on in the implementation phase. They were seeking a way to display information on the various aspects of Sustainability in fashion in an engaging way. Although this content typically exists more permanently than the short-lived marketing campaigns for which the landing pages system was primarily intended, the overlap of the problem space and requirements was significant enough to make for a beneficial collaboration.

Extension and adaptions were needed however, both regarding orthogonal aspects (like SEO support or a content review and approval workflow) as well as for specific presentational features. In particular, the addition of the latter in form of self-contained new modules demonstrated that the new system is flexible enough to enable contribution from other teams. Among the additional modules added by the Sustainability team was one showing details of the sustainability certificates Zalando supports on the product level.

Let's use this module to make the stack as described in the previous section a bit more tangible.

The Sustainability Certificate module

The purpose of the certificate module is to present a list of sustainability related certificates to our customers. A sustainability certificate acts as the proof for sustainability related claims about a product. They can be either a 3rd party certificate like Fairtrade or GOTS or one of the criteria Zalando provides, e.g. 'Made with 70-100% recycled materials'. On a landing page, each certificate needs to be shown with three content pieces:

• logo
• title
• description text

Additionally, the whole certificate module has two headlines and an introduction text block.

One interesting aspect of the module is that it gets its content not solely from Contentful, but partially from another Zalando service already delivering data for another customer touch point: the Sustainability accordion of the Product Detail Page.

Using a single source for sustainability information is valuable not only for making the life of our Content Editors easier (especially when considering the number of supported languages), but also because it's important to show accurate and up-to-date information about Sustainability claims across the whole customer journey.

For that reason, the Contentful data model of the module looks like this:

• Title
• Subtitle
• Overall intro description text block
• list of certificate IDs (the list and order of certificates to show can vary from landing page to landing page)

These fields are delivered via the Contentful proxy to the Fashion Store API (FSA) where the certificate IDs are enriched with the values for the logo url, title, and description in the same way as is done for requests from the Product Detail Page. The certificates are delivered to the clients by FSA in the field entities which is part of the Collection type in the GraphQL schema.

This ensures that the certificate detail information on Landing Pages and on the Product Detail Pages are always in sync.

query:

query collection_certificates($id: ID!, $first: Int!)
@component(name: "re-collection_certificates") {
  collection(id: $id) {
    id
    title
    subtitle
    description
    entities(first: $first) {
      certificates: nodes {
        __typename
        ... on SustainabilityCertificate {
          id
          title
          description
          logo {
            uri
          }
        }
      }
    }
  }
}

response:

{
  "data": {
    "collection": {
      "id": "ern:collection:fwd:component:xyz",
      "title": "Background check",
      "subtitle": "Sustainability criteria you can trust",
      "description": "Look for certificates like these to see...",
      "entities": {
        "certificates": [
          {
            "__typename": "SustainabilityCertificate",
            "id": "ern:sustcertificate::xyz",
            "title": "GOTS - organic",
            "description": "The Global Organic Textile Standard (GOTS) is...",
            "logo": {
              "uri": "[...]/sustainability/logos/gots-2.png"
            }
          },
          ...
      }
    }
  }
}

When implementing this module, we had to touch the following components of the Landing Page stack:

• Contentful, to add the new data model
• Contentful proxy, to map the new Contentful model to the Collection type of the GraphQL schema in the Fashion Store API
• UI components for app and web platforms

Overall, the implementation of the additional modules by the Sustainability team was a successful example of inner sourcing.

Impact of the Content Management Tool

Once the new tool was rolled out, it had a substantial impact on the efficiency of landing page content management:

• The average landing page time-to-go-live, from page creation, content upload to publish, was reduced from 2 days to 4 hours.
• In the previous set-up, we had to impose a 2-week lead time from page briefing to go-live, to allow for content upload issues & QA etc. With the new solution, this lead time has been removed entirely.
• The new tool requires no engineering involvement in the creation & publishing of landing pages - non-technical stakeholders can complete the process end-to-end themselves.
• The same was also true for changes to the layout of existing landing pages. Previously requiring engineering involvement, and re-upload of all the content again, now this can be achieved by simply reordering the modules, or adding/removing new ones as needed.
• The landing pages and all modules on them are mirrored across web and app, from a single point of upload, rather than two distinct pages, cutting the briefing and upload workload in half.
• Since rollout, we've seen an 82% increase in the number of landing pages published YoY.

Conclusion and Next Steps

In conclusion, if we assess the impact of the new tool against the original requirements, we think it’s fair to call the project a success. We implemented a tool that allows non-technical stakeholders to create and manage landing pages end-to-end, with greatly reduced effort, and that takes advantage of Zalando’s new Interface Framework.

Perhaps the most promising achievement is that one of the key aims of the tooling was to facilitate the addition of new features and iterations to continuously improve the landing pages offering. We feel this was achieved, as since the rollout many such features have been added, such as new content formats like the aforementioned Sustainability Certificates module, or process improvements like an adaptive streaming video solution which allows us to deliver longer video content with seamless playback, or image editing capabilities within the CMS to streamline content upload.

The ability to add these improvements gives us confidence that the tooling will remain adaptable enough to serve our ever-changing needs in the long term.

We're hiring! Do you like working in an ever evolving organization such as Zalando? Consider joining our teams as a Frontend Engineer!