Everyone has received one. “Hi ,” or “I noticed {{company}} is doing interesting work” or, best of all, “Congrats on the recent .”
It is the most visible failure in cold email, and it is worse than sending nothing personalised at all. A generic email is unremarkable. A broken merge field announces that this was automated, that nobody checked, and that the personalisation was never real.
The fix is not better data. It is writing sentences that survive missing data.
The three failure modes
Empty. The field has no value and renders as nothing. “Hi ,” is the classic.
Wrong. The field has a value, but the wrong one. A company legal name where you wanted a trading name — “I’ve been following the work at Northgate Analytics Holdings Ltd” reads badly. Or a first name field containing a full name, or a title like “Dr.” in a casual greeting.
Right but nonsensical. The data is correct and the sentence still fails. “I saw you’re based in Remote” or “Congrats on 3 years at Self-Employed.”
The third is the hardest to catch because nothing is technically broken, and it is common in LinkedIn-sourced data where people write things in fields that were meant for something else.
Fallbacks that actually read
The mistake is writing a fallback that is obviously a fallback.
| Field | Bad fallback | Better |
|---|---|---|
first_name |
“there” | “Hi” alone, with no name at all |
company |
“your company” | Restructure so the sentence does not need it |
job_title |
“your role” | Drop the clause |
industry |
“your industry” | Use a category you know applies to the whole list |
recent_post |
“your recent post” | Remove the entire sentence |
“Hi there” is defensible but reads like a mailing list. “Hi,” followed by the message reads like a person typing quickly. That is a better default.
For anything more substantial than a name, the right fallback is usually to omit the sentence rather than to genericise it. “I saw your recent post about your industry” is not personalisation; it is the appearance of personalisation, which is worse.
Writing sentences that survive
Three techniques, in order of how much they help.
Put variables mid-sentence, not at the start. “Hi {{first_name}}” breaks visibly. “Hope the week’s going well, {{first_name}}” degrades into a normal sentence when the field is empty.
Make the clause optional, not structural. Compare:
“I saw that {{company}} recently {{event}}.”
Everything collapses if either field is missing.
“Most {{industry}} teams we speak to are dealing with [problem].”
One field, and a fallback of a broad category keeps the sentence intact.
Write the fallback version first. Draft the email with no variables at all, so it works as a good generic email. Then add personalisation on top. If the message only works when every field populates, you have written a template that depends on luck.
Testing before launch
Four checks, none of which take long.
Send yourself the empty version. Create a test lead with every field blank and push it through the full sequence. Read what arrives. This catches more than any amount of reviewing the template in an editor.
Send yourself the ugly version. A test lead with awkward real-world values: a company name with “Ltd” and “Holdings” in it, a first name in all caps, a title of “Self-Employed”, a location of “Remote”.
Check the fill rate before enrolling. What percentage of your list actually has each field? If recent_post populates for 12% of the list, the sentence using it should not be in the sequence at all.
Scan for unmatched braces. A typo in a variable name renders as literal text. {{firstname}} where the field is first_name sends exactly that, visibly.
A sensible rule: no variable in a sequence without a fallback, and no exceptions. If a field cannot be given a sensible fallback, the sentence containing it should be removed rather than shipped hopefully.
The fill rate question
This is the decision most people get wrong.
If a field populates for 90% of your list, use it. If it populates for 30%, do not — not even with a fallback, because you are writing a sequence where seven in ten people get the degraded version and the whole structure was built around a sentence they will not see.
Better to segment. Run the personalised sequence on the 30% who have the data and a different sequence on the rest, written for what you do know about them. Two clean sequences beat one that limps for most recipients.
This applies especially to signal-based fields — a recent post, a job change, a hiring event. Those populate for a subset by definition, and building a general sequence around them is a mistake.
AI does not remove the problem
Worth saying, because it is a common assumption.
AI-generated openers are still working from fields. If the input data is missing or wrong, the model will either produce something generic or, less helpfully, invent a plausible detail. The second is considerably worse than an empty merge field, because a confidently wrong specific claim reads as either careless or dishonest.
If you use AI personalisation, check what it produces when the source data is thin. Some systems degrade gracefully; some fabricate.
The short version
A broken merge field is worse than no personalisation because it advertises the automation and the lack of checking.
Write the email so it works with no variables at all, then add personalisation on top. Put variables mid-sentence, make personalised clauses optional rather than structural, and give every variable a fallback — or remove the sentence.
Test with an empty lead and an ugly lead before launching. Check fill rate before committing to a field, and segment rather than limping if it populates for under half your list.
Next: personalising at scale, or the 40-point audit checklist.
Frequently asked questions
What is a merge field fallback?
The default value used when a personalisation variable has no data. Without one, the field renders as nothing, producing visible errors like “Hi ,” at scale.
How do you avoid personalization errors in cold email?
Write the message so it reads well with no variables, place variables mid-sentence rather than at the start, give every variable a fallback, and test with a deliberately empty lead record before launching.
What fill rate justifies using a personalization field?
Around 90% or above. Below roughly half, segment instead — run the personalised sequence on the records that have the data and a different sequence on the rest.
Does AI personalization avoid merge field problems?
No. AI openers still work from the underlying data, and thin inputs produce either generic output or invented details. A confidently wrong specific claim is worse than a blank field.