What are merge fields?

How rendering actually works

Your lead list is a table; each merge field names a column. At send time the sequencer takes the template, looks up the row for the recipient, and substitutes each token with that row's value: Hi {{first_name}}, saw {{company}} is hiring SDRs becomes "Hi Dana, saw Northwind is hiring SDRs". Syntax varies by tool - double braces are the most common; percent signs and square brackets also exist - but the mechanics are identical everywhere: the template is only as good as the row.

The four failure modes prospects actually see

• The blank. "Hi , quick question" - the field resolved against an empty cell. The message does not read as unpersonalized; it reads as a broken machine, which is worse than no personalization at all.
• The raw token. "Hi {{first_name}}" arriving unrendered - a typo in the field name, a mismatched column header, or syntax from the wrong tool. One of these in a thousand sends is the one that gets screenshotted.
• The wrong-shape value. ALL-CAPS surnames, "Dana Smith" in a first-name field, legal suffixes in the company field - "saw Northwind Traders LLC is hiring" - or a value that is simply wrong for the person. The data was present and the render succeeded; the row was dirty.
• The impossible sentence. A template written so that certain legitimate values break its grammar: "a {{company}} company like yours" produces "a Acme company like yours". The failure is in the copy, and it fires only for some rows - which is why it survives casual testing.

The discipline that prevents them

Audit coverage before the send, not after. For every field the template uses, check what share of rows actually carry a clean value. A first-name field at 99.6% coverage is usable; at 91% it will greet dozens of prospects with a blank. Coverage discipline also matters upstream: sequencers commonly refuse or mishandle rows with missing required fields, so one nameless row can hold up an entire import. Field hygiene is part of list building, not an afterthought at the template stage.

Set fallbacks, and write them to survive. Most tools support a default - {{first_name|there}} - so an empty cell renders "Hi there" instead of "Hi ,". A fallback is damage control, not personalization: if a field's coverage is low enough that the fallback fires often, drop the field and write copy that does not need it.

Test against real rows, including the ugly ones. Render the template against the actual list - the rows with missing values, hyphenated names, long legal company names - not just the first row or a hand-typed sample. And test every variant in the sequence, not only the primary: the follow-up that nobody proofread is still mail your prospect receives.

Normalize before importing. Proper-case names, strip legal suffixes, resolve "Dana Smith" into its parts, and standardise values the copy will inline. Every one of these is cheap in a spreadsheet and unfixable after the send.

Merge fields are not personalization

A rendered first name proves you have a database, not that you did any thinking. Real personalization is an opening line grounded in something true and current about the recipient - and merge fields' honest role is mechanical support for that, inserting the verified specifics your research found. Tokens shuffle your words; spintax is the same idea pointed at the sender's text, and neither adds relevance on its own. The copywriting rules we score against treat unsupported personalization theatre exactly as recipients do: as noise. Our cold email grader, incidentally, masks merge fields before scoring - so {{first_name}} in a draft is handled correctly rather than tripping the checks.

Common questions

What is the difference between merge fields and merge tags?

Naming only. Merge tags, merge fields, custom variables, personalization tokens and liquid variables all describe the same substitution mechanic; the syntax differs by tool, the discipline does not.

What happens if a merge field is empty?

Without a fallback, the token renders as nothing and the surrounding sentence collapses - "Hi ,". With a fallback, the default renders instead. Either way the root cause is a coverage gap in the list, and the durable fix is there.

How do you test merge fields before sending?

Render against the real list, sorted to surface the worst rows: empty cells, unusual names, long company names. Read every sequence variant, not just the first touch. Five minutes of this catches essentially all four failure modes.

Do merge fields improve reply rates?

Correct rendering is table stakes rather than a lever - it prevents the automation tells that kill replies. The lever is what the fields carry: verified, specific, current data in copy built around it.