Product Recommendations Wizard

Product recommendations put the right items in front of each visitor — cross-sells on a product page, a “recently viewed” rail on the homepage, best-sellers in the category they are browsing. This wizard walks you from catalog to live widget.

Watch the 3:02 walkthrough: the whole wizard — importing the catalog, tracking what shoppers do, designing the widget and placing it on the page.

In the panel: New campaign › Web Browser › Product Recommendations.

You can place several widgets on the same page, each running a different algorithm. If you need an algorithm Personyze does not offer, contact your account manager or support@personyze.com.

The steps

Eight steps, and the step bar groups them into three bands that open in turn:

Build — Catalog, Interactions, Content, Target. Everything you decide before anyone sees it.
Check — QA and Simulator. The bar labels this band after Publish until you publish to staging.
Live — Automation and Performance, labelled after Publish to live.

A closed band still holds its place in the bar and names the control that opens it, so you can see what is coming. A band that was open and closed again says paused rather than asking for the publish a second time.

Note the order — Content comes before Target. You design the widget first, then decide who sees it.

1. Catalog — the items to recommend from

The Catalog step of the Product Recommendations wizard — The Catalog step: what is in the catalog, how fresh it is, which fields the engine can actually use, and what else it learns from. Click to enlarge.

Personyze recommends from the product catalog it keeps for your site, and targeting rules match against that same data. The step opens with the size and freshness of that catalog — how many products, when the last successful sync ran, and when it was last checked — beside Import, Add product and a product search.

Under it, one line per feed: whether the feed is healthy, whether email alerts are on, and links to View feeds and settings or Add a feed. A feed is what keeps the catalog current; without one it goes stale, and so do the recommendations built on it.

Fields the engine uses

This is the part worth reading before anything else. Personyze measures coverage of each field across the whole catalog and draws it as a bar — In stock, Image, Price, Product link, Category, On sale — with the out-of-stock count beside it. A field at 100% is one every algorithm and every filter can rely on. A field at 40% is one that will quietly drop most of your catalog out of any widget that sorts or filters on it.

What else the engine learns from

On-site behaviour — product shown, added to cart, purchased. The engine needs these as much as it needs the catalog; the step links straight to product tracking.
Purchase history — upload past orders and the engine starts from what already sold together instead of spending weeks learning it live. One row per order line: order ID, product ID, date, and value if you have it.
Categories and interests — categories arrive from the feed on their own; interests are themes you can add on top.

Three ways to fill the catalog from your own pages

Besides a feed, the catalog screen’s Data settings menu can build catalog data out of the pages you already publish:

Grab columns from site — for each product URL you already have, Personyze fetches that page and reads column values out of it with CSS selectors. This is the one to reach for when a feed is missing a single field you can see on the page.
Grab interests from site — extracts keyword text from those pages and groups products into topical interests.
Site crawl — Personyze visits your product pages itself, discovers them, and assembles the catalog from what is on them. This one is switched on per account by Personyze support, so if you do not see it in the menu, ask us. See Building the catalog by crawling your site below.

2. Interactions — what the engine learns from

The Interactions step, showing the health of each product event — The Interactions step grades every event: how many arrived, how it compares with the step before it, and what is not arriving at all. Click to enlarge.

This is the step that decides whether your recommendations are any good, and the one most often skipped. Personyze learns from what visitors do with your products — what they view, add to cart, favourite and purchase — and this step is a health report on exactly that.

The top of it counts the whole set: how many events exist, how many are active, and how many actually arrived in the last seven days, with chips for All, Healthy and Needs attention so you can jump to the broken ones.

Each event then carries its own evidence:

Product shown is marked required — the whole funnel starts here, and nothing downstream works without it.
Added to cart, Removed from cart, Added to favorites and Purchased each show their volume and their ratio to the step before — adds as a share of views, purchases as a share of adds. A ratio that looks impossible usually means the event is firing in the wrong place, not that your shop is extraordinary.
An event that has never arrived says Never received, and one that has no source configured says Not set up. Those two are the ones to fix.

Below the events, what we learn while they browse — the categories being viewed — and what this data feeds: the recommendation sets built from these events, and the trending report. Both cover the whole account rather than this campaign, and both open in a new tab.

3. Content — the widget itself

What you build here is the frame, not a fixed list: what it recommends is decided per visitor at the moment it renders. Three campaign-wide controls sit above the widget itself, and all three are easy to miss:

