MCP Einstein Recipes: A Selection Guide for Production Personalization

Marketing Cloud Personalization ships with around a dozen Einstein recipes out of the box. The product picker makes them all look interchangeable. They are not. Picking the right recipe for a placement is most of what determines whether the recommendations on the page feel relevant or feel random.

Most of the recipes fall into five families. Knowing the family is enough to pick well in 90 percent of cases.

1. Behavioral recall: Recently Viewed and Recently Abandoned

These two recipes show items the visitor has already engaged with. Recently Viewed surfaces products the visitor opened in the current or recent sessions. Recently Abandoned focuses on items added to cart or wishlist but never purchased.

Neither requires affinity training. They work from session one. The downside is that they are pure recall: the visitor sees what they have already seen.

The right placements are persistent strips that sit across the site. A "Continue browsing" rail near the top of the home page. A "Don't forget about these" block on the cart page. They reinforce intent without trying to expand the visitor's interest.

Wrong placement: a category landing page where the visitor expects discovery, not recall. Showing the same items the visitor just saw on the previous page makes the category strip feel broken.

2. Similarity: Similar Items, Frequently Bought Together, View Also Viewed

These recipes anchor on the item the visitor is currently looking at and recommend items that relate to it. Similar Items uses content-based similarity (attributes, descriptions, embedded representation). Frequently Bought Together uses purchase co-occurrence. View Also Viewed uses behavioral co-occurrence at the view level.

Place these on item-detail pages. They are the canonical "people who looked at this also looked at" rail. The choice between the three depends on conversion goals and traffic volume.

• Similar Items works on small catalogs and from day one because it does not need behavioral data.
• Frequently Bought Together needs purchase volume to learn from. On low-traffic catalogs (under 1000 daily transactions), it falls back to similarity-style recommendations or shows weak signals.
• View Also Viewed sits between the two and works at moderate traffic levels.

The mistake teams make on item-detail pages is using a behavioral recipe before there is enough behavior to support it. The cold-start fallback shows generic items and the strip looks weak. Default to Similar Items until the catalog has six months of meaningful traffic.

3. Trending and bestsellers: Trending, Bestsellers

Bestsellers ranks items by raw purchase volume over a window. Trending ranks by recent acceleration in views or purchases (a moving derivative).

These work without personalization. They are population-level recommendations, the right answer when the visitor is anonymous, brand new, or otherwise without affinity signals. Use them on home page strips for cold-start visitors and on category pages where there is no item-level anchor.

The trap is using these as the default recipe everywhere. The visitor with a clear affinity profile gets the same recommendations as a first-time visitor. The personalization system effectively turns off. Bestsellers belongs in the recipe sequence (covered below), not as the standalone choice for a personalization placement.

4. Affinity-driven: Sort by Affinity, Personalized

These recipes consume the visitor's affinity profile and rank items accordingly. Sort by Affinity takes a candidate set (often a category page) and reorders the items to push high-affinity matches to the top. Personalized works as a recipe for any placement and combines affinity with other signals.

Use these on category pages, search results, and any list view where the visitor has had enough sessions to develop an affinity profile. Combined with sufficient catalog data, these are the recipes that produce the meaningful lift case studies cite.

The constraint is that affinity needs sessions to develop. New visitors get cold-start fallback. Affinity-driven recipes only shine after the platform has watched the visitor for some duration, typically three to five sessions on a B2C site, longer on B2B.

5. Specific selectors: Categorical, Custom

Categorical recipes recommend within a specific category. Custom recipes accept a manually defined item set as input. Both are escape hatches for cases where the marketing brief is more specific than what the standard recipes solve.

Examples:

• A category-locked "More from Beauty" rail. Categorical recipe with a category filter, ranked by affinity if available.
• A campaign that must show specific items (new arrivals from a brand partnership). Custom recipe with the manually curated list, optionally re-ranked by affinity.

These are not the default tools. They exist for cases the standard recipes cannot solve, not as replacements for personalization in general.

Recipe sequencing

A production placement rarely uses one recipe. The right pattern is a sequence: try recipe A, fall back to recipe B if A returns fewer than N results, fall back to recipe C as the last resort.

A typical home page strip sequence:

1. Recently Viewed (if the visitor has any session history)
2. Personalized affinity ranking of recent catalog activity (if the visitor has affinity)
3. Trending (population-level fallback)

A typical item-detail strip:

1. Similar Items (always works, content-based)
2. Frequently Bought Together (if traffic supports it, replaces or augments)
3. Bestsellers in same category (last-resort fallback)

The point of the sequence is that the visitor always sees something good. The first recipe in the sequence is for visitors with the most signals. Each fallback handles the case where the previous recipe returned weak results.

Common selection mistakes

Five patterns recur on engagements where Sapota gets called in to debug recommendation quality:

• One recipe used everywhere. The home page, category pages, item-detail, all running Bestsellers. Affinity is never read. The system effectively becomes a static merchandising tool.
• Behavioral recipes on small catalogs. A 500-item catalog using Frequently Bought Together. There is not enough purchase co-occurrence data. Recommendations look random. Switch to similarity-based.
• Affinity recipes for cold-start visitors. The first 30 seconds on the site, the visitor sees Personalized recommendations that are pulling from an empty affinity profile. The output is generic. Switch the fallback order so cold-start visitors see Trending until affinity develops.
• Categorical filters that exclude too aggressively. Restricting recipes to a narrow category means there are not enough candidates. Recommendations get repeated or recipe falls back to a weaker source. Loosen the filter.
• Manual curation in Custom recipes that never gets refreshed. The merchandising team set up a Custom recipe in 2024 with a hand-picked list. Three years later it is still serving the same items because no one re-curated. Audit Custom recipes quarterly.

The discipline of recipe selection comes down to matching the placement context, the traffic profile, and the visitor's signal richness to the recipe family that handles those constraints. Sapota's Salesforce team treats recipe selection as a deliberate design step on every Personalization engagement, not as a configuration default.

---

Selecting or auditing Einstein recipes in Marketing Cloud Personalization? Sapota's Salesforce team handles recipe strategy, sequencing, and recommendation tuning on production engagements. Get in touch ->

See our full platform services for the stack we cover.