Personyze Wiki Personyze Wiki docs
English
Open Personyze
Docs/ Recommendation Setup & Feeds/ Setting Recommendation Fallbacks
Recommendation Setup & Feeds

Setting Recommendation Fallbacks

Add fallback algorithms for visitors the first choice has nothing for, and decide with Fill empty cells whether a short result is topped up.

6 min read Updated 4 days ago

An algorithm can only recommend from the data it has. A returning visitor with history gets a personal row; a first-time visitor, a product nobody has viewed alongside anything, or a filter that leaves the row short gets less — sometimes nothing. A fallback is a second algorithm that runs when the one before it comes back short.

Watch the 4:17 walkthrough: “also viewed” narrowed to the brand on the page, with a fallback that keeps the brand and carries its own title.


Adding a fallback

In the recommendation editor, the Output card → Fallback algorithms → Add fallback. It opens the same algorithm picker as the main one, with one difference: the page row reads Anchor, and the anchor you choose is stored with the fallback — it keeps its meaning even if the main algorithm’s page changes later.

Each fallback then shows as a row — Fallback 1: Similar Items (AI) — with Edit and Remove. Edit opens its settings: the algorithm (Change), When this fallback shows, Final touches, Filters and Group result by.

The Output card with Recommendations to show, Fallback algorithms with Add fallback, two fallbacks and the Fill empty cells toggle
The Output card: two fallbacks in order — Similar Items (AI), then Most Popular — and Fill empty cells, off. Click to enlarge.

Good fallback choices

Fallback Why
Most Popular or Best Sellers, site-wide Need no history, reflect what sells now. The strong default for any audience.
Most Popular or Best Sellers with Taken from set to a category When there is context — the category page being viewed, the category of the product on this page — category-bounded popularity is more relevant than site-wide.
Similar Items (AI) / Similar Content (AI) Fills with on-topic items instead of generic bestsellers, and works for items nobody has viewed yet. Needs Similar items (AI) switched on.
Trending Now Offered on every page, and needs no history.
Any products, Sort by: High rated For sites where ratings sell. It reads the rating field of your catalog feed.
Any products with filters A curated pool — on sale, one brand, one category — when you want control rather than an algorithm.

When the fallback fires

Fallbacks run in order when the algorithm before them returns fewer items than the widget shows. Each has its own setting, When this fallback shows:

Mode What happens
Fill the remaining spots (the default) If the choices before it return fewer items than the widget shows, this fallback completes the row.
Only when there’s nothing else to show It stays hidden while any earlier choice has items, and takes over completely when none do. The honest mode for a widget titled after its main algorithm: one “recently viewed” item padded out with best sellers is often worse than the one item alone.

The main block’s filters apply to every fallback. Anything you set on the fallback itself — its Final touches, Filters, Group result by — only narrows it further. So a widget filtered to the brand on the page keeps recommending that brand when the fallback takes over: more from this brand, not whatever sells best site-wide. Skip items the visitor already… and Fill empty cells are set once, for the whole widget.

With Match the visitor conditions on the widget, a fallback’s items are sorted by the same conditions, within its own results, and always come after the main algorithm’s, however well they match. With Hide the widget, a fallback adds only its matching items. See Match the visitor.

Fallbacks chain: add as many as you need, and they run in the order you set. A “personalized → popular in this category → popular site-wide” cascade covers more visitors at each step. The QA bar shows which algorithm actually filled each slot.

Fill empty cells

A separate switch in the same card, and off by default on a website widget. Off, “Only what the recommendation actually returned is shown. If it returns nothing, the block is empty.” On, a short or empty result is topped up: the most popular items first, then the catalog itself (a category recommender tops up with the rest of your categories). The fallbacks above apply either way — this only fills what they leave.

A title per fallback

A fallback changes what the widget shows, so it can also change what the widget says — “Frequently bought together” should not sit over a row that is really a best-sellers fill.

In the design editor (Customize Look & Feel, or the Look step of an email recommendation), templates that offer it show a Widget titles entry. It opens as:

  • Main title — used when the first-choice algorithm serves.
  • One row per fallback, labelled with its number and algorithm name, each with a checkbox. Unticked — the default, Uses the main title — the fallback inherits the main title; tick it and a title field appears for that fallback alone.

The titles are ordinary dynamic text: variables and tokens work in them exactly as in any other title.

Which title shows depends on the fallback’s mode. A title belongs to whichever algorithm leads what the widget serves. In Fill the remaining spots mode a mixed row — main items topped up by the fallback — keeps the main title, because it still leads with main items; the fallback’s title appears only when the fallback serves alone. In Only when there’s nothing else to show mode every row comes from one algorithm, so the heading always matches the items under it.

The heading only renders when the widget has something to show. When nothing serves at all, the title disappears with the widget rather than floating over an empty box.
It depends on the template. The entry appears in templates designed to offer Widget titles; a template without it simply has one title. It works wherever the template customizer does — on-site widgets, email recommendations and get-code widgets — but not in the Canvas Builder. It supersedes the older email pattern of one “Title (fallback)” field shared by every fallback.

Best practices

  • Give every personal algorithm a fallback. “Personalized for this visitor” only works if the visitor has data.
  • Match the fallback to the surface. A homepage deserves Most Popular. A product-page “also viewed” row should fall back to popular items in the same category, or Similar Items (AI) — not random products.
  • Do not fall back to an unfiltered Any products. With no sort and no filter it is simply your catalog, in no particular order. Out-of-stock items are left out automatically; add a sort and the filters that make the pool worth showing.
  • Test the fallback explicitly. A visitor with no history is exactly who it is for: use Reload as a new visitor on the QA bar, or the QA simulator.
Did this page answer your question?
Thank you — that goes to whoever maintains this page.