Catalog
What the Catalog domain tests
Catalog stores structured product or content data for personalization and recommendations. The exam tests collection design, item identity, data freshness, and safe use in templates.
Core rules
- Structure: a catalog contains collections; each collection contains items. Every item needs a stable unique identifier. Fields should have consistent types-strings for names, numbers for prices, booleans for availability.
- Relationships: items can reference other items or collections, enabling recommendations such as “products in the same category.” Keep references valid; a broken ID produces blank or wrong personalization.
- Data sources and sync: catalogs are populated by API, CSV upload, or integrations. Sync frequency determines freshness. Inventory, price, and availability change fastest and need the tightest refresh.
- Template use: templates pull catalog fields for dynamic blocks, recommendation rows, and conditional content. Always define a fallback for empty results or missing fields.
Worked example
An email shows three recommended products from the “Recommended” collection for the user’s top category. The template reads the collection, filters by category and in-stock=true, then renders name, price, and image. Reasoning: filtering on availability prevents promoting sold-out items; the category match keeps relevance; a fallback block shows bestsellers if fewer than three items qualify.
Traps
Stale catalogs advertise wrong prices or out-of-stock items. Missing or reused item IDs overwrite records. Treating catalog data as user profile data puts the wrong source in the wrong system. Omitting empty-result handling produces blank modules. Field type mismatches break filters and sorting.