The catalog data model

The catalog is built from a small set of pieces. Learn what each one is for and the rest of this area falls into place. Skip it and you will end up modelling everything as free-text attributes and regretting it around article 2,000.

Take a hydraulic screw fitting, article 4711-A. It has a thread size, a material and a pressure rating. It comes in three lengths. It sits in the "Screw fittings" category, it is made by one manufacturer, it has a photo and a datasheet, and it needs four of a certain seal as a spare part. Every one of those sentences is a different piece of the model.

The pieces

How they fit together

Attribute group ──contains──▶ Attribute
                                  │
                                  │ assigned to (required? per channel?)
                                  ▼
                              Family ──has──▶ Family variant ──defines──▶ axes
                                  │                                        │
                                  │ assigned to                            │
                                  ▼                                        ▼
                              Product ◀──varies along──────────────── Variant products
                               │  │  │
              ┌────────────────┘  │  └────────────────┐
              ▼                   ▼                   ▼
          Category           Reference entity       Asset
       (where it's found)   (shared records)     (managed media)

Read it as one sentence: an attribute is a field, a family says which fields a kind of product must have, a product is an instance of a family, and categories, reference entities and assets are the things a product points at.

Attributes: the atoms

An attribute is one field. It has a type (text, number, boolean, date, single-select, multi-select, price, measurement, asset, reference), and that type is the single most consequential choice you make.

Two flags matter more than any other and are covered in Channels, locales and completeness:

• Localizable: the value differs per language.
• Scopable: the value differs per channel (your shop vs. a punchout catalog).

Two more decide whether the attribute is useful for finding things:

• Filterable: a buyer can narrow by it.
• Usable in grid: you can see it in the product list while editing.

Families: the contract

A family is the contract for a kind of product: these attributes apply, these are required, and required for which channels.

Families are why a 200,000-article catalog stays manageable. You do not decide per product which fields it needs. You decide per family, once, and every product in it inherits the rule. A family also names which attribute is the product's label and which is its main image.

Keep families at the granularity where the attribute set differs. "Hydraulic fitting" and "Pneumatic fitting" are separate families if they need different technical fields; they are one family with a medium attribute if they do not. Ten to fifty families is normal. Several hundred usually means somebody modelled categories as families.

Variants: one article, many sizes

A safety glove in five sizes and three colours is not fifteen unrelated products. It is one product model that varies along two axes.

A family variant defines those axes. The shared information (description, manufacturer, certificate, marketing copy) lives once on the model. Only what differs per combination lives on the variant, which is typically the SKU, the barcode, and the size-specific dimensions.

Get this right and updating the description of that glove is one edit. Get it wrong and it is fifteen, of which you will do eleven.

Categories: where buyers browse

Categories are the navigation tree. A product can sit in several. Two things to know early:

• Categories are not the same as families. A family is about which fields a product has; a category is about where a buyer finds it. "Screw fittings" is a category; "Hydraulic fitting" is a family. They often look similar at the top and diverge fast.
• Categories can be rule-based: defined by a condition on attribute values rather than a manual assignment, so they fill and re-fill themselves as products change. Useful for things like "Stainless steel" or "In stock now".

Reference entities: shared records

When many products point at the same thing (a manufacturer, a material, a norm, a certificate) that thing deserves to be a record, not a repeated string.

A reference entity is that record type, and it can have its own attributes. A manufacturer gets a logo, a website, a description. Change it once and every product referring to it is updated. This is also what lets you build a manufacturer landing page without scraping product text.

Assets: managed media

An asset is a media file with structure around it: which asset family it belongs to, what its code is, and its own attributes. Asset families can carry a naming convention, so 4711_A_front.jpg can be recognised and filed automatically rather than attached by hand.

The practical difference from "upload an image to a product": one datasheet covering forty articles is stored once and referenced forty times, and replacing it updates all forty.

Measurements

A measurement family defines a standard unit and the units convertible to it: length in mm, cm, m, inch. Storing "10" and "mm" as two loose fields is how conversion bugs are born. Storing a measurement means the platform knows what the number means, can convert it, and can display it per market.

Associations

Association types express product-to-product relationships: accessory, spare part, replacement, cross-sell. They can be two-way (if A is an alternative to B, B is an alternative to A) and quantified (this assembly needs four of those screws). Quantified associations are what make spare-part lists and assembly kits work.

How this works in the Revenue Cloud

Every piece above is a screen under PIM in the Commerce Studio. The day-to-day objects have their own entries; the structure lives under Data model.

Three details the tables above do not show:

• A product has a Kind: Simple, Model or Variant. A model carries the shared values; a variant carries its own and points at its model under Parent (model). Two levels at most.
• A product's values are stored per attribute, and an attribute's Localizable and Scopable flags decide how many values it holds. The same attribute engine serves products, reference entity records, assets and categories; the Entity type on the attribute says which.
• Codes are permanent. Labels can be renamed in every language at any time; a code is what imports, exports and integrations use to address the object.

Next

• Channels, locales and completeness — the flags that decide how many values a field really has.
• Plan your data model — turn this into decisions for your catalog.