Magento Personalization Extension: Per-Shopper Product Ranking

FastMagento made Magento’s pages cheap to serve. Once a listing, a search or a product page costs a handful of queries no matter how big the catalog is, the next question is not “how fast” but “how right, for this shopper”. FastMagento Personalization is my answer: every shopper gets their own product order, built from what they already bought, searched for and filtered by — with no model, no SaaS, and no data leaving your store.

What Magento Personalization Does for Each Shopper

A shopper who has bought black clothing eleven times should not have to scroll past orange hoodies to find the black ones. Personalization re-orders three places for each logged-in shopper:

• Category listings — products this shopper is likely to want climb up to about a page; everything else keeps your merchandising order.
• Search results and instant search — among products that match the words equally well, the ones they prefer come first. A better text match still wins.
• Related, up-sell and cross-sell rows — the products you linked stay exactly the same; only their order changes.

On a configurable product page it also preselects the size or color the shopper usually buys, when it is in stock. Everything stays selectable.

Which Shopper Signals Drive Personalization?

There is no event pipeline to buy and no second copy of your data in someone else’s cloud. The strongest signals are ones your store already has — and throws away:

Those are the default weights. One-star reviews and returns count as negatives — but only against that product. A return is usually the wrong size, so it never turns into “dislikes blue”.

How the Personalization Algorithm Decides, Step by Step

Personalization here is a chain of small, visible decisions, run in this exact order, and every step has a setting you can turn:

1. Signals Count what each shopper bought, searched, filtered, viewed and saved — per attribute, and per category they bought from.
2. Gate one: is the preference real? The choices must be concentrated (someone who buys every color has no color preference) and there must be enough history (one purchase is not a taste).
3. Gate two: would acting on it change anything? A value most products carry cannot re-order a page. Boosting “size L” when half the catalog has L moves nothing, so it is refused. Rare values score higher.
4. Boosts Each value that passes both gates gets a boost, capped at the two strongest per page so the page cache stays small.
5. Balances An exploration slot and an A/B test keep the whole thing honest (more on both below).

A size or year the shopper typed into search skips the first gate and ranks at three times the strongest inferred preference: what someone typed beats what we worked out about them.

Magento Personalization Example: Four Shoppers

This was run on a demo store (Magento 2.4.9, sample data, Hyvä). Three customers each placed eight to ten orders, always in the same color and size. Here is what each saw, against a guest:

Notice what did not happen. Size M is on 52% of the catalog, so boosting it would shift every product equally — it was refused for listings and used only to preselect the variant, where it is exactly right. Color was only preselected where the product actually came in that color. And nothing disappeared: every listing kept every product.

The fourth shopper bought eight tops in six colors and four sizes. The only thing her orders shared was a material. The built-in explain command shows exactly what the module concluded:

$ bin/magento fastmagento:profile:inspect --customer=6
  pattern   ACTIONABLE but NON-DISCRIMINATING — "Solid" is on 67% of the catalogue
  material  ACTIONABLE ("Organic Cotton" on 22% of listings)
  color     ignored (too spread out, or too little evidence)

$ bin/magento fastmagento:personalization:explain --customer=6 --category=21   # Women › Tops
PLP  +0.0885  inferred Organic Cotton   [18% of the category carries it]

$ bin/magento fastmagento:personalization:explain --customer=6 --category=22   # Women › Bottoms
PLP  +0.0077  inferred Lycra®           [8% of the category carries it]

On tops she is lifted on organic cotton. On bottoms, organic cotton is on 52% of the category, so it is refused there and her next materials rank instead. Through Varnish, logged in, the first organic cotton top moves from fourth to first. The guest’s page is unchanged, and color — which she has no consistent taste in — is never touched.

Avoiding the Rich-Get-Richer Ranking Trap

Popularity-driven ranking has a loop it cannot escape: the most-shown products get the most clicks, so they keep being shown. Measured on a real store:

Re-ranking cannot fix a loop that is the ranking. So by default, 10% of page one is an exploration slot: the last card or so goes to the least-shown product that still matched, so new stock gets a measured chance to be seen. “Never shown” is not “never bought”. The slot never touches your curated related or up-sell rows, and setting it to zero turns it off.

A/B Testing Magento Personalization

“It ranks differently” is not the same as “it sells more”. Turn on the A/B test and half of your shoppers get personalization while the other half get your store exactly as it is. Assignment is sticky and hash-based, and the dashboard compares sessions, orders, revenue and conversion for each half. An optional Auto setting then tunes the overall strength toward whatever the test shows converts best — slowly, at most 0.05 per night, and it tells you on the dashboard when and why it is holding still.

Does Personalization Work with Varnish and Full-Page Cache?

Personalization and full-page caching normally fight. Magento varies its page cache by customer group, not customer, so without care the first personalized page would be served to everyone in the group — the wrong order for them, and a leak of the first shopper’s taste. The module adds a short signature of the boosts a request would use (not the shopper’s identity) to the cache key. Shoppers who would see the same order share one cached page; shoppers who would not cannot collide; shoppers with no preference share the normal anonymous page. It works with Magento’s built-in cache and with Varnish, and the same fix is applied to the product-option block cache.

It also costs nothing per page. Measured on a live store, turning personalization on did not raise the MySQL query count of any page:

Profiles are rebuilt hourly off the request path, and with personalization switched off every page is byte-identical to FastMagento without the module installed.

Personalization for Any Magento Catalog, Not Just Apparel

The attributes it learns come from your own catalog’s filterable attributes, or the ones you list. A hardware store’s “1/4 inch” shopper and a chess store’s “wood” shopper are lifted by the same code that lifts a “blue, size M” shopper — and any value the whole store or category carries is refused automatically. Profiles, measurements and settings are per store view.

Frequently Asked Questions