Product Recommendations Wizard

Build a product recommendation widget from catalog to live campaign — including the interaction tracking that decides whether the recommendations are any good.

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.

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

Seven steps: Catalog, Interactions, Content, Target, QA, Automation and Performance.

Automation and Performance only appear once the campaign has been saved. On a brand-new unsaved campaign you will see five steps; save it as a draft and the other two appear.

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, showing the item count and import feed status — The Catalog step shows how many items Personyze holds and whether an import feed is keeping them current. Click to enlarge.

Personyze recommends from the product catalog it keeps for your site, and targeting rules match against that same data. The step shows your item count and how many import feeds are scheduled.

Schedule an import feed. A one-off upload works to get started, but without a feed the catalog goes stale — and so do the recommendations and rules built on it. Prices drift, sold-out items keep being recommended, new arrivals never appear.

Keep is_in_stock accurate for the same reason: nothing damages trust like recommending something a visitor cannot buy.

Getting products in

The Product Catalog page showing 40 products, active feed count, last sync time and catalog health, with options to push data by file upload, URL feed, SFTP or REST API — The Product Catalog page. It reports item count, active feeds, last sync and overall health at a glance. Click to enlarge.

Four ways to get products in, from Settings › Product Catalog:

File upload — a CSV or spreadsheet. Fine to start with; it is a snapshot, not a sync.
URL feed — Personyze fetches a feed on a schedule. This is what most catalogs should use.
SFTP — you drop a file, Personyze picks it up.
REST API — your backend pushes items as they change. See the products object.

Map up to two keys: Internal ID and SKU. The Internal ID is what on-site events tie back to, so it must be the same value your tracking sends. Getting this wrong is the classic cause of a catalog that looks fine and recommendations that never learn.

What a product record looks like

Only internal_id and a title are strictly required, but the richer the record the better the recommendations and the more you can filter on:

{
  "internal_id": "nw-p001",
  "title": "Alpine Shell",
  "url": "https://example.com/shop/alpine-shell",
  "image_1": "https://example.com/img/alpine-shell.jpg",
  "price": 249,
  "sale_price": 199,
  "category": "Jackets",
  "brand": "Northwind Outfitters",
  "is_in_stock": 1
}

Any additional key you send becomes a custom field, available immediately as a recommendation filter and a targeting rule. You can add custom fields at any time without redefining anything.

Two fields carry more weight than their size suggests: image_1, because a card with no image renders as an empty box; and is_in_stock, because recommending an out-of-stock item is worse than recommending nothing.

The empty state

A catalog with no scheduled feed shows “No import feed scheduled yet — items will go stale without one.” That is not a blocker — the campaign will build and save — but prices, stock and new arrivals will drift out of date from the day you upload. Treat it as a to-do, not a warning you can dismiss forever.

2. Interactions — what the engine learns from

This is the step that decides whether your recommendations are any good, and the one most often skipped.

Personyze learns from how visitors interact with your products. Four interaction types are tracked, and the step shows how many events reached Personyze in the last 30 days, plus how many distinct products each covers:

Viewed — required. Without it, almost every algorithm has nothing to work from.
Added to cart
Favorited
Purchased

An empty interaction type means every recommendation and rule that relies on it has nothing to go on. If “Purchased” shows zero events, then “best seller” and “bought together” cannot work — they will fall back to something more generic, or return nothing.

The Interactions step showing event counts for the last 30 days across Viewed, Added to cart, Favorited and Purchased, each with a Show code snippet button — The Interactions step. Each type shows events received in the last 30 days and how many distinct products they cover. Click to enlarge.

Each type has a Show code snippet button giving you the exact tracking call, and the step links through to the full product tracking settings where containers, Google Tag Manager and SDK integrations are configured.

Setting up tracking

The Product interaction tracking page listing the seven trackable events with their container counts, events received in the last 7 days, and per-event setup — Settings › Product Tracking. Seven events, each with its own sources and a live count of what has arrived. Click to enlarge.

Settings › Product Tracking is where the events are configured. Seven events can be tracked; Product Shown is the required one. The page shows, per event, how many sources feed it, how many events arrived recently, and when the last one landed — so you can tell at a glance which are genuinely wired up.

Each event can be filled from more than one source, and you can mix them:

Containers — Personyze reads the product id straight out of your page HTML using a selector you define.
Google Tag Manager — Personyze detects GTM events you already fire.
JavaScript snippet — call the tracking API directly from your page code. Each event card has a Show code snippet button with the exact call.
REST API — for events that do not happen in a browser at all: offline purchases, phone orders, back-office refunds. See product interactions.

One behaviour worth knowing: on a given page, only one product view per session is logged, so a page that fires the event repeatedly will not inflate your numbers.

The empty state, and why it matters

A fresh account reads “7 events · 0 active · 7 not set up”, and every event card shows 0 events. Nothing warns you when you publish. The campaign will run, the widget will render — and the algorithms behind it will have no behaviour to learn from, so everyone sees roughly the same generic list.

Before publishing a recommendation campaign, check this page and confirm at least Product Shown and Product Purchased are receiving events. Those two carry most of the engine.

3. Content — the widget itself

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 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 — before publishing

The QA step of a saved campaign showing the campaign summary, shareable preview links, simulator preview, overlaps and conflicts panels, and preview results — The QA step once the campaign is saved. Click to enlarge.

Save the campaign as a draft and the QA panels open. There are four:

Campaign summary — who you are targeting and how many actions you are presenting, in one sentence.
Preview options — get a shareable preview link for any URL on your site (it shows the content even when audience rules are not met), or open the site in the Simulator, which lets you fake user variables such as country or time to trigger matches.
Overlaps & conflicts — where this campaign collides with your other live campaigns: shared audiences, actions firing for the same visitors, and other campaigns using the same placeholders. Worth a look before publishing.
Preview results — note the caveat: these panels reflect the last 90 minutes of preview / staging traffic, not your live audience or all-time totals.

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.

6. 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.

7. 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.

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.

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.