Chapter 1

Prepare for Commerce wins

Building an enterprise commerce platform is an exciting but complex effort. If you are doing research to ensure the launch is successful right out of the gate to maximize your return on investment, then this article is for you. 

Improper catalog design can have lasting ramifications, such as difficulty rolling out new products, inefficient content management, and confusing shopping experiences. In this article, we will explore some practical data modeling techniques that you can apply to your project. You’ll also see an example of a draft design in action for a sample manufacturing catalog.

Chapter 2

Three examples of production challenges

When I am exposed to an existing commerce platform that is struggling, typically the first thing I look at is the catalog. To my surprise, I have witnessed many improper implementations supported by frustrated marketers and operations departments. Below are examples of three challenging scenarios (client information has been removed):

  1. Product Rollout Agility. In this scenario, a manufacturer acquired a similar business, but their products did not fit into the existing model. Furthermore, the existing products were difficult to merchandise because the fields were not separated. In the revised data model, the new product line fits cleanly into the existing taxonomy, and visitors can find products more easily through individual field filters.

  2. Separation of Duties. This client was struggling with data entry related to the merchandising of a product because Marketing was attempting to use a Product Information Management (PIM) system geared for specifications to handle romance copy (rich text and imagery). The image below demonstrates a catalog being sourced by two systems (romance copy in blue, specifications in green). Moving the romance copy to the content marketing tool allowed the team to focus on presenting the product with emotion, while operations focused on accurate specifications for technical enthusiasts. 

  3. Denormalized Presentation. In this example, the presentation has been bound to the catalog at the variant level of data, utilizing the same product image for each card. The result is three duplicate pictures and descriptions, yet there are different SKUs. Clicking into this product reveals that the different SKUs are actually different colors/finishes. The desired consumer experience would be to see one summary image of a product that meets their needs, and the ability to select the desired color after clicking into the product.

Chapter 3

Product catalog design play-by-play

Plotting out your catalog design is a tricky investment of time because you need to balance real examples without performing too much engineering. To deal with this challenge, I recommend three steps: model the data in a free-form tool like Excel, utilize a variety of real examples to represent the toughest use cases, and diagram the data on a PLP (product listing page/grid) and PDP (product detail page where you pick variant and add to cart) mockup so other team members can visualize it. The example below will show products modeled from the Lawn & Garden section of a commerce site.

This Excel template accomplishes the following:

  • Visualize the data model and real products in one picture.
  • Separates products from variants, demonstrating the configurability aspect.
  • Helps the developer understand how to configure the index, so there aren’t  matches on junk data. In this example, a shopper would never search for ‘Extra Blade’ because that is a nuance specific to that particular product, not the entire catalog.
  • Separates variant selection vs. display. This is particularly useful for manufacturers that have spec-heavy catalogs. For example, I need to select blade size, not SKU #, but the number may be important if I am familiar with the manufacturer’s numbering system.
  • Options available for facet are clearly mentioned, as not all fields are good candidates for faceting.

Ideally you have a mock of a PLP and PDP from the designer. The data points in the model above can be called out on the mock-up. Because I devised this from a real website, I can skip a step and show the result.

The image below demonstrates the mapping of product fields (in blue) and variant fields (in red) to the PLP. This allows the visitor to filter for products that meet their needs, regardless if the information is shown in the product grid or available in the next click, which would be the detail page.

This image shows how variants are represented on the PDP. An important key design construct is to have the data model inform the UI strategy when there are variant combinations that do not exist. For example, if I want the extra blade, I cannot get it in the 20” Corded model. Edge cases like this can create a lot of churn in the UI design and development cycle if not properly analyzed and communicated up-front.

When building a catalog like this, there is no telling what type of source you will encounter from project to project. Many organizations rely on an ERP (Enterprise Resource Planning) with a very flat and rigid model with several data-quality issues. It will be the job of the ETL (Extract Transform Load) to make sense of that model and put it into the one described above in the Excel image. Examples of typical ETL transformations are:

  • De-duplicating repeating variants or SKUs
  • Utilizing composite keys (multiple fields to determine uniqueness) when the ID system is not reliable
  • Set starting product price using the lowest variant price
  • Scrubbing variations of the same data so that facet selections are clean e.g. 14”, 14-inch, 14 in
  • Handling product updates versus discontinue & replace
  • Stamping inventory on a frequent interval, so that the commerce platform is not overburdened with inventory queries during visitor shopping
  • Verifying values that will be in a numeric index are in fact numeric, which is helpful for range facets such as 9 to 12 amps

Chapter 4

How does it map to Sitecore?

Sitecore Experience Commerce™ is a platform that can produce the above demonstrated experiences. It’s important to understand how the generic terms of product and variant map to the platform to improve communications across team members.

To save space and avoid duplication of data, products as described herein are referred to as a product family, and additional products are associated in order to represent the variants.

Chapter 5

Summary and takeaways

With the model cataloged properly, marketers enjoy merchandising features within the commerce platform’s standard toolsets:

  • Product grids show unique items
  • Products can be related to other products (up-sell and cross-sell)
  • Discount rules can be based off a variety of factors, such as if product weight is less than 100 lbs. then shipping is free
  • Recommend related products for visitors that fit in the DIY (do it yourself) persona, such as a leaf blower for someone shopping lawn mowers; if the persona is looking at ride mowers then perhaps the related product is a bag because this DIYer wants to limit physical activity

I hope the audience can use these examples to launch successful commerce platforms. This will also help the team emphasize the importance of empowering marketers and including those folks during the design sessions. It is important to evaluate the design through each lens (visitor/marketer/operations/customer service) before proceeding to the next step, so that your team can deliver memorable experiences through commerce.

Walt Rolle is a Sitecore Strategy MVP and leads the Digital Sales & Marketing practice for, helping his clients launch digital transformation that works through accurate technical guidance and a rock-solid management strategy. Connect with Walt at or @WaltRolle.