Merge tags in cold email are placeholders that your sending tool replaces with each prospect’s data at send time: a first-name tag renders as Sarah, a company tag renders as Acme, and one template becomes a thousand filled-in emails. The mechanics are the whole subject of this article: what the tags are, the three ways they break in real campaigns, the fallback syntax that saves a send when the data is missing, and the honest ceiling on what a filled-in template can earn. The neighboring questions are owned elsewhere: variant syntax that randomizes wording lives in our verdict on spintax in cold email, and the strategy of what to personalize and why lives in our guide to personalization at scale. This piece is about the plumbing, because the plumbing is where campaigns visibly fail.
The mechanics here come from send volume, not theory. Our parent agency, Referral Program Pros, has run more than 4,000 outbound campaigns and booked over 7,000 meetings, and GTM Bud turns that playbook into software under a written guarantee: 5 percent positive replies on LinkedIn, 1.5 percent on email, or a full refund. Across those campaigns, merge tags were never the thing that won a reply, but a broken one was regularly the thing that lost it, which is why every rule in this article is about preventing the visible failure first and knowing the format’s limits second.
What are merge tags in cold email and how do they work?
A merge tag is a named placeholder in an email template that the sending platform swaps for the matching value in each recipient’s contact record at send time. The tag name must match a field in your data, usually a column header in the CSV you imported, and the platform performs the lookup per recipient: tag name in, column value out, one personalized render per send. The syntax varies by platform. Zapier’s explainer on Mailchimp merge tags shows Mailchimp wrapping tags in asterisks and pipes, while most cold email tools use single or double curly braces around a field name, and Microsoft-lineage tools call the same thing a merge field. What never varies is the dependency: the tag is only as good as the column behind it, which is why every merge tag failure in this article is really a data failure wearing template clothing.
Here is the shape most cold email tools use:
Hi {{first_name}},
Quick question about how {{company}} handles outbound.Two tags, two lookups per recipient, and two separate ways for this four-line email to embarrass you, which the next section walks through.
How do merge tags break, and what does the prospect see?
Merge tags break in three distinct ways, and each one shows the prospect something different. The blank tag renders nothing, the raw tag renders the placeholder itself, and the wrong fill renders data that was never meant for that sentence.
The blank tag. The tag resolves, but the field is empty, so the prospect reads “Hi ,” with a floating comma where their name should be. This is the missing-data failure, and it is common enough that sending platforms build tooling around it: SmartReach, a cold email vendor, documents in its help center that it blocks sending to any prospect whose record lacks a field the template references, and lists the affected rows under a missing merge tags error for you to fill in or fallback.
The raw tag. The tag does not resolve at all, so the prospect reads the literal placeholder: “Hi {{first_name}},” sitting in their inbox as plain text. GMass, a Gmail mail merge vendor, catalogs the causes in its posts on wrong mail merge tags and failed personalization: a tag name that does not match the column header, a typo inside the tag, a stray space next to the braces, or an old template loaded against a new spreadsheet whose columns are named differently. GMass warns senders when tags and columns do not match, which tells you how often they do not.
The wrong fill. The tag resolves cleanly and the data is wrong: a first-name column holding company names renders “Hi Acme,” a scraped name field in capitals renders “Hi JOHN,” and a company field holding the full legal entity renders “I saw Acme Corporation Holdings LLC is growing.” Nothing errored, and the email still announces that a machine filled a form. This is the failure that upstream list work prevents, which is why cold email list segmentation and field cleanup matter more to merge output than anything in the template editor.
| Failure mode | What the prospect sees | Root cause | The fix |
|---|---|---|---|
| Blank tag | “Hi ,” with a floating comma | Empty field in the contact record | Fill the field, set a fallback, or let the tool block it |
| Raw tag | The literal placeholder as plain text | Tag name, typo, or spacing mismatch with the column | Match tag names to headers exactly; test the worst row |
| Wrong fill | “Hi Acme,” or “Hi JOHN,” | Shifted columns, scraped casing, legal suffixes | Clean and normalize fields at import, before templating |
The three failures are not equally expensive. A raw tag in the subject line is the worst outcome available, because it is visible before the open and reads as proof that the sender never looked at the message. The blank and the wrong fill at least require the prospect to open the email before writing you off.
Do fallback values fix broken merge tags?
A fallback value fixes exactly one of the three failures: the blank tag. A fallback is alternate text the platform renders when the field is empty, declared inside the tag itself, and it turns “Hi ,” into “Hi there,” which a human might plausibly have typed. The syntax is platform-specific. GMass uses a pipe inside the braces, so {first|there} renders the first name when present and the word there when not. Liquid-template platforms like Encharge document a filter form, {{ person.firstName | default: "there" }}, and some tools use a comma separator or a settings-level default instead, so the only universal rule is to check your tool’s documentation and then send yourself a test from a row with the field deliberately blank. What a fallback cannot do is fix a raw tag, because an unrecognized tag never triggers the fallback logic, and it cannot fix a wrong fill, because the field is not empty, just wrong.
Two design rules keep fallbacks from becoming their own failure:
- Write fallbacks that survive the sentence. The fallback renders inside your copy, so read the whole sentence with it in place. “Hi there” survives. “Quick question about how your company handles outbound” survives, barely, and only because it degrades to a generic email rather than a broken one.
- Give some tags no fallback on purpose. A greeting can degrade gracefully; a mid-pitch company reference cannot, because “I noticed your company just raised a round” with a fallback in it is a sentence that was never true for anyone. For required tags, the better behavior is the SmartReach one: block the send, surface the row, fix the data. A fallback that papers over a missing field you actually needed is a template telling you the prospect should not be in the campaign yet.
Which hygiene habits prevent merge tag failures?
Every merge tag failure in the last two sections is preventable before the campaign starts, and the prevention is list discipline rather than template cleverness. The habits that survived 4,000+ campaigns at our agency are short:
- Match names exactly, once. Pick one naming convention for columns and tags, keep it across every list and every template, and never retype a tag by hand when the tool can insert it. GMass observes that subject-line tags often get typed manually because insert buttons only reach the body, and hand-typed tags are where typos live.
- Audit the edges of the list, not the middle. Sort each merged column and read the top and bottom rows. Blanks, capitals, titles in name fields, and legal suffixes all cluster at the edges of sorted data.
- Normalize at import. Proper-case the names, strip the suffixes, shorten legal entities to the name humans use. The template cannot fix what the list got wrong.
- Test-send from the worst row. Not row one. The row with the most blanks and the ugliest casing is the render that some real prospect will receive.
- Re-check tags when the list changes. The template that worked against last month’s spreadsheet breaks against this month’s if one column header moved, which GMass names as a classic cause of raw-tag sends.
None of this is glamorous, and all of it is faster than the apology email. The honest framing is a trade-off: ten minutes of list hygiene against the percentage of your list that silently receives a broken send.
Why does a filled-in template still read as a template?
Because the prospect is not reacting to whether their name is present, they are reacting to whether the email could have been sent to anyone else, and a token-filled template fails that test with every tag rendered perfectly. A first name and a company name prove the sender owns a spreadsheet, not that the sender understands the prospect, and after years of token-filled outreach, inboxes have trained recipients to read “Hi Sarah, I saw Acme is growing” as automation in a personalization costume.
The most quotable number on this comes from Prospeo, a contact data vendor, in its guide to AI cold email personalization mistakes. It reports a split result: openers built from company-name and industry tokens pulled roughly a 1 percent reply rate, while openers built on a real trigger, a hiring signal or a tech stack change, pulled 9 percent with the same sender and offer. Quote it with its weight class attached: Prospeo published no sample size or test design, so this is one practitioner’s result from a vendor with a product to sell, not a benchmark. But the direction matches what the strategy side of this topic documents at length, and the three-level framework behind that direction is laid out in our guide to personalization at scale.
| Dimension | Merge-tag personalization | Research-based personalization |
|---|---|---|
| What varies per send | Name, company, title tokens | The actual observation the email is built on |
| What it proves | You have a spreadsheet | You looked at this prospect specifically |
| Failure mode | Blank, raw, or wrong-filled tags | A wrong or hallucinated fact, which is why review matters |
| Published evidence | Prospeo reports about 1 percent replies on token openers | Prospeo reports 9 percent on trigger-based openers, same caveats |
| Right job | Logistics: greeting, signature, scheduling | Relevance: the first line and the reason for writing |
The table is not an argument for deleting your tags. It is an argument for demoting them. Merge tags still do honest work in the frame of the email, the greeting, the signature, the meeting link, because those are logistics and logistics should be automated. What a tag can no longer do is carry the part of the email that answers why you, why now.
Where research-based writing replaces token swapping
The replacement for a token opener is a researched one: a first line built from something true and specific about this prospect, written fresh rather than filled in. Doing that manually does not scale past a few dozen sends a day, which is exactly the gap GTM Bud was built to close. Its AI cold email writer researches each prospect before writing, pulling from their LinkedIn activity, company news, and hiring signals, and then generates the message from those facts, so the opener varies because the research varies, not because a synonym wheel or a token table shuffled it. The full pipeline, from research to draft to the guardrails against hallucinated facts, is documented in our breakdown of how an AI cold email writer works.
The division of labor that falls out of this article is clean. Tags handle the frame, research handles the hook, and fallbacks handle the rows where the frame data is missing. A campaign built that way has nothing left for a merge tag to ruin, because the only tags remaining are the ones that degrade gracefully.
Frequently asked questions about merge tags in cold email
What is the difference between a merge tag, a merge field, and a personalization token?
They are the same mechanism under different vendor names: a placeholder the sending tool replaces with the matching field from your contact data. Mailchimp says merge tags, HubSpot says personalization tokens, Microsoft Word mail merge says merge fields, and cold email tools use all three plus custom variables. Syntax differs, with asterisk-pipe wrappers, single braces, or double braces by platform, but the lookup logic is identical everywhere: tag name in, column value out.
Do merge tags hurt cold email deliverability?
Not directly. Tags resolve before the message leaves your mailbox, so filters only ever see finished text, and no provider documents a penalty for mail-merged content as such. The indirect risk is the pattern: token-filled templates are near-identical across hundreds of sends, and clustered low-engagement mail is what providers actually score, the same behavioral territory covered in our verdict on spintax in cold email. The direct cost of a broken tag lands on replies, not placement.
Should you use merge tags in cold email subject lines?
Only with extra caution, because the subject line is where errors are most visible and, in some tools, most likely. GMass notes its one-click insert buttons only reach the body, so subject tags get typed or pasted by hand, which is where typos and stray spaces creep in. A broken body tag is discovered after the open; a broken subject tag is why the open never happens.
What is a good fallback value for a first name merge tag?
One that survives being read aloud in the full sentence. For a greeting, the word there works because “Hi there” is something a person actually writes, and GMass suggests the same shape with its pipe fallback syntax. Read every rendered sentence with the fallback in place, and give no fallback at all to tags the pitch depends on, because a generic stand-in for a company name reads worse than a blocked send.
How do you test merge tags before launching a campaign?
Test against your worst rows, not your best. Sort the list by each merged column, read the top and bottom rows where blanks and ugly casing cluster, and send yourself a render from the emptiest row, not row one. A cold email automation tool that validates fields before sending and blocks the rows that fail turns this ritual into a default.
Keep the tags for logistics, earn the reply with research
The merge tag decision is a trade-off between automation you need and automation you show. Tags earn their place in the frame of a cold email, the greeting, the signature, the scheduling line, where they fail loudly enough to be caught by hygiene: exact name matching, edge-of-list audits, worst-row test sends, and fallbacks only where the sentence survives them. They lose their place in the part of the email that does the persuading, because a filled-in token proves spreadsheet ownership, and the one published split result on the question, Prospeo’s 1 percent against 9, points the same direction as every campaign we have run: the reply follows the research, not the render.
GTM Bud is built on that division. Its cold email automation tool handles the frame, the sending discipline, and the field validation, while the research layer writes each opener from facts specific to the one prospect reading it, the same system behind our agency’s 4,000+ campaigns and 7,000+ booked meetings, under the same written guarantee: 5 percent positive replies on LinkedIn, 1.5 percent on email, or a full refund. Fill the frame with tags. Earn the first line. The floating commas disappear on their own.