CASE STUDY · HEADLESS COMMERCE & E-COMMERCE PERSONALIZATION
Building a personalized product recommendation engine for an online retailer.
- 6%Average order value up 6%
- 11%11% click-through on recommendations
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised online retailer. Name withheld under confidentiality.
Event tracking, recommendation models and on-site placements. We started with the data, then models, then the places on the site where recommendations appeared.
- 1Every shopper saw the same merchandising.
- 2The home page, category pages and product pages showed best sellers and manual picks, whatever a visitor had browsed.
- 3A returning customer who had viewed running shoes three times still saw a general mix.
- 4The team knew it was leaving sales on the table but had no tracking in place to act on, and no way to prove that personalisation would pay.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In early tests, the model recommended almost entirely popular items, so the personalised block looked the same as best sellers
Popular products dominated the training data. We added a step that down-weighted extremely popular items, mixed in items related to the shopper's recent browsing and enforced a minimum variety across categories. We also reviewed output by hand with the merchandising team, who spotted odd pairings the numbers had hidden.
- PROBLEM 02The second version was clearly more relevant and tested better against the control
- PROBLEM 03A second hurdle was cold start
New products had no events, so they never appeared and never gained any. We added a small share of slots for new items, chosen by category similarity and by merchandiser picks, and let their own events take over after enough views. We also showed returning shoppers a recently viewed row, which cost almost nothing and performed well.
- PROBLEM 04We also showed returning shoppers a recently viewed row, which cost almost nothing and performed well
03 · THE PROCESS
How we ran it.
We split the work into three stages with a review at the end of each.
- 01Step 1
Data first: we defined the events to capture, fixed product data and set up a persistent shopper identity.
- 02Step 2
Baseline models: we shipped simple, explainable recommendations such as "viewed together" and "bought together", and measured them.
- 03Step 3
Improved models: only after the baseline had traffic did we add a model that used each shopper's recent behaviour.
We ran weekly reviews of click and order data with the merchandising team. Every placement launched as an experiment with a control group.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Product data quality is owned and checked, because the recommendations depend on it.
- NOW 02
New placements start as experiments with a control group.
- NOW 03
Merchandisers can set rules and pin products without engineering help.
- NOW 04
Consent status is part of every personalisation decision.
- 6%
Average order value up 6%
- 11%
11% click-through on recommendations
05 · WHAT WE BUILT
How it works.
- A tracking layer recorded product views, searches, add-to-cart, purchases and removals, with a stable shopper ID that survived across sessions and merged on login.
- Events went through a queue into a warehouse, and a nightly job built product and shopper features.
- Product data was cleaned first: category trees, duplicate variants, missing attributes and out-of-stock items.
- The recommendation service returned a ranked list for a shopper and context, with rules on top: no out-of-stock items, no items already bought, and brand or margin constraints set by merchandising.
- Placements on the home page, product page and cart called the service through a cached API with a fallback to best sellers if it was slow.
- Consent was checked before tracking.Shoppers who declined saw non-personalised results.
- Controls
- Recommendations never overrode inventory or compliance rules. Items under recall, hidden for legal reasons or out of stock were filtered after ranking, not before, so a model mistake could not surface them. Each placement logged what was shown, in what order and to which experiment group. A kill switch per placement returned the page to the old merchandising in seconds.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Every shopper saw the same merchandising. The home page, category pages and product pages showed best sellers and manual picks, whatever a visitor had browsed. A returning customer who had viewed running shoes three times still saw a general mix. The team knew it was leaving sales on the table but had no tracking in place to act on, and no way to prove that personalisation would pay.
- What did Brandsmashers build?
- Event tracking, recommendation models and on-site placements. We started with the data, then models, then the places on the site where recommendations appeared.
- How was the work run?
- We split the work into three stages with a review at the end of each.
- What were the results?
- Average order value up 6%; 11% click-through on recommendations.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
