Product Data
Modelling the product record: attributes, variants, SKUs, taxonomy, localisation and the metadata that travels with an image. Product data is where DAM and PIM projects succeed or quietly fail, because a schema nobody can enforce becomes a schema nobody fills in. These posts cover the modelling decisions that are expensive to reverse.
-
Single source of truth, applied to product data
Everyone agrees on single source of truth in the abstract and nobody agrees on it per field. The phrase only becomes useful when it is written down as a list of fields with one owner each, and a rule about what everyone else is allowed to hold.
-
Syndicating product data to marketplaces
Every channel wants the same product described differently, and each one enforces its own rules asynchronously, three days after you sent the file. The fix is to hold the union of their requirements and validate before you publish, not after.
-
Attributes, variants and the SKU problem
A product with six colours and five sizes is thirty things to sell and one thing to describe. Confusing those two numbers is the single most common cause of a catalogue that cannot be maintained, and it happens in the first month.
-
The product data model that survives growth
Most catalogue rebuilds are not caused by the platform. They are caused by a data model that could not represent a variant, a market or a unit, and had to be flattened into free text to keep going. Here are the decisions that are expensive to reverse.