Everyone has received it. “Hi {{first_name}},” or worse, “I saw that is hiring for roles.” The recipient does not read that as a small technical fault. They read it as proof that the message was machine-generated and that nobody checked, which is exactly the conclusion you spent the whole email trying to avoid.
A blank merge field is worse than no personalization, because a generic email is merely unremarkable while a broken one is evidence.
Why signal variables break more than name fields do
A first name is present on almost every record. Signal data is not, and that is inherent to how it arrives rather than a data-quality failing.
| Variable | Typically populated | Why it goes missing |
|---|---|---|
| First name | Almost always | Occasional single-name or initial-only records |
| Company | Almost always | Legal name against trading name mismatches |
| Job title | Usually | Not public, or so long it will not fit a sentence |
| New company (job change) | Often | Move announced before the new employer is listed |
| Job posting title | Sometimes | Posting closed or reworded between the watch firing and the send |
| Post text (engagement) | Sometimes | Post deleted, edited, or too long to quote |
Notice the pattern in the last three rows: signals are events, and events change after they fire. The watch was accurate on Tuesday and the posting was pulled on Wednesday. Your sequence sends on Thursday.
The rule: no signal variable without a fallback
In Signals the editor will not save a signal variable that has no fallback. That looks pedantic for about a day, and then it saves you from the send where 200 of 2,000 messages went out with a hole in the second sentence.
The important part is what makes a good fallback. It is not a placeholder word. It is a shorter version of the same sentence that reads naturally when substituted.
Bad: “I saw {{company}} is hiring for {{job_title}} roles” with fallbacks “your company” and “new”. Produces: “I saw your company is hiring for new roles”, grammatical, meaningless, and obviously a template.
Good: two variants of the sentence, one for each state. Full: “I saw {{company}} is hiring two {{job_title}}s this quarter.” Fallback: “I saw you are adding to the sales team this quarter.” Both are specific enough to justify the email, and the reader cannot tell which one they got.
Four rules that prevent most incidents
- Never let a variable start a sentence. A missing value at the start of a line is the most visible failure mode there is, and no fallback rescues it fully.
- One signal variable per message. Two variables mean two chances to fail and a sentence that reads like a mail merge even when both resolve.
- Keep quoted text out. Quoting a prospect’s post is the highest-risk variable in outbound: it can be deleted, edited, or 400 words long. Reference the topic, do not quote the text.
- Preview the fallback path, not the happy path. Most teams preview three records where everything resolves. Preview the ones where it does not, that is the version some of your audience will receive.
The pre-send check that takes two minutes
Before any signal-driven sequence goes live: sort the enrolled list by whichever signal variable you are using, look at the records where it is empty, and read the message as those people will get it. If a sentence reads as broken, either rewrite the fallback or drop those records from this sequence and put them into a version that does not need the variable.
Then set the standing rule: a signal older than its decay window does not send at all. A hiring reference is not just unpersuasive four months later, it is wrong, and being wrong about something checkable costs more than being generic. Decay windows per signal type are here.
Next: the 90-day job-change window, signal to enrolled, end to end, or personalization that scales without breaking.
Frequently asked questions
What is a merge field fallback?
A value used when the variable is empty. A good fallback is a shorter version of the same sentence that reads naturally on substitution, not a placeholder word like “your company” dropped into a sentence built for a real name.
Why do signal merge fields fail more often than names?
Because signals are events and events change after they fire. A job posting can be pulled, a post edited or deleted, and a job move announced before the new employer is listed, all between the watch firing and the send.
Is a blank merge field really that damaging?
Yes. A generic email is unremarkable; a broken one is evidence that the message was machine-generated and unchecked, which undermines the entire premise of the outreach.
How many merge variables should one cold email have?
One signal variable. Two means two chances to fail and a sentence that reads like a mail merge even when everything resolves correctly.
Should I quote a prospect’s LinkedIn post in an email?
Avoid it. Quoted post text is the highest-risk variable in outbound because the post can be deleted, edited or far too long. Reference the topic instead of quoting the words.