Personalisation that doesn't feel creepy

Picture the moment. A user browses a navy jacket on your site Tuesday evening, closes the tab, opens their email Wednesday morning to a subject line that says "We noticed you were looking at the navy jacket." Instant flinch. They didn't object to being shown the jacket — they object to being told you watched them look at it. Same data point. Different phrasing. That phrasing is what crossed the line.

Now run the same data through different copy. Our user opens a weekly digest, and the navy jacket sits at the top of a row of recommended product. No flinch. They register the relevance — "oh, that's the one I was looking at" — and either click or don't. Same browse signal, same product, completely different experience. One reads as being watched. Another reads as being served.

That's the rule most teams miss. How you signal what you know matters more than what you know. A marketing team showing off its data infrastructure in the copy is the fastest way to trip the reaction. Quiet relevance — the same data, never narrated — is usually fine.

Which means this is a copy discipline more than a data one. You can hold every user's complete behavioural history (every page view, every cart event, every email open) and never trigger the creepy reaction, provided your copy treats the data as invisible context rather than a headline.

Show the relevance, hide the source. "Here are jackets we think you'll like" works. "Based on the jacket you viewed on Tuesday" doesn't. Both are personalised; only the second narrates the personalisation. Users register the relevance without being reminded they're being tracked. Silent relevance is the default mode for nearly every message you send.

Reference commitments the user made, not behaviour they didn't commit to. A cart-abandonment email — sent when a user adds something to their cart and leaves without buying — referencing "your cart" feels fine, because the cart is a user-initiated state. They typed "add to cart." A browse-abandonment email referencing "that item you looked at" feels less fine, because browsing is a passive thing the user didn't intend to commit to. Cart-abandonment converts harder than browse-abandonment anyway, so erring on the right side of this line rarely costs revenue.

Use the group, not the individual. "Customers who bought X often also buy Y" works as social proof. "We noticed you bought X" reads as surveillance, even though the underlying data point is identical. Framing personalisation as belonging to a group instead of an individual feels safer because it is — no individual is singled out by name.

Hand the user the dial. A preference centre — the settings page where a user tells you what they want more or less of — turns personalisation into collaboration. They know why they're seeing what they're seeing and can change it. Counterintuitively, programs with strong preference centres tolerate more data-driven content, because users have signed on to the system and know where the controls are. Our Liquid reference covers the syntax for implementing preference-aware personalisation in Braze (Liquid is the templating language most ESPs use to swap in personalised values at send time).

Narrating cross-device tracking. "We saw you looked at this on your phone yesterday and thought you might want it on your laptop too" — even if true, this reads as proof your system tracks the user across devices. Users mostly accept that tracking happens. Very few accept being told about it by name. Use the data; don't announce the data.

Re-surfacing data the user just rejected. A user deletes an item from their cart. Un-favourites a product. Navigates away deliberately. An email the next day referencing that item reads as your program ignoring the signal they sent. Rule: honour negative actions at least as much as positive ones. If a user says "no" through behaviour, your program has to hear it. Otherwise, "we weren't listening" — which is worse than not personalising at all.

Inferring a life event the user didn't volunteer. "We noticed you've been browsing wedding dresses — here are more" assumes a life context the user hasn't shared with you. If they were shopping for someone else, or the engagement ended, or the browse was idle curiosity, your email becomes memorable for the wrong reasons entirely. Any personalisation based on inferred life events needs explicit user consent and an escape hatch. Most programs should just not do it.

Teams that ship the best personalisation often use less data, not more. A clean, explicit user-preference dataset — what the user told you they wanted, in their own words, through a form — produces better targeting than a sprawling behavioural profile. Signals are reliable. Users can be shown them without embarrassment. Compliance surface stays manageable.

Most lifecycle programs over-collect and under-use. Our CRM Data Model skill covers the discipline of picking the smallest dataset that supports your personalisation strategy. You can always collect more later. Removing data already in the system is much harder, and the compliance surface — your regulatory exposure for every field you store — keeps expanding as privacy regulations tighten. Clean explicit preferences outperform sprawling behavioural datasets on almost every dimension that matters.

A useful internal test before any send: for every piece of personalisation in your email, can you show the user exactly which data produced the message, and would they be comfortable with that view? If either answer is no, reconsider. This test catches most of the decisions that create creepy moments — usually before they ship.

Sensitive contexts. Grief, medical situations, legal processes, financial distress — all contexts where personalisation reads as insensitive even when technically appropriate. A user who stops placing orders because they're going through something serious does not need a reactivation email asking what happened. Right behaviour: pause marketing sends entirely (via a quieted segment or an explicit user flag) and resume only when the user signals readiness. Knowing when to fall back to unpersonalised content, or no content at all, is the discipline.

New users. Your first few messages to a newly-acquired subscriber should lean on explicit preferences (what they opted into when they signed up) rather than inferred behaviour (what they've done in the product since). Behavioural personalisation assumes you've earned the right to reference a user's actions. First sends are where that right is still being negotiated; reference behaviour too early and the negotiation goes sideways.

Cross-audience sends. When one message goes to multiple audience tiers at once, personalisation that's fine for some users is awkward for others. A line referencing "your last purchase" lands well for a recent customer and strangely for a dormant one who forgot they ever bought anything. When audiences split, split the message. Slightly different subject line, slightly different opener — usually enough to make the send work for both cohorts. A single message optimised for neither ends up awkward for both.

Through-line across all three: the discipline isn't maximising personalisation, it's knowing when to dial it down. Teams that get this right treat "send something less personal" and "don't send at all" as first-class options in the playbook, never as failures of the system.