Personalisation that doesn't feel creepy

Specificity that implies surveillance. A user who browsed a product page once and then opened their email to a message saying "We noticed you were looking at the navy jacket" gets an instant discomfort reaction — not because the data is wrong, but because the phrasing makes the observation explicit. The same data point delivered as a product recommendation in a digest feels fine. One reads as being watched; the other reads as being served.

The rule most teams miss: the creepy line isn't about what you know, it's about how you signal what you know. A marketing team showing off their data infrastructure in the copy is the fastest way to trip the reaction. A team using the same data silently to improve relevance is usually fine.

This is a voice and copy discipline more than a data one. You can have every user's complete behavioural history and never trigger the reaction, if your copy treats the data as invisible context rather than a headline.

Relevance without reference. "Here are jackets we think you'll like" works; "Based on the jacket you viewed on Tuesday" doesn't. The recommendation is personalised, but the copy doesn't narrate the personalisation. Users register the relevance without being reminded that they're being tracked.

Recent product activity as context, not subject. A cart-abandonment email referencing "your cart" feels fine because the cart is a user-initiated state the user created. A browse-abandonment email referencing "that item you looked at" feels less fine because browsing isn't an action the user chose to take. Commitment the user made → fair game. Passive behaviour the user didn't commit to → danger zone.

Aggregate patterns framed as trends. "Customers who bought X often also buy Y" works as social proof. "We noticed you bought X" reads as surveillance even though it's the same underlying data point. Framing the personalisation as belonging to a group instead of the individual feels safer because it is — the individual isn't singled out by name.

Transparent, user-controlled settings. A preference centre that lets users say "show me more running gear" turns personalisation into a collaboration. The user knows why they're seeing what they're seeing, and can change it. Counterintuitively, programs with strong preference centres often have higher tolerance for data-driven content because the user has signed on to the system. The Liquid reference covers the syntax for implementing this kind of preference-aware personalisation in Braze specifically.

Cross-device narration. "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 the system tracks users across devices. Users mostly accept that tracking happens; very few accept being told about it by name.

Re-surfacing abandoned data. A user deletes an item from their cart, or un-favourites a product, or navigates away deliberately. An email the next day referencing that item reads as ignoring the signal the user sent. The rule: honour negative actions at least as much as positive ones. If the user said "no" through behaviour, the lifecycle program has to hear it.

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

The teams that ship the best personalisation often use less data, not more. A clean, explicit user-preference dataset produces better targeting than a sprawling behavioural profile, because the signals are reliable and the user can be shown them without embarrassment.

Most lifecycle programs over-collect and under-use their data. The CRM Data Model skillcovers the discipline of picking the smallest dataset that supports your personalisation strategy. You can always collect more; removing data that's already in the system is much harder, and the compliance surface of unused data keeps expanding as regulations tighten.

A useful internal test: for every piece of personalisation in your program, can you show the user exactly which data produced the message, and would they be comfortable with that view? If the answer to either is no, reconsider. The test catches most of the lines that create creepy moments.

Sensitive contexts. Grief, medical situations, legal processes, and financial distress are 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. The right behaviour is to pause marketing sends entirely — possible via quieted segments or explicit user flags — and resume only when the user signals readiness.

New users. The first few messages to a newly-acquired subscriber should lean on explicit preferences (what they opted into) rather than inferred behaviour (what they've done in the product). Behavioural personalisation assumes you've earned the right to reference their actions; the first few messages are where that right is being negotiated.

Cross-audience sends. When a single message goes to multiple audience tiers simultaneously, personalisation that's fine for some users is awkward for others. A message that references "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.