Email merge tag fallbacks, stop shipping 'Hi ,' to your list
Every email marketer has sent the dreaded 'Hi , welcome back!' with an empty first name. Merge tag fallbacks prevent it. Here's how they work across ESPs and how to design for missing data.
You've seen it in your own inbox. Maybe you've even sent it: "Hi , thanks for being a customer." The two spaces where a first name should be. It's the calling card of a marketer who set up personalization without testing the empty-data path.
Fix it once with merge tag fallbacks and never ship an awkwardly empty greeting again.
What a fallback is
A merge tag fallback is a default value that gets rendered when the variable it's replacing is empty, null, or undefined. Instead of:
Hi {{first_name}},You write:
Hi {{first_name|friend}},If first_name is populated, recipients see "Hi Alex,". If it's empty, they see "Hi friend,", a graceful fallback that doesn't break the sentence.
Why it's required, not optional
1. Your list is dirtier than you think. Even lists with a 95% fill rate on first_name have 5% blanks, often your newest subscribers, who came in via a lightweight opt-in. That 5% gets your worst first impression.
2. Imported lists have unpredictable casing and whitespace. A CSV import with a column header of First Name (space, uppercase) mapped to a variable named first_name produces blanks for every row. Fallbacks save you.
3. Array and object fields have nested fallback needs. If you're rendering the top item from an array like {{orders.0.product_name}}, what happens when orders is empty? Without a fallback, your email renders the literal tag: "Your recent order of {{orders.0.product_name}} has shipped!"
Fallback syntax across ESPs
Syntax varies, here's a cheat sheet for the top ESPs as of 2026:
- Mailchimp:
*|FNAME:friend|*(yes, asterisks and pipes). You can also use*|IF:FNAME|* ... *|ELSE:|* ... *|END:IF|*for conditional blocks. - Klaviyo:
{{ first_name|default:'friend' }}(Django-style filter syntax). - HubSpot:
{{ contact.firstname | default:"friend" }}(also Django-style). - SendGrid / Twilio:
{{firstName | default('friend')}}(Handlebars with a default helper). - Customer.io:
{{customer.first_name | default: 'friend'}}. - Draftship:
{{first_name|friend}}, compact pipe syntax, no quotes needed.
If you're working across multiple ESPs, standardize on one internal convention and translate at export time. Mixing syntaxes in the same campaign is a debugging nightmare.
Designing copy that survives missing data
Fallbacks protect against empty fields, but copy design protects against awkward-but-valid fields:
Don't assume capitalization. Someone enters their name as "jack" or "JACK". Your copy says "Hey, {{first_name}}! How's it going?" and ships "Hey, jack!" Use a lowercase-then-capitalize filter if your ESP supports it, or accept the casing variance as part of the deal.
Don't assume length. Names can be 30+ characters. "Alexandra-Constantinopoulos-Hatzidakis" blows up button labels. Design with a 20-character budget in mind.
Don't assume Latin alphabet. Names in non-Latin scripts (Chinese, Arabic, Japanese) look fine on their own but may break layouts tuned for Latin letter widths.
Don't assume data is safe to render. Someone enters <script>alert(1)</script> as their first name. Your ESP should escape it, but test. Many older ESPs don't escape merge tag output by default.
Stress-testing merge tags before send
The golden move: render your email with adversarial recipient data before every send.
Draftship's stress-test preview mode automatically injects 40-character variable values so you can see where your design breaks. Without that tool, you can fake it:
1. Add a test recipient with every field set to a 40-character string. 2. Add another with every field empty. 3. Render the preview with both. Fix anything that looks broken.
If your ESP doesn't support test recipients with custom data, create a preview URL that accepts query-string overrides. Most modern ESPs have this, Mailchimp calls it "preview mode with merge tags", Klaviyo calls it "profile preview".
Quick reference: which fallbacks matter most
Always provide a fallback for:
- First name in greeting ("Hi {{first_name|there}}")
- Company name in B2B ("Your team at {{company|your company}}")
- Any number with a currency symbol ("{amount|0{'}'}")
- Array first-item references ({{items.0.name|an item from your order}})
Optional fallback for:
- Last name (usually not in the greeting)
- Internal IDs (shouldn't be rendered anyway)
- Segment-only fields (only exposed to specific audiences)
TL;DR
- Merge tag fallbacks prevent "Hi ," by giving every variable a default.
- Syntax varies by ESP: pipe, filter, or double-brace conditional.
- Design copy that tolerates missing, long, and non-Latin names.
- Stress-test with adversarial data before every send.
- Draftship's
{{name|friend}}syntax is the shortest common denominator.