Email Merge Tags: What They Are and How They Work Across ESPs
Every email tool spells “first name” differently
Open the same welcome email in Mailchimp, Klaviyo, and HubSpot and you’ll find three different ways to write “Hi, Alex.” Mailchimp writes it as *|FNAME|*. Klaviyo writes it as {{ first_name }}. HubSpot writes it as {{ contact.firstname }}. Same idea — drop in a placeholder where the recipient’s name goes, and let the sending tool fill it in — but each provider invented its own syntax.
That’s the merge-tag problem in one sentence: a powerful idea fragmented across a dozen incompatible dialects. Here’s what merge tags are, why they matter, and how to use them without rebuilding your email for every provider.
What a merge tag actually is
A merge tag (also called a personalization token, merge field, or variable) is a placeholder in your email that the sending tool replaces with real recipient data at send time. You write the placeholder once; each recipient sees their own value when the message lands.
The most common merge tags pull basic contact details:
- First and last name
- Email address
- Company, city, or country
- Phone number
Beyond contact fields, one merge tag matters more than the rest: the unsubscribe link. Every commercial email needs a working way to opt out, and most providers expose it as a specific token rather than something you build by hand.
Why every ESP spells it differently
There’s no shared standard for merge-tag syntax, so each email service provider (ESP) designed its own. The differences are small to look at but fatal to get wrong — paste a Mailchimp tag into a SendGrid email and it won’t resolve. The recipient will literally see *|FNAME|* staring back at them instead of their name.
That fragmentation has real consequences:
- You can’t move a polished email between providers without rewriting the tags. A template built for one ESP needs its personalization translated before it works anywhere else.
- A mistyped tag shows up verbatim. Unlike a typo in body copy, a broken merge tag is immediately visible to the reader — and looks unprofessional fast.
- The unsubscribe token is non-negotiable. CAN-SPAM, GDPR, and similar rules require a working opt-out. If you hard-code an old unsubscribe token or leave it out, you’re both breaking the law and hurting your deliverability.
The merge-tag dialects you’ll meet
Here’s how the major ESPs write the same handful of tokens:
| Token means | Mailchimp | Klaviyo | HubSpot | SendGrid | Brevo |
|---|---|---|---|---|---|
| First name | `* | FNAME | *` | {{ first_name }} | {{ contact.firstname }} |
| Last name | `* | LNAME | *` | {{ last_name }} | {{ contact.lastname }} |
| `* | *` | {{ email }} | {{ contact.email }} | ||
| Unsubscribe | `* | UNSUB | *` | {% unsubscribe %} | (module, not a token) |
The patterns are recognizable once you’ve seen them — pipe-delimited caps for Mailchimp, double braces for Klaviyo and SendGrid, a contact. prefix for HubSpot and Brevo — but the details (spaces or none, uppercase or lowercase, unsubscribe as a link or a tag) vary provider to provider. That’s exactly the friction a tool like Temway exists to remove.
How to use merge tags well
- Pick the smallest set that adds real value. A first name in the greeting is table stakes. Beyond that, only insert data that genuinely improves the message — a company name in a B2B outreach, a city for a local event. More tags isn’t more personalization.
- Always set a fallback. What happens when a field is blank? Most ESPs let you define a default (“Hi there” when there’s no first name). Use it — an empty greeting (“Hi ,”) looks broken.
- Get the unsubscribe token right. Use the exact syntax your ESP documents, and place it clearly in the footer. Don’t invent one, don’t reuse a competitor’s, and don’t leave it for later.
- Test with a real recipient. Personalization that renders fine in a preview can still break in an actual inbox. Send a test to yourself with a populated profile and confirm every tag resolves.
- Match the tag to the ESP you’re actually sending from. This is the easy mistake: a template imported from another provider still carries the old syntax. Rewrite before you send.
For the strategy behind what to personalize — behavior, lifecycle stage, dynamic content — see Email Personalization Beyond First Name. This article is about the mechanism; that one is about the message.
Common merge-tag mistakes
- Using one ESP’s syntax in another’s email. The tag passes through unrendered, and the reader sees raw markup.
- Forgetting the fallback. No default plus a missing field equals a blank spot or a dangling comma in your greeting.
- Hard-coding an unsubscribe link. Providers need their own tracked opt-out link to handle compliance and suppressions automatically. A pasted URL won’t behave the same way.
- Over-stuffing the email with tags. “Hi
{{ first_name }}from{{ city }}who bought{{ last_order }}” feels invasive, not relevant. - Not testing with incomplete data. A profile that has every field filled won’t reveal the broken fallbacks. Test against a sparse contact too.
How to handle merge tags in Temway
Temway is a builder and exporter — it designs the email; your ESP fills in the data at send time. The merge-tag problem is exactly the friction Temway is built to remove, so you can write one personalization token and send to any provider without rewriting it.
- Author once, in a neutral syntax. Insert a tag like
{{ first_name }}straight from the editor’s merge-tag picker (or type it in a text block). It renders as a clean pill in the editor and stays in one consistent form no matter how many providers you send to. - It’s translated to each ESP when you push. When you push an email to your ESP, the neutral token is rewritten into that provider’s exact dialect —
*|FNAME|*for Mailchimp,{{ contact.firstname }}for HubSpot,{{first_name}}for SendGrid, and so on. You never hand-translate. - The mapped providers cover the dialects above. Mailchimp, Klaviyo, HubSpot, SendGrid, and Brevo are mapped; their first name, last name, email, and unsubscribe tokens all translate automatically. For other providers, the token passes through as-is — fine if your ESP shares the same brace syntax, and something to double-check otherwise.
- Custom fields work too. If you send data the built-in tags don’t cover — an order number, a loyalty tier — you can add your own fields and, where needed, give each ESP its own token for that field. One authored email, per-provider syntax, no duplication.
- Build the design, then ship. Lay out your blocks, drop merge tags into the text where personalization belongs, preview on desktop and mobile, then export the HTML or push to your ESP. The design is yours; the data merge happens at send time in the provider you chose.
Where to go next
- Master the message side in Email Personalization Beyond First Name.
- See how Temway works with your provider on the integrations hub — each page covers that ESP’s personalization specifics.
- Protect your sends with Email Sender Reputation.
- Build the email your tags live in with Building Your First Email.
Explore: Email Coding & Development
HTML, CSS, MJML, and client-specific quirks — the technical foundations of building emails that render consistently everywhere.
What Is MJML? A Practical Guide to Responsive Email
MJML is a markup language that makes responsive, cross-client email HTML far easier to produce. Here's what it is, why it exists, and how it works under the hood.
Why HTML Emails Still Use Tables for Layout
Modern web pages abandoned table layouts years ago, but email still relies on them. Here's why tables persist in email — and how MJML lets you skip writing them.
HTML Email vs. Plain Text: When to Use Each
Should you send HTML email or plain text? Here's how they differ, when each wins, and why the best emails combine both in a single message.
How Wide Should an Email Be? Ideal Email Width Explained
Email width affects readability, rendering, and whether your layout breaks. Here's what the ideal email width is, why it matters, and how to get it right.