Marketing Cloud Personalization Catalog: Five Modeling Decisions

The catalog in Marketing Cloud Personalization (the product formerly known as Interaction Studio and Evergage) is the foundation every recipe, every segment, and every campaign reads from. It is also the part of the implementation most teams give the least thought to during scoping. The first modeling decisions get made in the kickoff week and quietly shape what the platform can do for the next two years.

Five decisions worth slowing down on.

1. Item types: subclass or attribute

Every catalog item belongs to an item type. Product is the default. Real implementations need more.

The trap is treating taxonomy as a single flat field. A retailer launches with one Product item type and a category string attribute. Six months later the marketing team wants to recommend "more from this brand," "more in this collection," and "items from the same designer." None of those work cleanly because category is a flat string, not a thing the platform can recognize as a related entity.

The fix is to model first-class item types for anything the business will want to navigate to or recommend on. Common first-class types beyond Product:

• Category for taxonomy nodes
• Brand for manufacturer or own-label
• Article for content commerce or magazine sites
• Store for retailers with locations

Item attributes are the right tool for properties that describe an item but never become a recommendation target on their own. Color, size, price, in-stock flag, shipping class. If marketing will never say "show items where attribute X equals Y" in a campaign brief, it is an attribute.

A reliable test: if the team will ever want a landing experience for that value (a Brand page, a Category page), it is its own item type.

2. Related catalogs: the join model

Once item types exist, related catalogs define how they connect. A Product belongs to one or more Categories. An Article is tagged with one or more Topics. A Recipe uses several Ingredients.

Two patterns work:

• Many-to-one for canonical hierarchies. Product to Category. The product carries a single category reference.
• Many-to-many for tags or facets. Article to Topic. Stored as a list of references.

The instinct that breaks implementations is denormalizing relationships into attributes. Storing category_name as a string on Product looks faster but breaks every recipe that should "recommend other items in the same category." The relationship has to be a relationship, not a string match.

Two practical rules:

• Set up related catalogs before importing real data. Schema migrations on a populated catalog are painful.
• Confirm the bi-directional view. From a Product page, can the platform find sibling products via Category? From a Category page, can it list members? If either query fails, the relationship is wired wrong.

3. Multiple catalogs: when, and why usually not

Multi-catalog is supported. Most teams who turn it on regret it.

The legitimate cases are narrow. Genuinely separate businesses with no shared visitors, customers, or taxonomy. A holding company running an electronics retailer and a furniture retailer with separate domains and separate teams. The catalogs share nothing. Recommendations should never cross.

The illegitimate cases look tempting but cause damage:

• Same business, multiple regional sites. Use one catalog with a region attribute. Visitors travel across regions. Affinities should follow them.
• Same business, B2C and B2B. Use one catalog with a customer_type filter on recipes. Cross-channel learning still helps.
• Same business, multiple brands under one parent. Use one catalog with a Brand item type. Customers shop across brands.

The cost of multi-catalog is invisible at first. Einstein affinity is per-catalog. Recipes are per-catalog. Segments target one catalog. A visitor who browses both catalogs is two profiles. Six months in, the team realizes recommendations are weak in both catalogs because no single catalog has the data density to learn from.

Default to one catalog. Add a second only when there is zero overlap between the audiences and zero scenario where one would inform the other.

4. Item ID stability: the rule that breaks everything else

The single hardest rule of the catalog is that item IDs must be stable forever. Once an item enters the catalog with ID SKU-12345, that ID can never change for that item.

Item IDs are the join key for every behavioral signal. View events, purchase events, cart events, all reference the item by ID. Affinity profiles, recipe training, recommendation logic, all key off the same ID. Change the ID, and the platform sees the item as new. The accumulated affinity from every visitor who ever interacted with it is silently disconnected.

Common ways teams accidentally invalidate IDs:

• Re-platforming the e-commerce site. The new platform regenerates SKUs. Catalog import overwrites old IDs with new ones.
• Shopify-style variant restructuring. Splitting one master SKU into per-color child SKUs. Each child becomes a new item, the master disappears, history is lost.
• Localization. Generating per-locale IDs (SKU-12345-EN, SKU-12345-DE). Now the platform sees ten variants of one product instead of one product visible in ten locales.

The cure is upstream discipline. Whatever generates the ID should be the most stable system in the stack. Master SKU from the PIM, never the e-commerce platform's auto-generated ID. If a re-platform is unavoidable, plan a catalog ID migration in parallel and test on staging for a full reporting cycle.

5. Feed versus API: pick one and own idempotency

Catalog data flows in via batch feed (CSV or JSON) on a schedule, or via real-time API push, or both. "Both" is where bugs live.

A typical pattern that fails: the e-commerce platform pushes to MCP via API on every product update, and a nightly catalog feed runs as a backstop. The feed wins last write, the API wins the moments before. Stock status flickers. Price flickers. Recommendation quality stays bad for a week before someone notices.

The discipline is single-source-of-truth per attribute. Pricing comes from one system, only. Inventory from one system, only. Whichever pipeline owns an attribute, the other ignores it.

For the pipeline itself, idempotency matters more than speed. The same feed run twice should produce the same end state. Real production catalogs run feeds on retry, on outage recovery, on manual reprocess. Anything that drifts on retry will drift in production.

A practical sequence for new implementations

The order that avoids rework:

1. List every recommendation experience and segment the business will want in the first year. Read backward to the item types and relationships needed to power them.
2. Define item types and related catalogs in MCP Admin before the first import.
3. Lock the source of truth for item IDs in the upstream system. Document it, do not just decide it.
4. Run a feed end-to-end on a staging catalog. Verify ID stability across two consecutive imports.
5. Enable behavioral tracking and live recommendations only after the catalog is confirmed stable.

Catalog modeling is one of the few parts of MCP where the cost of getting it wrong compounds across years. The cost of getting it right is one extra week of design before go-live. Sapota's Salesforce team treats it as the longest-effort phase of every Personalization engagement, regardless of how simple the brief looks.

---

Implementing or auditing a Marketing Cloud Personalization catalog? Sapota's Salesforce team handles catalog design, sitemap implementation, and Einstein recipe configuration on production engagements. Get in touch ->

See our full platform services for the stack we cover.