Merge tags are supposed to make a message feel written for one person. Used badly, they do the opposite. The single most recognizable sign of automated outreach is not a typo or a bad pitch, it is the message that opens “Hi {first_name},” with the token sitting there unrendered because the field was empty.

The tags themselves are fine. The craft is in what you put in them, what you fall back to when the data is missing, and knowing when one more token stops helping and starts reading as a database query. Here is how to use them without the cringe.

The fallback is the whole game

Every merge tag will be empty for some fraction of your list. Names are missing, companies are blank, headlines are nonsense. The question is never “what does this look like when the data is there,” it is “what does this look like when it is not.”

A good token always carries a fallback that reads naturally on its own:

“Hi {{first_name|there}},” renders as “Hi Sarah,” when the name exists and “Hi there,” when it does not. Both are fine. Neither exposes the machinery.

Write the fallback first, then the personalized version. If the fallback sentence does not stand on its own as a message you would send, the whole line is fragile.

Tags that help, tags that hurt

Some fields personalize. Others just prove you scraped a profile.

First name: almost always helps. It is the one piece of personalization everyone accepts, as long as you handle the empty case.
Company: helps in the body, rarely in the opener. “teams at {{company}}” can work mid-message. “I see you work at {{company}}” as a first line announces the merge.
Title or role: handle with care. Job titles are inconsistent and often stale. “As a {{title}}” breaks the moment the title is “Founder, ex-Google, advisor, dad.”
Anything scraped and quoted back verbatim: usually hurts. Reciting someone’s exact tagline at them is the uncanny valley of personalization. It is accurate and it is creepy.

The uncanny valley of over-personalization

There is a point where adding more tokens stops making the message feel human and starts making it feel surveilled. A message that references your name, your company, your last three job titles, the city you are in, and the conference you attended does not read as thoughtful. It reads as a script with a good data source.

One specific, genuinely relevant detail beats five generic merged ones. The goal is not to prove you have data about the person. It is to sound like someone who paid attention to one thing.

Test your fallbacks against real-world mess

The data is always messier than the template assumes. Before a send, check the edges:

Empty fields. Every token, rendered with the value missing. This is the one that ships broken most often.
All-caps and lowercase names. “Hi JOHN,” and “hi sarah,” both look automated. Normalize casing.
Legal suffixes on company names. “teams at Acme, Inc.” and “teams at Acme LLC” read as pulled straight from a registry. Strip them.
First name that is actually a full name. Some records put “Sarah Chen” in the first-name field. “Hi Sarah Chen,” is a tell.

What Marno does

Marno’s personalization uses a {{first_name|fallback}} syntax where the fallback is required, not optional, so a token can never render empty in a live message. The editor only accepts known tokens, so a typo’d {{frist_name}} is caught before it sends rather than shipped as literal text. And every step shows a live preview against real lead data, including the missing-field case, so you see the fallback version before a single message goes out. Personalization that you can actually trust at scale.