How recommendations are picked
Before we dive into the catalog, a few rules apply to every algorithm:- Already-purchased items are filtered out. If a customer has bought a product, Maestra will not recommend it back to them.
- Zone and brand restrictions are respected. Recommendations only include products that match the customer’s region/zone and the brand context of the channel.
- Stock and availability are checked. Out-of-stock items are excluded automatically.
- Per-project limits. Each algorithm has a cap on how many active instances you can run per project. The cap is noted on each algorithm below.
- Refresh cadence. Some algorithms recalculate once a day (used for stable signals like overall popularity or co-purchase). Others run in real time (used for in-session behavior).
Where to use which algorithm
A quick mental map before you read the catalog:- Homepage — Popular Products, Personal Recommendations, Event-Based Personal Recommendations, Recently Viewed Products.
- Category page — Popular Products by Category, Popular Products in Viewed Categories.
- Product page — Similar Products, Complementary Products, Manual Category Matching.
- Cart / checkout — Complementary Products to List, Complementary Products to Last Order, Similar Products to Product List.
- Post-purchase emails — Complementary Products to Last Order, Manual Category Matching to Last Order, Personal Recommendations.
- Cart-abandonment emails — Similar Products from Last Session, Complementary Products to List.
- Wishlist / back-in-stock emails — Similar Products to Product List.
The 14 algorithms
1. Popular Products
Calculates the most popular products across the whole catalog for a selected time window. Popularity is ranked first by the number of orders, then by the number of product views as a tiebreaker.- Best for: homepage, “Bestsellers” blocks, cold-start visitors with no behavioral history.
- Signals used: order count, view count.
- Refresh: once a day.
- Limit: up to 40 instances per project.
2. Popular Products by Category
The Popular Products algorithm, scoped to a single category. Each instance is tied to one category and only ranks products within it.- Best for: category landing pages, category emails, “Top in [Category]” rails.
- Signals used: order count and view count, restricted to the category.
- Refresh: once a day.
- Limit: up to 20 instances per project.
3. Popular Products in Viewed Categories
Looks at the categories a customer has interacted with in the last 90 days and recommends popular products from those categories. Runs in real time so the rail updates as the customer browses.- Best for: homepage personalization for returning visitors, category pages, “For You” rails.
- Signals used: the customer’s category views over the last 90 days, plus category-level popularity.
- Refresh: real time.
- Limit: 1 instance per project.
4. Similar Products
Builds a per-product list of similar items. The algorithm is tunable so you can shape how many recommendations a product gets based on its price tier — expensive products typically benefit from more alternatives, while cheap products need fewer.- Best for: product detail pages (“Similar items”), out-of-stock fallbacks.
- Signals used: product attributes, category, price band, co-view patterns.
- Refresh: once a day.
- Limit: up to 5 instances per project.
5. Similar Products from Last Session
Real-time variant of Similar Products that uses the product(s) the customer viewed in their current or most recent session. Designed to re-engage browse-abandoners.- Best for: browse-abandonment emails and pushes, return-visit homepage rails, exit-intent popups.
- Signals used: last-session product views.
- Refresh: real time.
- Limit: up to 2 instances per project.
6. Similar Products to Product List
Takes an arbitrary list of products as input and returns similar items for each. Useful when the trigger product set isn’t a single SKU — for example, the entire wishlist or a back-in-stock notification batch.- Best for: wishlist follow-up emails, back-in-stock notifications, “We’ve got alternatives” messages.
- Signals used: product similarity across the input list.
- Refresh: real time.
- Limit: up to 3 instances per project.
7. Complementary Products
Recommends products that are frequently bought together with a given product. Built on receipt-level co-purchase frequency, with category-pattern reinforcement.- Best for: product detail pages (“Frequently bought together”), cart pages, order confirmation emails.
- Signals used: co-purchase frequency in past orders, category co-occurrence.
- Refresh: once a day.
- Limit: up to 5 instances per project.
8. Complementary Products to Last Order
Real-time variant of Complementary Products, personalized to the items in the customer’s most recent order.- Best for: post-purchase emails, order-confirmation up-sell, “Complete your purchase” pushes.
- Signals used: items in the last order, plus catalog-wide co-purchase frequency.
- Refresh: real time.
- Limit: 1 instance per project.
9. Complementary Products to List
Like Complementary Products to Last Order, but the input is any product list — typically the current cart. Designed for cart-abandonment and live cart up-sell.- Best for: cart pages, cart-abandonment emails and pushes, mini-cart drawers.
- Signals used: items in the input list, co-purchase frequency.
- Refresh: real time.
- Limit: up to 3 instances per project.
10. Manual Category Matching
Lets you define custom rules linking categories — for example, “show accessories from category B when the customer is on a product in category A.” Rules can be derived from real purchase patterns or set up manually by a merchandiser.- Best for: merchandiser-curated cross-sell on product pages, editorial pairings, brand-rule enforcement.
- Signals used: your custom rules; optional similarity weighting.
- Refresh: once a day.
- Limit: up to 5 instances per project.
11. Manual Category Matching to Last Order
Real-time variant of Manual Category Matching that fires off the categories present in the customer’s last order. Same custom rule set, applied to post-purchase context.- Best for: post-purchase emails, replenishment flows, “Goes with what you just bought” pushes.
- Signals used: categories in the last order, plus your manual rules.
- Refresh: real time.
- Limit: up to 5 instances per project.
12. Personal Recommendations
Predicts what each customer is most likely to buy next, using a collaborative-filtering-style model. It combines the customer’s own views and orders with the behavior of similar customers (peer analysis).- Best for: homepage “For You” rails, personalized email blocks, account/dashboard recommendations.
- Signals used: the customer’s product views and orders, look-alike customer behavior, catalog metadata.
- Refresh: once a day.
- Limit: up to 5 instances per project.
13. Event-Based Personal Recommendations
Real-time personalization that works for known customers and anonymous visitors. Reacts to in-session events (views, add-to-carts, searches) without requiring an identified profile.- Best for: anonymous-visitor homepages, search results pages, in-session re-ranking, first-touch personalization.
- Signals used: real-time session events.
- Refresh: real time.
- Limit: 1 instance per project.
14. Recently Viewed Products
Shows products the customer has viewed in the last 14 days, most-recent-first. Not a prediction model — it’s a memory aid that lifts return-conversion.- Best for: homepage and product-page rails, “Pick up where you left off” emails.
- Signals used: the customer’s view history over the last 14 days.
- Refresh: real time.
- Limit: 1 instance per project.
Choosing between daily and real-time algorithms
A rule of thumb when you have a choice:- Use daily algorithms when the underlying signal is stable across the day — overall popularity, catalog-wide co-purchase, baseline similarity. They’re cheap to serve and produce consistent rails.
- Use real-time algorithms when the recommendation has to react to what the customer just did — abandoned a cart, viewed a product five minutes ago, just placed an order. Real-time is where lift comes from on cart, post-purchase, and re-engagement surfaces.