Personalization in Email Copy: Beyond First Name Tokens
Personalisation that changes the message rather than the greeting, and the merge-tag failure that makes it obvious.
On this page
The short version
- A first name in a greeting is not personalisation, it is a merge tag. It has been common long enough that most readers register it as automation.
- Useful personalisation changes what the email says, not who it is addressed to — and that requires data you collected on purpose.
- Every merge tag needs a fallback that reads as a deliberate sentence, because the data will be missing more often than you expect.
Personalisation in email has come to mean inserting a name. That was novel once and is now near-universal, which means it no longer signals attention — it signals that a mail-merge is running, which is what it always was.
The version that still works changes the substance: which paragraph appears, which example is used, which offer is made. That requires knowing something worth acting on, which is why most personalisation projects are really data collection projects.
Level two is where most of the return is
Writing a different email for each segment sounds like more work than conditional blocks, and for two or three segments it is usually less. There is no template logic to debug, no rendering surprises, and each email can be written as a whole rather than assembled from fragments that have to make sense in every combination.
Conditional blocks earn their complexity when the number of variants multiplies — three attributes with two states each is eight versions, and writing eight whole emails is not sensible. Below that threshold, separate sends are usually faster and always easier to check.
What each level needs and what it costs
| Level | Data required | Build cost | Typical effect |
|---|---|---|---|
| Merge tag | A name field | Minutes | Marginal, and falling |
| Segment copy | Any segment you already have | One email per segment | Substantial |
| Conditional blocks | A reliable attribute per contact | Template logic plus QA | Substantial, at scale |
| Derived content | Behavioural or account data, live | Integration work | Large where it applies |
The second row is the one most programmes should exhaust before touching the third. It needs no new data and no new tooling.
The fallback problem
Every merge tag will be empty for some proportion of the list — imports, form variations, people who typed a single character, contacts created by integrations that never asked. When it is empty, the email prints whatever you set as the fallback, and the default fallback in most platforms is an empty string.
That produces the visible failures everyone has received: "Hi ," with the comma marooned, or "Thanks for your interest in ,". The fix is a fallback that makes a complete sentence, and the discipline is to write the fallback version first and treat the personalised one as the variant.
Personalisation that reveals surveillance
There is a line where personalisation stops feeling attentive and starts feeling monitored, and it is crossed by referencing behaviour the reader did not know you could see. Referring to a purchase is expected. Referring to how long someone spent on a page is not.
A workable rule: use data the reader knowingly gave you, or actions they knowingly took with you. Everything derived from passive observation can inform which email you send without being mentioned in it.
Before shipping a personalised send
- Every merge tag has a fallback that forms a complete sentence
- The fallback version has been read end to end as a whole email
- Name values are trimmed, and values containing an at sign are rejected
- Casing is left as the subscriber typed it
- Conditional blocks have been previewed in every combination, not just the common one
- Nothing in the copy references behaviour the reader did not knowingly share
- A test has been sent to a contact with every optional field empty
Frequently asked questions
Does putting the first name in the subject line still work?
It produces a small open-rate lift on many lists and is common enough to be recognised as automation by many readers. Test it on your own list rather than adopting it as a default, and never use it on a list where the name data is unreliable.
How do I collect data for level three without adding form fields?
Progressive profiling — ask one question in an early email, store the reply, use it later. A single well-chosen question in a welcome sequence usually gets a better response rate than the same question added to the signup form.
What is the most common personalisation bug in production?
An empty fallback, followed closely by a conditional block that renders nothing for a combination nobody tested — producing an email with a paragraph missing and no visible error anywhere.