What personalization is
Personalization is the practice of matching what a user sees to what is known about them. The same
URL shows different people different products, banners and sort order, while the page structure and
the navigation stay the same.
The signals behind that adjustment fall into three layers:
| Data layer | What it covers | When it becomes available |
|---|---|---|
| Visit context | Device, traffic source, city, time of day, landing page | From the first request |
| In-session behaviour | Views, filters, search queries, add-to-cart events | After a few actions |
| Accumulated profile | Order history, affinity to brands and categories, price band | After several visits |
The defining difference between personalization and manual interface settings is where the
initiative sits. When the shopper picks the city or the size themselves, that is customization. An
explicitly stated preference always outranks a computed one: overriding a chosen city with a “more
likely” one is the classic mistake that destroys trust in a site.
The difference from segmentation is granularity. A segment describes a group — men 25–34 who
have bought footwear. Personalization, taken to its limit, describes one person. In practice the two
live together: segments carry the business logic and the constraints, and the algorithm picks inside
them.
Maturity levels
Rollouts almost always go through the same four stages. Skipping one does not work — each stage
depends on the data and the processes of the one before it.
| Level | What it does | What it requires | Typical effect |
|---|---|---|---|
| 1. Segments | Different content for 3–10 groups | Analytics, manual setup | The first few percent on CR in narrow scenarios |
| 2. Rules | If-then conditions on behaviour and context | Event tracking, a campaign editor | Growth on triggered scenarios |
| 3. ML 1:1 | Individual selection of products and content | Accumulated history, a personalization engine | The bulk of the revenue gain |
| 4. Real time | Reacting inside the session in milliseconds | Event streaming, low latency | Highest on new and anonymous traffic |
A sensible order of work: close levels 1–2 on your highest-traffic surfaces first, accumulate event
data, and only then switch on algorithmic selection. Starting with 1:1 personalization while
tracking is still missing is pointless — the models have nothing to learn from.
Where it applies
Personalization is not a separate page but a layer applied over surfaces you already have. Their
priority is set by traffic volume and by proximity to money.
| Surface | What gets personalized | Note |
|---|---|---|
| Homepage | Hero banner, curated blocks, category order | Wide reach, a lot of new traffic |
| Category listing | Product order, promo blocks | PLP personalization carries the heaviest traffic of any scenario |
| Product page | Similar items, accessories, bought-together blocks | Direct effect on average order value |
| Cart and checkout | Add-ons, free-shipping thresholds | Handle with care — any noise here costs conversion |
| Search | Result ranking, suggestions | The highest-intent audience on the site |
| Mobile app | Feeds, in-app messages, onboarding screens | Requires one shared profile with the web |
| Product blocks inside campaigns | The personalization platform supplies the block content; your ESP sends the message |
One boundary is worth stating outright: a personalization platform decides what to show, but it is
not a communication channel. Sending email, push and SMS is the job of your ESP and your marketing
automation stack. Personalization drops a relevant product block into someone else’s campaign — it
does not replace the sending system.
What data you need
Data requirements depend on the scenario, not on the “power of the algorithm”. The minimum set to
start with:
Events (required):
page_view — page view with a type (home / PLP / PDP)
product_view — product view with an ID
add_to_cart — add to cart with an ID and a quantity
purchase — order with line items, total and order ID
Catalogue (required):
product feed: ID, title, price, availability, category, brand, attributes, image
Identity (recommended):
anonymous device ID + user ID after sign-in
It is worth separating the sources. First-party data is collected by your own systems and keeps
working under any third-party cookie restriction, while zero-party data is what the shopper
tells you directly — in a quiz, a survey or their account settings. The second kind is especially
valuable for new users who have no history yet.
The most common cause of weak results is not the algorithm — it is the feed. Stale stock levels,
missing attributes and product IDs that do not match between the site and the feed all lead to
personalization recommending things that are out of stock. Catalogue quality gets checked before
launch, not after the first A/B test.
How to measure the effect
Personalization is the one class of change where the temptation to report on before-and-after
movement is strongest and most damaging. The correct measurement setup:
- A control group. Part of the traffic — usually 10–50% — sees the non-personalized version for
the whole duration of the test. - One primary metric. Most often revenue per visitor: it combines conversion rate and order
value, so a win cannot come from sacrificing one for the other. - A run to a sample size calculated in advance. Stopping a test the moment the numbers look
good is a guaranteed way to get a false result. - A long-term holdout. A permanent 5–10% of traffic without personalization answers the
question of what the platform is worth right now, not what it delivered at launch.
| Metric | What it shows | Risk if used alone |
|---|---|---|
| Block CTR | Visibility and relevance | People click but do not buy |
| CR | Share of converting sessions | Can rise while order value falls |
| AOV | Average order value | Can rise while CR falls |
| RPV (revenue per visitor) | The combined effect | Slower to reach significance |
| Attributed revenue | The contribution of specific blocks | Depends on the attribution window and model |
Section map: types of personalization
Personalization breaks down into a set of narrower concepts — by surface, by mechanic and by data
type.
By surface:
- Homepage personalization — hero banner and curated blocks by segment or profile
- PLP (category) personalization — the order of products in a listing
- Personalized banners — swapping the creative and the offer by audience
- In-app personalization — feeds, screens and in-app messages
By mechanic:
- Dynamic content — blocks whose contents are decided by a rule or an algorithm
- 1:1 personalization — individual selection instead of group rules
- Real-time personalization — reacting to actions inside the current session
- Hyper-personalization — combining behavioural, contextual and external signals
- Personalized recommendations — product selection as a special case of personalization
Infrastructure:
- Personalization engine — the system that decides what to serve
- CDP — the store of profiles and the source of segments
- Affinity profile — the vector of a user’s preferences
Implementation checklist
- Pick the surface with the most traffic. Personalizing a rare scenario produces a handsome
percentage lift and an invisible contribution to revenue. - Check the feed and the events. Product IDs match, stock levels are current,
purchase
arrives without losses. - State the hypothesis with an expected effect. Without an expected effect you cannot calculate
a sample size. - Launch an A/B test rather than switching it on for everyone. Otherwise, a month later, there
is no answer to the question of what actually worked. - Fix one primary metric and a set of secondary ones to watch for side effects.
- Wait for the calculated sample size. Interim peeks are not results.
- Keep a permanent holdout after the rollout, so you can measure the platform’s contribution
over quarters. - Respect the user’s explicit choices — city, size, language, opting out of recommendations.