Content and commerce are data. Time to simplify.

Why separate commerce data from the product catalog?

The segmentation of catalog and editorial content is flawed convention carried forward by monoliths designed well before the modern composable approach. When you handle the product catalog with an ecommerce platform and enrich your catalog's contentwith a CMS, you need glue code that adds unnecessary complexity to your stack.

Why do it this way? There's a better path forward.

There are a number of reasons to separate commerce data from content:

• You need less glue code
  When you handle the product catalog with an ecommerce platform and enrich the catalog content with a CMS, you need to write and maintain glue code that adds unnecessary complexity to your stack.
• You get a single source of truth
  The CMS or PIM provides a single source of truth for all types of content. As a result, frontend development is easier and you can scale your architecture to support more channels without any data duplication.
• You can model more tailored catalogs
  In addition to providing content as an API, a headless CMS gives you the flexibility of designing data models with a tailored schema. The same way you can define editorial content models, you can also define categories, products, variants, and bundles with ease and keep them natively connected to the editorial entities.
• You simplify your content editors' life
  Spreading content across two different sources is also confusing for content editors. Editors need to know where each type of content is stored and log into different backend UIs to manage them.
• You achieve better performance
  Content can be cached more aggressively than commerce. If your catalog size is not too large, you can also think of statically generate category and product pages, building a "pure" Jamstack ecommerce website. Content also affects your site's SEO, so it is better to deliver it server-side. Instead, prices, stock, and buy buttons have less impact on SEO and can be injected on the client side.

Product titles, descriptions, and images are content and can be created directly in a tool like a CMS without any data synchronization requirements between your content and commerce platforms. This means that a product catalog can live within a content domain and not the commerce engine, which is all about prices, promotions, stock, payments, etc.

Any modern headless CMS will allow you to define a data model where you can specify a strongly-typed schema. In doing so, you unite your product and editorial content. We recommend reading more about this approach because it will further articular why a commerce engine should not manage product content.

Dive deep into strongly-typed product modeling.

Modelling product content with Commerce Layer.

Headless CMSs make it easy to create a product catalog with any type of attributes and taxonomies. It is more convenient and effective to use strongly-typed models (for example, "bags" instead of "products", "categories" instead of "taxonomies", etc.) when working with a specific brand. An example of the model and its relationships can be seen in the diagram below.

• Taxonomies within catalogs
• Taxons within taxonomies
• Products within taxons

All are sortable so they can be merchandised differently depending on the country. The country selector is populated by the country model. Selecting a country activates the current catalog. In order to create a new version of a catalog, you just need to create a new catalog object, define its merchandising, and connect it to the countries where it will be available.

Enhancing the catalog content is as easy as defining any other content model and linking it to products or taxons natively. Therefore, even if a PIM is added to your stack, it should only be used to clean data and organize a master catalog that can then be imported into a headless CMS.

Read more from our founder on how to model product catalogs.

Do you need a PIM?

The need of a PIM comes into play when you have to deal with large catalogs, low data quality, and complex worflows, all factors that must be considered separately. Therefore, it highly depends on your specific use case and organization. Reasons include things like the size of your product catalog, the variety and quality of the assets you plan to use to present your products, your team's workflow, and whether you want to create and manage an orchestration layer for your digital experience.

In general, you have these options:

• Use a headless CMS.

A CMS can serve as the application used to manage your product information. You can design a strongly typed schema that supports both editorial and product content, enabling you to create an immersive, content-led customer experience.If your catalog size is not too large, your approval workflow is simple, and your raw data quality is good, this is a great option for simplifying your stack and saving in terms of total cost of ownership.

• Connect your headless CMS to a PIM.

Using a PIM, you can organize your catalog and ensure product data consistency more easily by using features such as bulk editing, rule-based classification, reporting on data completeness, and others.

There are two ways to bring a PIM into your stack. The first method is to use the PIM as the source of product content for the headless CMS. The second option is to introduce an orchestration layer that aggregates editorial content from the headless CMS with product content from the PIM, and exposes a unified API to the frontend.

• Switch to a PXM instead of a PIM.

Product Experience Management (PXM) systems are an evolution of PIMs that emphasize customer experience within product catalog management. This solution simplifies the stack and can reduce total cost of ownership compared to the previous option, while offering all the tools you need to manage larger product sets. It is, however, a very catalog-led approach that may not be optimal for brands seeking to create immersive stories outside of the product page.

Read more from our founder about whether you need a PIM.

Indexing your product catalog.

In the ideal composable stack, there are three main components that handle different types of product information:

• an application to manage the catalog, like a PIM or headless CMS
• a commerce platform that provides prices and product availability
• a search engine

All product data, including product classification through different taxonomies, are contained in a master catalog, which is flattened as a list of documents during the indexing phase. It is crucial that the index documents reflect the variants, not the products. This allows customers to search and filter for attributes at the variant level, such as color, size, availability, or price. The results can then be grouped based on distinct products at query time, as described in this guide from Algolia.

By modeling your catalog and indices properly, you'll unlock great flexibility. Any attribute stored in the index will be available on the frontend as a filter. For example, a category code allows you to filter products by category or subcategory. You can then easily implement catalog navigation by attaching their codes to navigation items. By indexing online and in-store availability, you can show a product only if it's available or implement alternative shopping flows when an item is out of stock. By storing the price, you enable filtering or sorting based on price. Below is an example of an index document.

Learn more about how to build an index of your product catalog.