Last updated: Feb 09 2018

Area: Episerver Commerce Applies to versions: 10
Other versions:

Guidelines for working with catalogs

This topic provides important guidelines for working with catalog structures in Episerver Commerce.

Catalog design

The Episerver Commerce Catalog subsystem, architecture, and APIs provide great flexibility for designing and implementing catalogs. There is no single way to design a catalog. Organizations in the same business may create very different catalogs depending on what they are trying to accomplish and the choices they make. However, there are some central things to consider when designing catalogs.

Define a complete set of requirements

As with all systems, it is essential to define a complete set of requirements for what you are trying to accomplish with your catalog. When creating a catalog structure, consider the following important questions.

  • How will the catalog be managed? Will it be updated directly or by an external data source?
  • Which marketing, promotion, and merchandising requirements must the catalog support?
  • Does the catalog structure makes sense to your business team?
  • Are the catalog's fields and data structures as simple as possible?
  • Should you offload abstract data types (such as images and files) to the media management system (even though Episerver Commerce can store them)?
  • Are you using solid naming conventions when defining meta-classes and meta-fields?

Plan to support integration requirements

Nearly all e-commerce applications, for B2C and B2B, require integration across a variety of systems, and you should understand and plan for these. Not all e-commerce implementations require integration. But, in the rapidly changing world of e-commerce, data is increasingly being shared, not only with internally managed systems, but a variety of external providers. The following are examples of typical system integrations.

  • Marketing automation and email marketing
  • Retail merchandising
  • Enterprise Resource Planning (ERP)
  • Product Information Management (PIM)
  • Digital Access Management (DAM)

What data will you need?

Think carefully about the data you need. Migrating your product catalog to a new system may give you support for e-commerce and reporting features that you currently do not have. These features normally require data that is needed but non-existent in your current system. Plan the data you need to support your site, reporting, marketing, and merchandising and to ensure all requirements are met.

Understanding catalog components

Catalog entries

Catalog entries are the products, variants, bundles, and packages in the catalog. Custom types can be derived from all of these to map to different product types to store their respective characteristics. For example, a shoe could have fields for lining and sole materials, while a scarf would have only one field for material, and something completely different, like a wine, would have vintage and country of origin fields.

For each product type, there is often an SKU type, adding the characteristics that vary between product variants, such as a shoe variant with a size field, and a scarf variant with a color field.

Catalog categories

Catalog categories provide structure to your catalog content. While search is a vital part of an e-commerce site, many customers still want to browse a site as they would a physical store or print catalog. Display templates can use catalog categories to provide this experience.

 

Extracting data from a catalog for use in other systems

You can export the catalog as an XML file, and then write an XSLT template to transform the XML file to a printable version or format for other purposes. See MSDN for information about XSLT.

Structuring variants

As mentioned above, the best way to structure a catalog depends on the site. That is also true for variants that belong to the same product. Below are some general guidelines for all sites.

  • Do not have too many variants directly belonging to one product. For performance reasons, keep the number of variants in the hundreds, at most. System performance depends on how data is used, and if that number is exceeded, the risk of performance impact is high.
  • Having a couple of hundred variants for a product is not user friendly. From a usability perspective, you should have no more than 30. This only becomes an issue if the catalog is managed directly from the Episerver Commerce catalog UI, instead of through a third-party integration.
  • To reduce the number of variants per product, a product-product-variant hierarchy is usually a good pattern.

Comments