A Marketing Cloud Personalization recipe out of the box does a reasonable job. It returns items relevant to the placement and the visitor. Most production deployments need more than reasonable. The marketing team wants to exclude items that are out of stock, boost items from a partnership campaign, hide items the visitor already purchased, prioritize new arrivals during launch week. Filters and boosters are how those rules get expressed. They are also where recipes silently break when layered without discipline.
What filters and boosters actually do
A filter is a hard exclusion rule. Items that fail the filter cannot appear in the recipe output. They are removed from the candidate set before ranking happens. Filters are deterministic: the item either passes or does not.
A booster is a score adjustment. Items that match the booster get their relevance score modified up or down. They are still in the candidate set, but their position shifts. Boosters are probabilistic: a strong booster moves an item up, a weak one nudges it.
The mental model: filters decide who is allowed in the room. Boosters decide where they sit.
When to use which
Two questions determine the answer.
1. Is the rule absolute or relative?
"Never recommend out-of-stock items" is absolute. Filter.
"Prefer items from the spring collection" is relative. Booster.
"Hide items the visitor already owns" is absolute. Filter.
"Prioritize items in the visitor's preferred brand" is relative. Booster.
2. Is the rule about availability or preference?
Availability rules (in stock, eligible for shipping, regulatory permitted) are filters. Items that fail are unavailable, not just less preferable.
Preference rules (boost new arrivals, demote items the visitor has seen many times, prefer items in the same category) are boosters. The platform might still want to show them under the right conditions.
The mistake is applying filters where boosters belong. A filter that excludes "items the visitor has not engaged with" eliminates 99 percent of the catalog and produces empty strips. The intent (favor items the visitor has shown interest in) is a booster, not a filter.
Common filter patterns
Five filter patterns recur on real engagements:
- Stock status filter. Exclude items where inventory is below threshold. Universal. Required for any placement that risks recommending unavailable items.
- Geographic eligibility filter. Exclude items not shipped to the visitor's region. Read from visitor profile or session location.
- Already-purchased filter. Exclude items the visitor (or account, in B2B) has already bought. Useful on cross-sell rails. Less useful on item-detail pages where "buy again" can be valuable.
- Category restriction filter. Limit to a specific category. Used when the placement context is itself category-scoped. Example: a Beauty category page strip should only show Beauty items.
- Lifecycle filter. Exclude discontinued items, beta-stage items, items past their seasonal window.
The discipline is to layer filters minimally. Each filter cuts the candidate set. Five strict filters can leave nothing. The recipe falls back or returns empty.
Common booster patterns
Boosters are softer levers. The patterns that work:
- Recency booster. Boost items that were added to the catalog recently. Useful during product launches.
- Margin booster. Boost items with higher profit margin (where the data is available). Subtle. Should not be aggressive enough to override relevance.
- Editorial pick booster. Boost items the merchandising team has flagged as "featured this week." Manual lever, refresh weekly.
- Affinity match booster. Boost items that match the visitor's strongest affinity attributes. Sometimes built in to recipes, sometimes layered explicitly.
- Promotion booster. Boost items currently on promotional pricing. Useful during sale events.
Boosters compound. A recently added item that is also editorially featured and on promotion gets three boosters. The combined boost can outweigh genuine affinity match. Watch for this. Cap the cumulative boost.
The conflict patterns
Five ways layered filters and boosters break recipes:
1. Over-filtering. Stock filter, region filter, already-purchased filter, category filter, brand filter, all applied. Candidate set shrinks to one or zero items. Recipe falls back to a weaker source. Strip looks repetitive.
The fix: review filter stack regularly. Question each filter. Some that seemed essential are unnecessary in practice.
2. Conflicting boosters. Recency booster pushes new items up. Margin booster pushes high-margin items up. The two compete. Items that are both new and high-margin dominate. Items that are neither disappear despite being relevant.
The fix: assign explicit weight to each booster. Document the weight. Adjust based on observed output, not on intuition.
3. Booster overriding affinity. Editorial pick booster is set to a high weight to ensure featured items get prominent placement. The booster overrides the underlying affinity-driven ranking. Personalization effectively turns off for items that were boosted.
The fix: limit booster weights so they nudge but do not dominate. The affinity signal should remain the primary factor.
4. Filters applied to boosted items. A filter excludes items the visitor has already purchased. A booster increases score for high-margin items. A high-margin item the visitor purchased is filtered out before the booster ranks it. Counterintuitive but consistent with how filters precede boosters.
The fix: understand the order. Filters always apply first. Boosters work only on the candidate set that survives filtering.
5. Catalog-level filters in recipe-level config. A filter that should apply to all recipes (exclude items past their seasonal window) gets configured per-recipe. Some recipes have it, some do not. The catalog has effectively two layers of "available" depending on the recipe.
The fix: lift truly universal filters to the catalog level. Use catalog filtering or a global recipe wrapper. Recipe-level filters are for placement-specific rules.
Testing the layered config
A practical test for a recipe with multiple filters and boosters:
- List the candidate set the recipe should produce in the abstract (e.g., "all items in Beauty that are in stock").
- Run the recipe in MCP debug mode. Check the actual output.
- If output is empty or much smaller than expected, walk back through filters one at a time. Disable each, see if output appears. The filter that, when disabled, restores the output is over-filtering.
- If output is the right size but the order looks wrong, check booster weights. Disable boosters individually to see which is dominating.
- Document the final config including the rationale for each filter and booster weight. Future debugging starts there.
Reviewing filters and boosters quarterly
Filters and boosters drift over time. Items get added that should match a filter but were not configured. Booster weights set during launch are still in effect a year later, even though the catalog and traffic have changed.
A quarterly review on every active recipe:
- List every filter currently applied. For each, confirm it still serves a purpose.
- List every booster and its current weight. For each, confirm the weight is still calibrated to the desired effect.
- Test the recipe output on three representative visitor profiles. Confirm the rankings still feel right.
Most teams skip this review for the first 2 years and then face a recipe that has accumulated 15 filters and 8 boosters, none of which the current team understands. Sapota's Salesforce team treats filter-and-booster config as documented configuration, not as silent recipe metadata, and reviews on a calendar regardless of whether the recipe appears to be working.
Tuning Marketing Cloud Personalization recipes or auditing filter and booster config? Sapota's Salesforce team handles recipe optimization on production engagements. Get in touch ->
See our full platform services for the stack we cover.