Campaign cap — how often this campaign may show to one visitor. Out of the box there is none.
Goals — by default the campaign is measured against your account-wide goals; you can add one dedicated to this campaign.
A/B — Activate A/B testing turns the single piece of content into two competing versions. See A/B testing.

The Content step of the Product Recommendations wizard, where recommendation actions are added and A/B testing can be activated — The Content step. A campaign is built from one or more actions; A/B testing can be switched on here. Click to enlarge.

The Content step with a recommendation action added, showing a live preview of the widget rendering real catalog products with prices and Add to Cart buttons — Once an action is added, the Content step previews the real widget — rendered from your actual catalog. Click to enlarge.

Click Add action to open the action picker. It lists every action type available for this campaign — Product Recommendations, Product Recommendations JSON Feed, Social Proof Widget, Category Recommender and Lead Form with Personalized Recommendations — with tabs for All, Most popular, Recommendations and Forms, remarketing emails.

The Add action panel, listing action types such as Product Recommendations, JSON Feed, Social Proof Widget, Category Recommender and Lead Form, filtered by All, Most popular, Recommendations and Forms tabs — The action picker. Search by name, or filter by category. Click to enlarge.

Pick an action type and you land in the template chooser. Start blank, copy from an action you already built, or pick a ready-made template. Templates are grouped into List & Strip, Bought Together, Slider, Vertical and Countdown, each with a thumbnail and a description of what it does.

The template chooser for Product Recommendations, showing template thumbnails grouped by List and Strip, Bought Together, Slider, Vertical and Countdown — The template chooser. Every template is fully editable once inserted — the grouping is a starting point, not a constraint. Click to enlarge.

Once a template is inserted you configure the recommendation itself:

The context — home page, category page, product page, cart, post-purchase, search, or not-found. The context shapes which algorithms make sense.
The algorithm — personalized picks, others-who-viewed, bought together, most popular, best sellers, recently viewed, items in cart, buy it again, cross-sell and more.
Modifiers — a time window (today, recently, last 2 / 4 days, last week, all time), a category scope (all categories, the current product’s category, the last viewed category), an interest scope, and ordering such as recent-first or cheapest.
Filters — restrict the pool by stock, price range, brand, category, or any custom catalog field.
The design — pick a template and edit it, or write your own HTML.
Placement — which placeholder on the page the widget renders into.

You can also activate A/B testing from this step to run two algorithms or two designs against each other and let the results pick the winner.

Inside the action editor

Once a template is inserted, the action editor opens with three sub-steps of its own: Select Recommendation Algorithm, Customize Look and Feel, and Placement, Trigger & Frequency.

Sub-step 1 — the algorithm and its guard rails

Step 1 of the recommendation action editor: the selected algorithm, output and fallback settings, skip rules, catalog restrictions and custom filter rules — Sub-step 1. The algorithm is only the first choice — everything below it decides what is allowed to appear. Click to enlarge.

Beyond picking the algorithm you control:

Output — how many items to show, plus fallback algorithms that fill empty slots when the first choice returns too few. This is the safety net that stops a widget rendering half-empty.
Skip items the visitor already… — exclude what they are viewing now, have viewed before, have in cart, have wishlisted, or have already purchased. The last one matters most: recommending something a visitor just bought is the classic own-goal.
Restrict the catalog — match the visitor’s gender or age, only (or never) discounted items, prefer recently-viewed or interest categories, or limit to selected categories.
Group similar items — collapse variants so one product does not fill the whole widget.
Custom filter rules — combine any product field with geo location using AND / OR / NOT groups, compared against a constant or a visitor-profile field.

Choosing an algorithm

The recommendation algorithm picker, filtered by page (Home, Category, Product, Cart, Thank you, Search, 404) and by type (Personalized and Behavioral, Cross-Sells, Visitor History, Catalog Events, Custom) — The algorithm picker. Filter by page first, then by type. Click to enlarge.

Pick the page first. The page is not just where the widget shows — it changes how the algorithm works. Behavioural algorithms use a different anchor per page: the current product on a Product page, all recently-viewed items on Home, cart contents on Cart.

Available pages: All pages, Home, Category, Product, Cart, Thank you, Search, 404. Not every algorithm suits every page, so the count next to each page tells you how many remain.

The algorithms

Seventeen algorithms in five families. Expand a family to see what is in it.

