AI Personalised Recommendations for UK Ecommerce

In short

Generic “Customers also bought” widgets lift AOV by maybe 1–3%. Properly-built AI recommendations on your actual customer data lift AOV by 15–30%. The difference is using behavioural patterns, not just co-purchase data, and delivering recommendations across product pages, cart, checkout, email and post-purchase, not just one widget.

Delivered as a Quick Win (£1,500–£3,500, 1–3 days) for small automations or an Implementation Sprint (from £8,000, 4 weeks) for production workflows. Priced against scope. Tests via Prototype Guarantee at £1,000.

Where personalised recommendations land

Six surfaces, in order of typical impact:

1. Cart page: “complete your set” / “frequently bought together”. Highest absolute revenue lift per visitor.
2. Product page: “customers like you also viewed”. Boosts engagement + AOV.
3. Post-purchase email: second-order driver. Three weeks after first order, AI predicts the right next-purchase prompt.
4. Homepage: personalised hero for returning visitors.
5. Abandoned cart email: recommendations alongside the abandoned items, calibrated to convert at the right discount level.
6. Checkout extensions: last-second add-ons. Real revenue per impression.

How we build

We use your store data (Shopify / WooCommerce / Magento) plus a recommendation engine layer (custom Claude/OpenAI scoring + classical collaborative filtering hybrid). Output is fed back into your existing tools (Klaviyo, your store theme, your checkout) via API.

Why generic widgets stopped working

Every ecommerce platform comes with a “customers also bought” widget out of the box. It uses simple co-purchase data: shoppers who bought X also tended to buy Y. The lift over showing nothing at all is modest, typically 1 to 3 percent of AOV. Most SME store owners install the widget, see the marginal lift, and conclude that personalisation is largely a solved problem.

The widget is solving a narrow version of the problem. It treats every shopper identically. Two shoppers landing on the same product page see the same recommendations regardless of their browse history, their previous purchases, their cohort, or their probable intent. The widget is a static lookup table, not a model.

Properly-built AI recommendations close the gap by treating each shopper as an individual. A returning customer who has bought twice in the past 12 months sees recommendations calibrated to their actual purchase pattern. A first-time visitor sees recommendations based on the path through the site so far and the cohort their browse pattern matches. The same product page produces ten different recommendation sets for ten different shoppers, each one calibrated to the shopper’s specific signal.

The lift this produces over the generic widget is typically 5 to 10 times. The absolute AOV lift over no recommendations at all sits in the 15 to 30 percent range across comparable SME ecommerce deployments.

What “personalisation” actually means here

Six dimensions of signal feed the recommendation engine. The exact mix varies by store; most builds use five of the six.

• Purchase history. What this shopper has bought before, when, at what price, with what return behaviour. The strongest predictor when it exists.
• Browse behaviour. What this shopper has viewed in this session and previous sessions. Category breadth, dwell time, scroll depth, add-to-wishlist behaviour.
• Cart context. What is already in the cart. Recommendations should complete the set, not duplicate.
• Cohort. Which segment this shopper sits in (from the customer segmentation work) and what shoppers in that segment typically buy next.
• Inventory and margin. Recommendations are weighted toward products with healthy stock and reasonable margin, not just toward the highest co-purchase score. Out-of-stock items get suppressed automatically.
• Time of day and seasonality. Some products convert better at certain times; the model accounts for it.

The output is a ranked recommendation list, refreshed per impression, with each recommendation tagged with the reason it was selected. The merchandiser can audit any recommendation back to the signals that produced it.

Where the recommendations show up

The six surfaces in the section above account for the bulk of the lift. The Wingenious build sequence usually implements them in this order based on observed payback.

• Cart page. Highest absolute revenue lift per visitor. Shoppers in the cart are buying; the question is what else they buy. “Complete the set” or “frequently bought together” calibrated to the actual cart contents produces immediate AOV lift.
• Product page. Lower absolute lift than cart but huge impression volume. The cumulative impact across the store can be larger than the cart page.
• Post-purchase email. Three weeks after the first order, the AI predicts the right next-purchase prompt. Replenishment patterns, complementary products, seasonal next-step. Drives second-order rate.
• Homepage. Returning visitors see a personalised hero. New visitors see trending products. The shape adjusts to the shopper rather than presenting the same page to everyone.
• Abandoned cart email. Recommendations alongside the abandoned items, calibrated to convert at the right discount level (sometimes no discount; sometimes 10 percent; rarely a sledgehammer 25 percent).
• Checkout extensions. Last-second add-ons on Shopify Plus or Magento. Real revenue per impression because the friction to add is so low.

A typical sprint implements the top three surfaces. A custom build implements all six, integrated.

How the cold-start problem gets solved

A genuine challenge. First-time visitors have no history to personalise from. Three classes of fallback handle this until enough signal accumulates.

