Recently Viewed Products: Helping Customers Find What They Forgot

Almost nobody buys on the first visit. A customer finds a product they like, gets pulled away by a phone call or a closing tab, and comes back an hour — or a day — later with one problem: they can't remember exactly what they were looking at. They know it was "the grey one with the wooden handle," but your store has forty of those. So they search, fail, and leave. A recently viewed products block fixes precisely that moment: it hands the customer back the products they already chose, so the path from "I'm back" to "add to cart" is a single click instead of a frustrated hunt.

Last updated: June 2026.

This article is about that one job — closing the gap between intent and the back button by remembering what a visitor looked at. It is not about suggesting products they haven't seen (that's cross-selling and upselling) or saving products on purpose for later (that's a wishlist). Recently viewed is automatic, passive, and built on a simpler truth: recognition is easier than recall.

What PrestaShop already ships — and where it stops

PrestaShop has had a recently viewed feature for years, and most merchants don't realise it's already installed. In 1.7, 8 and 9 it's the native module ps_viewedproduct ("Viewed products block"); on 1.5/1.6 it was called blockviewed. You'll find it under Modules → Module Manager — search "viewed." It displays viewed products on the product page, commonly through displayFooterProduct (the older 1.6 blockviewed used the column hooks), and its one configurable setting is the number of products to display.

Under the hood it doesn't query an order or a customer account at all — it reads a browser cookie named viewed, a simple comma-separated list of product IDs that the ProductController appends to every time a product page loads. That design has two consequences worth knowing before you decide whether the stock module is enough:

• It's anonymous and instant. Because it's cookie-based, it works for logged-out guests from the very first product they open — no login, no account. It works from a browser cookie; handle disclosure/consent according to your cookie policy and local law. So what? The customer who'll never create an account still gets the benefit.
• It forgets when the cookie does. The list lives in the visitor's browser. Clear cookies, switch from phone to laptop, or let the cookie expire and the history is gone. The native module makes no attempt to tie views to a customer ID and follow them across devices.

For a small catalogue placed in a sidebar, the stock module is genuinely fine — don't pay for what you already have. The reasons merchants outgrow it are specific: the default placement (left/right column) is dead space on most modern full-width themes; it can't be put on the cart page where the "did you forget these?" nudge is strongest; and it can't survive a device switch. Those are the gaps a dedicated module exists to fill, covered further down.

Why "recently viewed" pulls its weight

The mechanism is plain cognitive psychology: recognition beats recall. Asking a customer to remember and re-type a product name is asking them to do work; showing them a thumbnail of the exact item they were looking at asks them only to recognise it. One of those is effortful and fails often; the other is instant.

There's a second effect that's easy to miss. A returning visitor who lands on a generic homepage has to re-find their footing — re-navigate categories, re-narrow, re-decide. A returning visitor who immediately sees the three products they were weighing up an hour ago is dropped straight back into the decision they'd already half-made. You're not generating fresh interest; you're resuming interest that already exists, which is far cheaper than creating it.

It's tempting to attach a hard conversion number here, and you'll see "X% of recently-viewed clicks convert" quoted around the web. Treat those figures as directional, not as a promise — the real lift depends on your catalogue size, how often customers comparison-shop before buying, and how visible you make the block. The honest claim is mechanical, not statistical: every customer who'd otherwise have abandoned a re-search is a customer you didn't lose. Measure it on your own store rather than borrowing someone else's percentage.

Where to place it — and why placement changes the job it does

The same block does different work depending on where it sits. Decide what you want it to accomplish, then place it accordingly:

One thing worth knowing before you reach for a module: on PrestaShop 1.7, 8 and 9, ps_viewedproduct implements the widget interface, so you can render it anywhere your theme lets you call a widget — by dropping one tag into a template where you want the block, without registering a new hook:

{* render the viewed-products block in any theme template *}
{widget name='ps_viewedproduct'}

That covers a one-off placement (say, adding it to a custom homepage template). What it doesn't solve is the cookie's limits — and the native ps_viewedproduct is otherwise limited to its built-in product-page placement and does not provide arbitrary cart/home/custom-hook placement without theme/module work, which is why the cart-page placement — arguably the most valuable one — generally needs a more flexible module. If you're rethinking the whole layout while you're in there, our wider guide on PrestaShop product page design covers how a recently-viewed block should sit alongside everything else competing for attention below the fold.

The settings that actually matter

Three decisions decide whether the block helps or just adds clutter:

• How many products to show. Six to eight is the practical sweet spot — enough to jog memory, few enough to scan in a glance. On a one-row layout this is whatever fills the row cleanly; a wall of twenty viewed products stops being a memory aid and becomes noise.
• Never show it empty. A first-time visitor has no history, so the block has nothing to display. Make sure it suppresses itself entirely when the viewed cookie is empty rather than rendering an empty header — an orphaned "Recently viewed" heading with nothing under it looks broken and erodes trust. The native module handles this; a custom theme block sometimes doesn't, so check it logged out in a fresh browser.
• Exclude the product currently on screen. On a product page, the item the customer is looking at right now shouldn't appear in its own "recently viewed" row. It's redundant and wastes a slot. Confirm your module filters out the current product ID.

On mobile, switch the layout from a grid to a horizontal scrollable carousel. Vertical space is the scarcest thing on a phone screen; a single swipeable row shows the same products without pushing your "add to cart" button further down the page. A grid that forces three rows of scrolling on mobile usually does more harm than the block does good.

When to go beyond the native module

You move past ps_viewedproduct when one of its built-in limits starts costing you orders. The clearest triggers:

The cross-device point is the one that genuinely separates the two. A shopper who browses on their phone at lunch and buys from a laptop that evening is a single person to you, but two unrelated cookie jars to the native module — so their morning's research evaporates exactly when it would have closed the sale. A module that keys recently-viewed to the customer ID for logged-in users (storing the history server-side rather than in the browser) carries that history across the gap. If a meaningful share of your traffic shops cross-device — and on most stores it does — that's the feature worth paying for. mypresta.rocks builds personalization modules around exactly this kind of customer-aware, no-theme-surgery behaviour; the practical test for whether you need one is simple: look at how many of your customers start a session on mobile and finish on desktop.

Frequently asked questions

Does PrestaShop have recently viewed products built in? Yes — most merchants don't realise it's already installed. On 1.7, 8 and 9 it's the native ps_viewedproduct ("Viewed products block"); on 1.5/1.6 it was blockviewed. Find it under Modules → Module Manager, search "viewed." Its one setting is how many products to show, and it displays them on the product page (commonly via displayFooterProduct).

How does it remember what a visitor looked at? It reads a browser cookie named viewed — a comma-separated list of product IDs the ProductController appends to on each product page load. It never touches an order or customer account. That makes it anonymous and instant (it works for logged-out guests from the first product), but it forgets when the cookie does: clear cookies or switch from phone to laptop and the history is gone.

Where should the block go? Placement changes its job. On the product page (displayFooterProduct) it helps comparison-shoppers flip between candidates — the strongest spot. On the homepage (displayHome) it re-orients returning visitors. On the cart page (displayShoppingCartFooter) it's the highest-intent nudge: "you looked at these too." The cart placement is usually the most valuable and the one the native module can't do without help.

When is the stock module not enough? When one of its limits starts costing orders: you need it on the cart page or a custom hook, you want history that follows a logged-in customer across devices (cookie-only loses it on a device switch), a proper carousel layout, or "viewed but not bought" filtering on the cart. The cross-device case is the one that genuinely separates the two — a module keying history to the customer ID, stored server-side, carries it across the phone-to-laptop gap where a sale often closes.

How many products should I show, and how on mobile? Six to eight is the practical sweet spot — enough to jog memory, few enough to scan. Always suppress the block entirely when the cookie is empty (an orphaned "Recently viewed" heading looks broken), and exclude the product currently on screen. On mobile, switch from a grid to a single horizontal scrollable carousel so it doesn't push your add-to-cart button down the page.

Where it fits in the bigger picture

Recently viewed is one quiet thread in a store that remembers its customers. It overlaps the deliberate save (a wishlist is intent the customer declares; recently viewed is intent you infer), and it complements the head-to-head comparison shoppers reach for when they can't decide between two products. It's also a building block of the broader case that a trustworthy, frictionless product page makes — the kind of product page anatomy that gets visitors to click buy instead of back.

The whole point is humble: you're not persuading anyone of anything new. You're just refusing to make a returning customer re-find the product they already wanted. On PrestaShop that costs you almost nothing to switch on — ps_viewedproduct is probably already sitting in your Module Manager — and the only real decisions are where to place it, how to lay it out on mobile, and whether your customers shop across enough devices that the cookie's memory needs to become the customer's memory instead.