Open a retailer's app on your phone and it greets you by name, shows the trainers you looked at twice last week, and nudges you toward free delivery because you're two pounds short of the threshold. Open the same retailer on your work laptop an hour later and you're a stranger again. Generic homepage. The trainers gone. The offer gone. Somewhere between the two devices the same person turned into two people, and the business's most expensive personalisation logic never noticed.
Dynamic content optimisation is the practice of changing what a visitor sees, a banner, a product list, an email subject line, a pricing page, based on data about who they are and what they are doing right now. Not one website for everyone. A different arrangement of the same building blocks for each visitor, assembled at the moment the page loads. The phrase sounds like marketing jargon and the underlying mechanics are fairly plain: collect signals, decide a segment or a score, pick a variant, render it, and log what happened so the next decision is slightly better informed.
We build data and AI systems at Shipshape Data, and dynamic content is one of the places we see the gap between ambition and plumbing show up fastest. Teams buy a personalisation platform expecting it to do the thinking, then discover it can only be as good as the identity data and the event stream feeding it, which is usually held together with a cookie, a login, and hope. This guide covers how the decision actually gets made, the data foundation and identity resolution underneath it, how to test and measure whether any of it is working, and where the line sits between useful and unsettling.
How the decision actually gets made
Underneath the phrase "personalised experience" is a fairly small decision tree running many times a second: given what we know about this visitor, which pre-built variant of this content block do we show? The same question gets asked on a website hero banner, a triggered email, an in-app screen and a paid social audience, and the decision engine looks slightly different in each place, but it is the same question every time. Two broad ways to answer it, and most organisations start with the wrong one for their size.
Rules, and when they are enough
A rules engine is a set of if-then statements a human wrote. If the visitor arrived from a paid search ad for "waterproof jackets," show the outdoor hero image. If cart value sits within two pounds of the free delivery threshold, show the free delivery nudge instead of a discount code. Rules are explainable, cheap to build, and easy to audit when something goes wrong, which matters more than it sounds like it should, because something will go wrong and somebody will ask why the site showed a pregnant woman nappy adverts three weeks before she had told anyone.
The honest case for rules is that most businesses do not have anywhere near enough traffic to train a model well, and a rules engine tuned by someone who understands the product will usually beat a machine-learning model starved of data. We have watched clients buy a recommendation engine before they had the volume to feed it, and end up with a system quietly falling back to "most popular item" for the majority of visitors, dressed up as personalisation.
Where models earn their keep
Model-based selection, usually a multi-armed bandit or a small propensity model, picks the variant it predicts will perform best for this visitor rather than the same variant for everyone in a segment. It needs enough events to learn from and enough variants worth choosing between, and it genuinely helps once both are in place: a large e-commerce catalogue with thousands of daily sessions and dozens of plausible content variants is exactly the situation rules cannot keep up with by hand. Below that scale it is overhead dressed as sophistication.
The data foundation dynamic content actually needs
Every dynamic decision draws on three kinds of data, and they behave differently, which is why teams that lump them together tend to build something brittle.
Profile, behaviour and context
Profile data is who the visitor is as far as you can tell: account details, declared preferences, loyalty tier, past purchases. It changes slowly and is usually the most reliable of the three, when it exists at all, because most visitors are anonymous most of the time.
Behavioural data is what they have actually done: pages viewed, items added to a basket and abandoned, search terms typed and deleted before hitting enter. It is abundant, noisy, and decays fast in relevance. A visitor who browsed hiking boots in March is not the same visitor in July, and a system that still thinks they are will keep recommending boots to someone who bought a pair four months ago.
Context is everything true about this specific moment: device, time of day, location, referring channel, current stock levels, even weather in some retail setups. Context is what stops a system recommending an item that is out of stock, or pushing a summer sale to someone browsing at 2am in a country where it is currently winter. It is the cheapest of the three to get right and the one most often ignored.
Freshness beats volume
A well-populated customer data platform full of stale signals is worse than a thin one that is current, because stale personalisation is confidently wrong rather than honestly generic. The practical fix is less about collecting more data and more about deciding, deliberately, how long each signal stays valid. A browsing session might matter for hours. A purchase might matter for months. Treating both the same way is how you end up recommending last season's stock to someone who already moved on.
Identity resolution: knowing it's the same person
None of the above works if the system cannot tell that the visitor on the phone this morning is the visitor on the laptop tonight. This is the part vendors gloss over in the pitch and the part that actually determines whether any of it holds together.
Deterministic and probabilistic matching
Deterministic matching links identities through something exact: a login, a loyalty number, an email address entered at checkout. It is reliable and defensible, and it only covers the fraction of traffic that has logged in or transacted, which on most sites is a minority.
Probabilistic matching stitches together everything else, cookies, device fingerprints, IP ranges, timing patterns, and scores the likelihood that two anonymous sessions belong to the same person. It extends coverage a long way, and it is also the part that quietly breaks. Third-party cookies are dying in most browsers, device fingerprinting is under regulatory pressure, and every year a smaller share of a visitor's behaviour is legally or technically observable across sessions. Build an identity strategy that assumes today's signals and it will visibly decay over eighteen months, not fail suddenly.
Channels rarely share a key
A cookie identifies a browser. A logged-in session identifies an account. A mobile app identifies a device. An email open identifies an address. None of these is automatically the same identifier as the others, and most organisations have four or five systems each convinced they hold the definitive view of one customer, none of them talking to the others. Stitching them together is not a one-off integration project, it is ongoing work, because a new device, a cleared cookie store, or a second email address for the same person breaks the link again the moment it was built.
The practical answer is rarely a single universal identifier. It is closer to a hierarchy: trust the login above the loyalty number, trust the loyalty number above the cookie, and be explicit about how confident each layer is before letting it drive a decision that shows up on screen. A system that treats a shaky probabilistic match with the same confidence as a login is the one that greets a stranger by the wrong name.
The same problem as the golden record
This is the same discipline as master data management, applied to a moving target instead of a customer file. You are deciding, field by field and system by system, which signal wins when two sources disagree about who somebody is. Get the survivorship rules wrong here and the failure mode is not a duplicate invoice, it is a returning customer treated as a stranger, or worse, two different strangers merged into one profile and shown each other's history.
Personalisation is only as confident as the identity underneath it, and most systems are far more confident than the identity underneath them deserves.
Testing what you built, honestly
Shipping a dynamic content system and assuming it works because it launched is the single most common mistake we see. Personalisation needs testing more than a static page does, not less, because the whole premise is that different content performs better for different people, and that claim is falsifiable.
Segments dilute significance faster than people expect
Split visitors into twelve segments and test three variants in each, and you now need statistically meaningful traffic in thirty-six buckets rather than three. Most sites do not have it. The result is a dashboard reporting a lift in a segment that never crossed a sample size large enough to trust, and a team making decisions on what is essentially noise wearing a percentage sign.
The fix is unglamorous: fewer segments than you want, held for longer than feels comfortable, with a pre-registered idea of what a meaningful lift would look like before you look at the results. If you cannot say in advance how large an effect would justify shipping the change, you are not testing, you are hoping.
Bandits are not a shortcut around this
Multi-armed bandits shift traffic toward the better-performing variant as the test runs, which sounds like a free efficiency gain and sometimes is. It also means you are looking at a moving allocation rather than a fixed split, and reading a bandit's outcome with the same instincts you would apply to a clean A/B test will mislead you about how confident you should actually be. Bandits suit situations where speed matters more than a clean causal answer, a homepage banner during a sale weekend, say. They suit pricing decisions and anything with legal or reputational weight far less well, where a slower, cleaner test is worth the wait.
Measuring whether it actually worked
The metric that gets reported after a personalisation rollout is often the metric that was easiest to pull, not the one that answers the actual question. Click-through on a personalised banner nearly always beats a generic one. That tells you people click things that look relevant to them, which nobody doubted. It does not tell you whether the business is better off.
The harder, more useful question is incremental: would this visitor have bought, or stayed, or upgraded, without the personalisation at all? That is the same puzzle attribution modelling tries to answer for marketing spend, and it is worth borrowing the discipline rather than reinventing it badly. A holdout group, a slice of traffic that never sees the personalised version, however small, is the cheapest way to keep an honest baseline in view. Skip it and you will eventually be reporting a lift against a version of yourself that never existed.
Watch, too, for metrics that look good and mean something uncomfortable. A spike in add-to-basket rate paired with a flat conversion rate usually means the system is showing people things they are curious about rather than things they will buy, which is a fine outcome for engagement reporting and a poor one for revenue.
Where personalisation turns creepy
There is a line, and most people cannot define it precisely but recognise it instantly when a site crosses it. Showing someone a jacket like the one they looked at yesterday feels helpful. Showing them an advert that reveals you know they are pregnant, or unwell, or going through a divorce, before they have told anyone, feels like an intrusion, even when every signal used to infer it was collected legally.
The legal floor sits below the comfortable line
Compliance with data subject rights and consent requirements is the minimum, not the target. A business can be fully compliant, consent captured, purposes documented, and still build something that makes people uneasy the first time they notice how much the site seems to know. That reaction costs trust in a way no regulator measures, and it tends to surface as quiet churn rather than a complaint you can act on.
A rough working rule we use with clients: if you would be uncomfortable explaining out loud, to the customer, exactly which signal produced this piece of content, do not ship it. "We showed you this because you looked at similar items last week" survives that test easily. "We showed you this because your browsing pattern statistically resembles someone in a life stage we infer from search terms" does not, even if it is technically true and technically permitted.
Who owns it once it's live
Dynamic content systems decay the same way master data does: quietly, and mostly because nobody owns the ongoing decisions once the initial build is finished. Segment definitions drift out of date. Rules written for last year's catalogue keep firing on a catalogue that has moved on. A content variant that was a good idea in a launch meeting eighteen months ago is still live because removing it was nobody's job.
The organisations that keep this working have a named owner for the rules and the identity logic, separate from whoever owns the platform licence, someone with the authority to retire a rule that stopped making sense rather than letting it run because touching it feels risky. They also review the test backlog on a schedule rather than letting winning variants sit forever unchallenged, because a variant that won eighteen months ago against an older baseline has not necessarily won against anything current.
Decay is the default state
Nobody schedules a meeting to let a personalisation rule go stale. It just happens, in the gaps between more urgent work, and the first sign is usually a customer complaint rather than a dashboard alert. A quarterly review of live rules against current catalogue and current segments catches most of it: which rules still fire on inventory that no longer exists, which segments haven't been redefined since the product line changed, which content variant has been "winning" against a control nobody has refreshed in a year. It is a short, dull meeting compared with the build itself, and skipping it is exactly how a system that launched well ends up quietly wrong two years later.
Where to start
Start with rules, not a model, unless your traffic genuinely justifies the leap, and be honest with yourself about which of those two situations you are actually in. Get identity resolution right for the visitors you can identify with confidence, logins and loyalty numbers, before spending effort chasing probabilistic matches for the anonymous majority. Build a holdout into every test from day one so you always have an honest baseline to measure against, and decide, before you look at results, what a meaningful lift would need to look like.
Then apply the discomfort test to anything new before it ships: if you could not explain the signal behind a piece of content to the person seeing it, that is the moment to pull back, not push forward. Personalisation done well is quiet and mostly unnoticed. Personalisation done badly is the thing people screenshot and complain about. If you are weighing up a dynamic content programme, or you inherited one that nobody has looked at properly in a year, talk to us.