> ## Documentation Index > Fetch the complete documentation index at: https://help.maestra.io/llms.txt > Use this file to discover all available pages before exploring further. # Recommendation Algorithms in Maestra Maestra ships with 14 recommendation algorithms you can drop into your site, app, emails, push notifications, and call-center scripts. Each one is tuned for a specific surface — homepage, category page, product page, cart, post-purchase email — and uses a different signal mix to decide what to show. You configure algorithms under **Content → Product Recommendations**. The sections below walk through every algorithm, what it does, where it works best, how often it refreshes, and the per-project limits. ## 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. You can configure the time window the popularity score is computed over (for example, last 7 days vs. last 30 days), as well as filters by category, brand, or zone. ### 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. Most production setups mix both: daily algorithms for evergreen rails (homepage bestsellers, category top lists) and real-time algorithms for behavioral triggers (cart, browse abandonment, post-purchase). ## Next steps Once you've picked the algorithms you want to run, head to **Content → Product Recommendations** to create the recommendation block, point it at one of these algorithms, and embed it on your site, email, or push template.