Work with catalogs

Catalog design

The Optimizely Commerce Connect 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 Commerce Connect can store them)?
• Are you using solid naming conventions when defining meta-classes and meta-fields?

Plan to support integration requirements

Nearly all ecommerce applications for Commerce Connect and Configured Commerce require integration across various systems, and you should understand 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 Asset 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 ecommerce 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.

Understand catalog components

Catalog entries

Catalog entries are the catalog's products, variants, bundles, and packages. 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 ecommerce 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.

Extract 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 MSDNfor information about XSLT.

Structure variants

As mentioned above, the best way to structure a catalog depends on the site. The same is true for variants belonging 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 Optimizely Commerce Connect catalog UI instead of through a third-party integration.
• A product-product-variant hierarchy is usually a good pattern to reduce the number of variants per product.