Pre-ingest: Assess catalog data

Prior to beginning the upload process into the SessionM Platform, examine the catalog to make a number of determinations that will enable the rest of the process:

Standard catalog structure

While the characteristics of catalog data is covered below in Disparate catalog vs. unified catalog, it’s important to ensure that the high level concepts of SessionM’s notion of a catalog are followed. The essentials of catalog structure within Catalog Management are composed of categories, items, and modifiers.

Category - A category is a parent of either items or subcategories. It is important to note that a category can house either categories or items, not both within the same category.

Item - An item lives within a category and is what is transmitted to SessionM in a transaction. For example, if a transaction contains a medium hamburger and small fries, these are both items.

Modifier (Optional) - A modifier adds an additional level of detail to an item and is most frequently used in the restaurant industry. For example, if a transaction contains a medium hamburger with pickles, the pickles would be a modifier. When uploaded in a catalog, the modifier is usually identified as such. When provided in a transaction, the modifier is both identified as such and indicates which item is being modified. It’s important to note while modifiers can be in catalogs (and subsequently transactions), the SessionM Platform does not take any actions with this data. Items and modifiers look identical within the platform and are only differentiated with a flag.

Any catalog uploaded to the SessionM Platform should abide by the category / item / modifier (optional) structure to ensure it is properly ingested and used within the applicable modules.

Disparate catalog vs. unified catalog

One of the most important factors that should be examined is whether a disparate catalog or unified catalog approach will be employed. Differences between the two are outlined below:

  • Disparate Catalog - In this default catalog type, the Item IDs that are assigned to catalog items and provided to SessionM within transactions (API or Flat File) differ on a per-store basis. This is most frequently used in the restaurant industry.
  • Unified Catalog - The Item IDs that are assigned to catalog items and provided to SessionM within transactions (API or Flat File) remain the same regardless of the store providing the information across the full scale of the system. This is most frequently used in the retail industry.

The type of catalog you are working with determines the catalog setup process. If you are working with a disparate catalog scenario, no action needs to be taken within the environment as this is the default configuration. If you are working with a unified catalog scenario, please notify your SessionM environment standup team during environment creation/setup as the configuration must be changed to ensure that the catalog is loaded and managed properly.

One reason why it is important to make this distinction revolves around catalog mapping. The Catalog Management Module includes features that enable you to map differences in a disparate catalog back to a single master catalog for ease of use across the platform. This feature also results in a significant additional number of steps during configuration and perpetual management. While mapping functionality will be discussed later in this guide, it’s important to note the different experiences that will be presented within the SMP UI based on the two catalog scenarios.

Assuming that there are two stores, let’s take a look inside the database to understand the differences between catalogs in these independent scenarios.

Disparate catalog explained

In order to get a better understanding of how disparate catalogs represent products in two stores, consider this catalog excerpt:

Compare the above excerpt to the catalog shown below:

We can see that in the disparate catalog scenario a similar item like “Steak Burger” has different Item IDs ("Item_4" vs. "Product_4") across the two different stores. This will result in the need to take a few extra steps within the SessionM Platform to ensure that because the items are the same but addressed differently, they are resolved into a singular item.

Unified catalog explained

In order to get a better understanding of how unified catalogs represent products in two stores, consider this catalog excerpt:

Compare the above excerpt to the catalog shown below:

In the unified catalog scenario, we can see that the “Steak Burger” possesses the same Item IDs across two different stores. If this is guaranteed to be the case with all items across all stores, only one single catalog is needed for upload into the platform.

Catalog data validation

Once the correct catalog approach has been chosen (unified or disparate), catalog data should be examined to ensure it is structured properly and does not contain characteristics that are incompatible with SessionM’s catalog management tools. A few things to keep in mind:

  • Category names should not duplicate at the same level. While the same category name can live as a child in separate categories, duplicate category names can not co-exist as children in the same parent category. If this is the case, the name of one category should be changed or the items should be combined within the same category.

    Example - Within the “Footwear” category, there should not be more than one “Shoes” category.

  • In a disparate atalog scenario, all items should have SKUs prior to upload and these SKUs should be the same for the same items across all store catalogs. This will simplify the mapping process.

    Example - Item within Store 1 could be "Large Fries," while in Store 2 it may be "Lg Fries." It should have the same SKU (148818) across all stores.

  • Items (and associated item IDs) are able to exist in the same store catalog twice, but not in the same category. The actual item is only represented by a single item within the database, but the UI would represent this as multiple copies of the same item within a hierarchy.

    Example - Blue Pants Size 12 (Item ID: 1234) can belong to both the "Pants" category and the New Releases category.

If catalog data needs to be adjusted based on the suggestions above, it is important to have the changes made at the source, prior to being ingested by the SessionM Platform.