Personalized & Behavioural — 4 algorithms

Best when the visitor’s intent is not yet clear. Good defaults for homepage and category pages.

Personalized Recommendations	Picks based on the visitor’s demographics plus similar visitors’ behaviour.
Most Popular	Items most shown across the site.
Best Sellers	Highest purchase count.
Most-Added to Wishlist	Items most often saved to favourites.

Cross-Sells, Co-Views & Upsells — 8 algorithms

Anchored to a product context — what the visitor is viewing now, has in cart, or recently engaged with.

Others Who Viewed Also Viewed	Co-viewed by other visitors.
What Others Viewed Then Bought	Bought by other visitors who viewed the same items.
Cross-Sells	Items co-purchased with the anchor. Auto-learned by Personyze.
Inspired by Category	Items in the anchor category.
Up-Sells	Higher-priced alternatives to the current product or cart items.
Managed Cross-Sells	Cross-sells from a catalog you upload and maintain yourself.
Cross-Sells for Last Item Added to Cart	Co-purchased with the single most recent item added to the cart.
Last Bought Item: Those Who Bought This Also Bought	Co-purchased with the single most recent item the visitor bought.

Visitor History — 2 algorithms

Surfaces things this specific visitor has touched before. Best for returning visitors and post-purchase pages.

Recently Viewed	Products this visitor viewed recently.
Your Wishlist	Items this visitor saved to their wishlist.

Catalog Events — 2 algorithms

Triggered by changes in your catalog — price drops, new arrivals.

Price Dropped	Items cheaper than at the visitor’s last visit.
New in Stock	Recently added, or new since the visitor’s last visit.

Custom — 1 algorithms

When you want full control — you define the filter, Personyze ranks within it.

Any products

All products, ordered as you like and optionally narrowed with your own filter rules.

Most algorithms take modifiers: a period (recently, today, last 2 / 4 days, last week, all time), a source scope (any, mix categories, mix interests, current category, last or all viewed categories, cart categories, visitor interests), and a sort (purchased, added to cart, wishlisted, viewed, cheap, recently added, high rated, high profit). Cross-sell algorithms add a price relationship — cheaper than, more expensive than, or within a price band of the anchor item.

Sub-step 2 — look and feel

Sub-step 2 of the recommendation action editor: style accent, text font, item info order and layout controls beside a live preview of the widget rendering products with images, prices and sale badges — Sub-step 2. The preview is live — change a preset and the widget redraws. Click any element in it to edit that element directly. Click to enlarge.

The same template can look very different. Four one-click presets do most of the work:

Style accent — light (clean blue), gold (dark premium), bold (red), ocean (deep blue). Recolours toggles, buttons, totals, links and cards together.
Text font — system (clean sans-serif), serif (classic), rounded (friendly), condensed (narrow, space-saving).
Item info order — standard, price-first, info-top, name-first.
Layout — horizontal (card row, the default), vertical (stacked list), compact (mini strip with small photos).

A few things sit above the preview: Change template, Add to your templates (to reuse this design later), a Preview as on switch for phone / tablet / desktop, undo and redo, and Edit action with AI.

The products in the preview are demo products. They appear only while you are designing so the layout has something to render — site visitors never see them. Once the campaign runs, the widget fills with real items chosen by your algorithm.

Below the presets you can set catalog fields, the layout title, how many recommendations are visible before a Show More link, prices, the Add to Cart button and its success or failure messages, extra product info, and social-proof lines such as live viewed / bought / low-stock. HTML Source (advanced) at the bottom gives developers the raw markup.

Each preset also has a ⚡ Variations control — that is how you generate variants of the same widget to A/B test.

Sub-step 3 — placement, trigger and frequency

First decide where on the page:

Inline element — renders inside a placeholder in your page. Native and non-intrusive; it stacks with the rest of the content. You can select more than one placeholder.
Floating popup — sits on top of the page, optionally over a dimmed backdrop. Best when you want the visitor to deal with it before carrying on.

The behaviour settings — entrance animation, modal backdrop, scroll-with-page, close button, auto-close — mostly apply to floating popups only. For an inline element they are shown disabled rather than hidden, so the screen does not change shape when you switch.

Finally, when it opens: stack as many triggers as you like and the first match opens it — on page enter, after a delay, when idle for a period, or on engagement.

4. Target — who sees it

