Property definitions
A property definition is the schema for a single property — what it’s called, what kind of value it holds, and how it behaves. Every property on a product or variant traces back to one.identity
A machine-readable
key (unique within your organization) and a human-readable
name. Keys use letters, numbers, underscores, hyphens, or spaces, and must
contain at least one letter or number. A key does not have to start with a
letter — 10, 2xl, and 10-x are all valid. A key made only of separators
(-, ___, or a single space) is not. A numeric key is kept exactly as you
typed it: 007 stays 007 and is never folded to 7, because key cells in an
uploaded CSV are read as text rather than as numbers.value kind
The kind of value the property holds — including text, rich text, number,
boolean, enum (a fixed set of allowed values), date, URL, and string list.
The type governs how the value is entered, validated, and displayed.
product or variant
Whether the property lives at the product level (shared across all the
product’s variants, e.g. description) or the variant level (differs per
buyable version, e.g. size or color).
behavior flags
Whether a value must be present, whether it participates in search, and whether
it can be used as a storefront filter (facet).
grouping
An optional grouping label. For how properties are arranged into sections on the
product page, see Display groups & labels.
Dropdown value order
An enum property’s allowed values are offered in the order they were entered. On a list that grew over time — sizes added as they were stocked, colors as they launched — that order stops being useful to the person picking from it. Open the property in the Property Dictionary and set Dropdown value order:
Sorting is by the label you see, and it is number-aware, so “Size 2” comes
before “Size 10” rather than after it.
The setting applies to enum and localized-enum properties, and it governs
where you pick a value: the property’s dropdowns on edit forms and the value
control in variant Mass Update. It is separate from
Facet value sort, which orders the same values as a storefront filter — the
two are set independently and can differ. It does not reorder the value list in
the Property Dictionary itself, which is the editor that defines the “as
entered” order.
Product types
A product type is a template — a named set of property definitions that a class of products shares. “Running Shoe” and “Jacket” are product types; each links the property definitions its products should carry. A product references exactly one product type, and its properties are validated against that type.A product type links property definitions rather than redefining them, so the
same definition (say,
color) can be reused across many types. A type may also
override display placement for a property without changing the underlying
definition.Product type categories
A category groups product types that behave alike — for example a “Footwear” category over Running Shoe, Trail Shoe, and Sandal. Categories are yours to manage under Product Type Categories in the app: each has a display name, a key, an optional description, a sort position, and an active flag. A product type links to at most one category. Category keys are lowercase, carry no spaces, and use letters, numbers, hyphens, or underscores. A key made only of numbers —10 — is accepted. Case and
spacing are narrower here than for a property definition
key, which may contain uppercase letters and spaces.
Categories exist so you can configure enrichment once for a whole family of
product types instead of repeating yourself on each one. They are scoped to your
organization — there are no shared or built-in categories.
Enrichment configuration and overrides
Each property definition carries its own enrichment configuration: which strategies run for it, the custom prompt and context fields used to generate it, which model to use, the order it prefers its sources in, and whether enrichment may overwrite a value you entered. You edit all of it in one place. Open a property in the Property Dictionary and use the Enrichment Configuration section:Which of Generate, Standardize, Scrape & extract, or None run
for this property, in order. Generate is unavailable on enum-typed properties,
which are standardized rather than written.
The custom prompt used when generating this property, and the property keys
whose values are handed to the model as context. Context fields also decide
whether there is enough evidence to generate at all — see
Grounding thresholds.
An optional per-property model. The dropdown offers the models on your
organization’s approved list; leave it on Use default model to follow the
default configured for the prompt. Shown only when Generate or Standardize is
selected.
The order this property prefers its sources in, and whether enrichment may
replace a value you entered yourself. See
How enrichment works for what these mean when
sources disagree.
Free-text steering for the scrape and standardize strategies, and a character
cap on generated content.
Three tiers: product type, category, default
The Apply To selector at the top of that section decides where your edit lands. The same property can be configured three ways, and enrichment resolves them highest-wins:
So a
description that generates one way for footwear and another for one
specific jacket type needs a category override on Footwear and a product-type
override on that jacket type; everything else keeps the property’s own default.
The selector marks each scope Override or Inherited, and a scope with an
override offers Revert to Default to delete it and fall back to the tier
below. A product type with no category set simply skips tier 2.
Create them in order
Because each entity references the one before it, set them up in dependency order:1
Property definitions
Define the properties first — a product type can only link definitions that
already exist.
2
Product types
Create the templates that link those property definitions.
3
Products
Create products against a product type. A product can only reference a type
that already exists.
Property standardization
Merchants and brands describe the same property in many ways — “blk”, “Black”, and “true black” all mean one color. When enrichment fills in a property, it standardizes the value to your catalog’s canonical form so products stay consistent and filterable. You control how strict this is per property definition:- Exact-match-only — for properties where a near miss is unacceptable (typically numeric or size-critical properties), matching must be exact rather than approximate.
- Allow new values — when enabled, enrichment may create a new standardized value if none of the existing ones fit; when disabled, it only ever picks from values already in your catalog.
- Matching guidance — free-text instructions that steer how a specific property is matched.
- Source priority — the order this property prefers its sources in when more than one produced a value.
- Overwrite merchant input — whether enrichment may replace a value you entered yourself. Off for most properties; on for a few content fields.
Standardization is applied at the property level as part of enrichment. It reuses
your existing values wherever possible so the same concept isn’t recorded two
ways.
Products & variants
What products and variants hold and how they relate.
Display groups & labels
Organize properties into sections and tag product versions.