Property definitions
A property definition is the schema for a single attribute — what it’s called, what kind of value it holds, and how it behaves. Every attribute on a product or variant traces back to one.identity
A machine-readable
key (unique within your organization) and a human-readable
name. Keys start with a letter and use letters, numbers, underscores, hyphens,
or spaces.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.
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 attributes 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 lowercase key (no spaces), an optional description, a sort position, and an active flag. A product type links to at most one category. 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 attributes 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.
Attribute standardization
Merchants and brands describe the same attribute in many ways — “blk”, “Black”, and “true black” all mean one color. When enrichment fills in an attribute, 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 attributes), 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.