The widget is already built; these rules decide where it appears and to whom — every page by default, or only the home page, only category pages, only visitors in a segment, only people with something in their cart. A single widget can be narrowed further to a page group with Restrict to in its own editor.

You do not have to write the rules yourself: the AI targeting assistant at the top of the step turns a sentence into rules, and can either append them to what is there or replace what is there. The rules it writes are ordinary rules, editable like any other. It draws on your monthly AI allowance.

The Target step of the Product Recommendations wizard, with audience rules, campaign readiness checks and the audience forecast — The Target step. Readiness checks are on the right; the audience forecast shows how many visitors currently match. Click to enlarge.

With no rules, the widget reaches every visitor — which is often exactly right for a recommendation rail. Add rules to narrow it: first-time versus returning visitors, people with something in the cart, a particular audience or CRM segment.

Rules combine into groups with AND / OR / XOR, and any group can be flipped between Include and Exclude. The AI targeting assistant will generate rules from a plain-English description if you would rather not build them by hand.

On the right, campaign readiness lists what still has to be true for the campaign to run — site tracking being the critical one — and the audience forecast estimates how many recent visitors match.

5. QA — preview it before anyone sees it

The Preview & QA step with its campaign summary and three preview modes — Preview & QA: what the campaign is about to do, and three different ways to look at it — only one of which is evidence. Click to enlarge.

The step opens with a campaign summary in plain words — who it targets, how many actions it presents, and which placeholder each one uses — so you can catch “this targets everybody” before a visitor does.

Then it asks two questions: which page? and how do you want to run it? The three answers are not equivalent, and the step labels them so you cannot mix them up:

On your site — marked real test. Real rules, real you; audience rules, view limits and rotation all apply. The bar on the page says what ran and why. This is the only mode that is evidence of what a visitor gets.
On your site, forced — marked not a test. Rules are ignored and the content shows whoever you are. Useful for looking at the design, useless for proving the targeting works.
In the Simulator — marked sandbox. A made-up visitor whose attributes, audiences and history you can edit.

Any of the three can be opened on your own machine, copied as a link, or emailed to a colleague — all three need you to choose a page first.

The audience forecast beside it counts recent visitors that would and would not match. Note the caveat the panel itself carries: these numbers come from recent preview and staging sessions, not from your live audience.

The specific thing to check for recommendations: does the widget actually come back populated? An empty widget in preview almost always traces to step 1 or 2 — a catalog that did not import, or interactions that are not being tracked — rather than to your targeting. The Simulator step next door is the faster way to tell those apart.

6. Simulator — run the algorithm on one person

The Recommendation Simulator step — The Simulator answers one question: given this widget and this person, what would the engine actually pick? Click to enlarge.

The QA step asks whether the campaign shows up. The Simulator asks what it would recommend — it runs this campaign’s algorithm on its own, with no page and no targeting in the way.

Pick a widget from widgets in this campaign, then choose who to simulate:

Visitor — search by the whole email address or the whole user ID your site sends (neither matches on part of one), or filter by behaviour instead: among visitors on the site now or past visitors, who did some interaction at least N times. List who matches and Pick one turn that filter into a real person.
Product — what the engine would put next to one particular item.
New visitor — someone with no history at all, which is the case most recommendation setups get wrong. If this comes back empty, your widget has no fallback and first-time visitors will see nothing.

The widget stays selected while you step through people, so you can hold the settings still and vary the person — which is how you tell “the algorithm is wrong” apart from “this visitor has no history”.

7. Automation — start and stop by rule

The Automation step, where rules can start or stop a campaign based on a date or on measured campaign or site performance, with a history of what automation has done — The Automation step. Nothing here is on unless you add it. Click to enlarge.

Automation lets the campaign start or stop itself. Pick what should trigger it — a date, this campaign’s own numbers, or the whole site’s — and say what should happen.

Nothing here is on unless you add it. Without an automation, the campaign only starts and stops when somebody does it by hand.

One timing detail that matters: measured rules are checked once a day against completed days, so they describe yesterday rather than this afternoon. Do not expect an automation to react within the hour.

The History panel records only the moments that matter — a rule starting to match, an email sent, a webhook fired, a campaign switched — not every check.

8. Performance — once it is live

Impressions, engagement and the revenue attributed to the widget. You can set the reporting range to run from the campaign start or from the last edit — the latter is what you want after changing an algorithm, so old results do not mask the new behaviour.

Two places to look, on two different clocks