1. Bestsellers. The products that everyone buys, presented honestly as “popular right now”. A reasonable baseline that converts above no recommendation.
2. Trending. Products gaining velocity in the last 7 or 14 days, which often beats raw bestseller data when seasonal or trend effects are live.
3. Category-affinity inference. The first product or category the visitor engaged with is enough signal to infer broad cohort. Within one or two pages, the model can move from generic to roughly-targeted recommendations.

After the first session, behavioural data accumulates and the model transitions to fully personalised. Done well, even new shoppers see recommendations that feel relevant from session one.

When personalised recommendations pay back

The strongest payback is in stores with at least 1,000 monthly transactions and a catalogue of 100 or more SKUs. Below 1,000 transactions, the model takes longer to learn against your specific data and the build cost is harder to justify against the absolute lift. Below 100 SKUs, the recommendation problem is simple enough that the generic widget gets most of the way.

The payback is weakest in two situations.

1. Tiny catalogue. Below 50 SKUs, the merchandiser can hand-curate the recommendations and beat any model.
2. Single-purchase categories. Where customers buy once and rarely return for years (large appliances, mattresses), the post-purchase and second-order surfaces do not earn back the build cost. Personalisation focuses on the cart and product page only.

The technical shape of the build

The architecture has three layers.

• Data layer. Store events stream into a warehouse layer (BigQuery, Snowflake or Postgres). Customer, product, transaction, browse and cart events normalise to a shared schema.
• Model layer. A hybrid of classical collaborative filtering with LLM-assisted scoring. The collaborative filter handles the volume; the LLM layer handles the nuance (matching on attributes, applying seasonality, blending in cohort signal).
• Activation layer. Recommendations served back to the storefront via the Shopify Storefront API, WooCommerce REST API or Magento GraphQL. Recommendations served back to email via the Klaviyo or Mailchimp API. Built on Make.com, or bespoke code via Claude Code depending on integration complexity.

A/B testing infrastructure is built in from day one. The lift is measured against a control group, not against gut feeling.

Engagement options

Three shapes.

1. Prototype Guarantee at £1,000 / 7 days. A working cart-page recommendation widget running against a slice of your real store data. Useful where leadership wants to see lift on a real test before committing.
2. AI Implementation Sprint from £8,000, four weeks. Three recommendation surfaces into production with A/B testing, with 30-day stabilisation. Smaller scopes are implemented as a Quick Win from £1,500.
3. Custom Build from £9,950 fixed or £6,000+/month retainer where the catalogue is unusual, where the integration goes beyond standard ecommerce APIs, or where the full six-surface build needs to be implemented over a longer engagement.

Ongoing running costs typically land between £200 and £800 per month for an SME ecommerce store with under £5 million revenue. Modest against a 15 to 30 percent AOV lift.

What the merchandiser actually does post-launch

The fear most merchandisers have is that AI recommendations remove their job. The reality is that the job changes.

Pre-build, the merchandiser spends most of their time on tactical work: choosing which products feature on the homepage hero, curating the “customers also bought” widgets, writing the manual cross-sell logic on key product pages. Volume-sensitive work that limited what the merchandiser could touch.

Post-build, the tactical work is mostly handled by the model. The merchandiser shifts to strategic work: defining the rules the model honours (margin floors, never-show pairings, brand-promotion overrides), reviewing the model’s recommendations for the categories that matter most, and partnering with marketing on the seasonal campaigns where merchandising and promotion intersect.

The merchandiser’s working day becomes more interesting and more strategically valuable. The volume work that used to fill the day stops being the constraint.

When the build needs a refresh

Three signals that the recommendations are no longer earning their keep.

1. The lift against control narrows. The A/B testing infrastructure keeps measuring against a control. When the lift drops below the threshold that justifies the running cost, the model needs retraining or the surfaces need redesigning.
2. The catalogue has changed materially. A major range expansion or contraction shifts the recommendation space enough that the model needs fresh training data.
3. The customer base has changed materially. Acquisition through a new channel brings a customer cohort the model has not learned. Performance for that cohort lags until the model catches up.

The Quarterly AI Review (where one runs) audits the lift and flags any of these signals.

How the build coordinates with email

The strongest recommendation builds connect the on-site recommendations to the email programme. Three integration patterns work well.

The first is segment-aware email content. The segment the customer sits in (from the customer segmentation work) feeds into the email tool, and email content blocks include recommendation slots that draw from the same model the website uses. The customer sees consistent recommendations across the two channels.

The second is browse-abandonment recovery. When a customer browses without buying, the next email surfaces recommendations specifically calibrated to the browse pattern, not just generic bestsellers. Conversion on browse-abandonment emails roughly doubles compared to generic content.

The third is post-purchase next-step. Three weeks after the first order, an email lands with recommendations calibrated to the replenishment pattern, the complementary product set, or the seasonal next step. Second-order rate lifts meaningfully against the baseline.

These three integration patterns each add modest build complexity for substantial revenue lift. Most sprints implement at least one of them; custom builds usually implement all three.

Related capabilities

Customer segmentation · Multilingual customer support · Pricing optimisation · Marketing automation

Related

Sector fit: ecommerce.