When personalisation feels broken, the instinct is to rewrite the copy. It is almost never the copy. It is the profile the copy was assembled from.
A message that says the wrong thing to the wrong person is usually described as a content problem. In practice the content is doing exactly what it was told — resolving against a profile that is stale, partial, or merged with somebody else. The rewrite fixes the symptom and the next campaign has the same problem.
We are asked to improve lifecycle programs regularly, and the most common finding is not a missing journey. It is that the data feeding the journeys is not trustworthy enough to build on.
One person exists as several records: an anonymous visitor, an email subscriber, a purchaser with a different address, a support contact, a mobile app user. Whether those merge into one profile — and when — determines whether your personalisation is real or coincidental.
When resolution fails, the symptom is a message that treats a loyal customer as a stranger, or worse, treats a stranger as somebody with a purchase history. Both destroy trust faster than a bad offer does, because they demonstrate that you do not know who you are talking to.
Events arrive with inconsistent names and inconsistent payloads: three ways of saying someone viewed a product, two naming conventions for the same category, timestamps in different zones. Every consumer of that data then writes its own interpretation, and the interpretations disagree.
The fix is unglamorous and disproportionately valuable: a written, versioned event schema with a documented contract, and a rule that nothing enters the pipeline without conforming to it. Teams resist this because it slows down the first integration. It is the reason the twentieth integration takes a day instead of a fortnight.
A preference captured at signup is treated as current forever. A lifecycle stage is computed once and never recomputed. An engagement score is written but never decayed. Each of these produces a program that personalises using a snapshot of a person who has since changed.
Personalisation is not a copywriting technique. It is a claim about what you know, and it is only as good as your least-maintained field.
Take twenty recipients at random — real people, not test profiles. For each, open their profile and try to answer: how many events do they have, what is their lifecycle stage, when was each key property last written, and is the profile merged with anyone else's?
If you cannot answer those questions quickly and confidently for twenty people, you have found the reason your personalisation is inconsistent. It is not the copy.
Data quality is usually filed under engineering, which is precisely why it stays broken. Engineers can implement a schema; they cannot decide which events matter commercially, what "active" means for this business, or which customer states deserve different treatment. Those are marketing decisions that happen to be expressed as data.
The teams that get this right treat the data model as a product surface. It has an owner. It has documentation. Changes to it are reviewed by whoever owns the customer experience, because a schema change is a change to every message that resolves against it.
Start with the events your journeys depend on — usually between five and fifteen of them — and make those trustworthy before adding anything new. Get the names consistent, the payloads documented, the timestamps normalised, and the profiles recomputed on a schedule.
That work is invisible in a dashboard and it is the difference between a program that personalises and one that merely claims to. Every other improvement you want to make sits on top of it.
Written by the team at LMR — a senior lifecycle marketing studio working in Iterable, Braze, Klaviyo and the tools you already run.
Start a project ↗