Personyze reports campaign results in two places, and they update on very different schedules. Knowing which is which saves a lot of “is my campaign broken?”

Live Visits — immediate. The moment a visitor matches, they appear here. You can see sessions arriving, which campaign matched them, and what they did, within seconds. This is where you confirm a freshly published campaign is actually working.

The Live Visits dashboard showing 48 users and 53 sessions in the last 90 minutes, a sessions-over-time chart, Campaign 3 as the top matching audience, and a live session feed with geography, device and product activity — Live Visits, minutes after publishing. Top Audiences confirms the campaign is matching — here every one of the 53 sessions. Click to enlarge.

The Performance step — hours later. Visitor stats are only calculated once a session ends, and a session stays open until the visitor has been idle for a while. Add processing time on top and the panel’s own guidance applies: data appears about an hour after the first matching session ends, and can take 1–3 hours to settle.

So a campaign published this morning showing zero on the Performance step this afternoon is normal. Check Live Visits first: if sessions are arriving and the campaign appears under Top Audiences, it is working and Performance will catch up.

Performance data appears about an hour after the first matching session ends, so a freshly published campaign shows nothing at first. That is expected, not a fault.

Building the catalog by crawling your site

Most catalogs arrive as a feed. When there is no feed to be had — a platform that will not export one, a site whose item data only exists on the page — Personyze can build the catalog by visiting your own pages and reading what is on them.

Ask support to switch this on. The crawler is enabled per account by Personyze, one account at a time. Until it is, Crawl my site simply is not in the Data settings menu — there is no disabled button and no error to misread.

Once it is on, open Product Catalog → Data settings → Crawl my site (the same entry says article pages on a content catalog). Personyze starts from the pages you give it, follows your sitemap or the links it finds, and queues every item page; a background job then reads them one at a time.

The Crawl my site dialog — Crawl my site, with a finished pass underneath it: what was queued, what kind each page was judged to be, and whether it was read. Click to enlarge.

Start pages — one URL per line. Your homepage is not always the best choice; a section index or a sitemap usually finds more. If your site answers the crawler with a 403, the Crawl blocked or returning 403? What to allow link in the dialog says what to let through.
Item URL pattern — a regular expression matching your item page URLs. It decides what a fetched page is judged to be, so a loose pattern turns listing pages into catalog rows.
Page limit — stops the crawl after this many pages.
Re-crawl schedule — off (only when you press Crawl now), daily or weekly. A scheduled re-crawl reads only what has changed since the last pass; Force a full re-crawl instead re-reads everything.
Unpublish pages that no longer exist — when a page starts answering “not found”, its item is unpublished rather than left in the catalog advertising a dead link.
Read pages in a real browser — for a shop or magazine that builds its pages with JavaScript. Slower, and it covers far fewer pages per crawl, so leave it off unless a plain fetch comes back empty.

Beside the settings: Field mapping (point a field at a CSS selector, at the URL, or at a fixed value), Tracking suggestions (what to track next, from the pages already crawled) and Access credentials (a cookie or API header for a site that is not open to the public).

Watching a crawl, and what lands on its own

Progress at the bottom of the dialog is where you check the result: how many of the queued pages have been read, and a row per URL with what it was judged to be and whether it was read. That table is the fastest way to catch a pattern that is matching the wrong pages.

Title, description and main image usually arrive without any configuration, because most sites publish them as og: tags for social sharing. Price, SKU and brand usually do not — they are visible text rather than declared metadata, so they stay empty until you point Field mapping at a selector.

Crawl once with a small page limit, look at what came back in the items table, and only then map the fields that are missing. It is much faster than guessing selectors first.

Publishing

Three options in the top bar: Save as draft, Publish to staging and Publish to live. Staging lets you see the widget on the real site without exposing it to real visitors.

What Performance looks like with data

Once traffic flows, the Performance step shows the recommendations funnel with real money attached: transactions and attributed revenue, the widget’s share of total revenue, how many sessions were shown widgets and how many actually viewed them, plus daily funnel dynamics and revenue attribution against the site total.

Recommendations performance with data — A recommendations campaign’s Performance step: transactions, attributed revenue, Shown/Viewed funnel, and revenue attribution over time. Click to enlarge.

Content Recommendations Wizard — the same flow for articles and videos.
JSON API — Product Recommendations — the same engine, raw JSON output.
Products object and product interactions in the REST API.