Est. reading time: 5 minutes
An email that opens with “Hi, FNAME!” costs more than the flinch it causes. It announces to every recipient that they’re a database row, it lands hardest with your most engaged readers because they’re the ones who actually open, and it’s the kind of error that spam filters and unsubscribe fingers both notice. The good news is that broken merge tags aren’t mysterious. The tag is doing exactly what it was told, printing itself literally because the system couldn’t resolve it, and there are only three reasons that happens.
Why subscribers see the code instead of their name
The first and most common cause is a syntax mismatch. Every platform speaks its own tag dialect. Mailchimp expects *|FNAME|*, HubSpot expects {{ contact.firstname }}, Klaviyo expects {{ first_name }}, and SendGrid, Marketo, and Salesforce Marketing Cloud each have their own conventions. A template copied from another tool, an agency handoff, or a tutorial written for a different ESP will carry the wrong dialect, and the parser doesn’t guess. It prints the unrecognized string exactly as written, which is how Klaviyo syntax ends up greeting a Mailchimp list by its variable name.
The second cause is a data mapping gap. The tag is correct, but the field it points to doesn’t exist or doesn’t match, because the audience field is named something else, or the CSV import came in with a header like “GivenName” that mapped to nothing. With no value found and no default configured, the tag either prints literally or renders as an awkward blank, and the plain-text version of the email is frequently where this hides, since fewer people proof it.
The third cause is rendering corruption. Smart quotes pasted in from Word or a CMS break tag delimiters, as do stray spaces, wrong capitalization, and escaping inside code blocks. This family of failure has a tell, which is inconsistency. If the tag works in the body but breaks in the subject line, or works in preview but not in the live send, you’re looking at a corrupted instance or a layer with its own personalization settings, not a systemic problem.
The fix, in order
Start with syntax. Open your platform’s merge tag reference, copy the official first-name token, and replace every variant in the template, meaning the HTML body, the plain-text version, the subject line, the preheader, and the footer, since any one of them can hold a stale copy. Retype rather than paste where corruption is suspected, keeping quotes straight, braces exact, and case correct.
Then set the fallback, because a correct tag pointed at an empty field is still a broken greeting. Configure a default that fits your voice, “there” and “friend” are the standard casual options, and where the platform supports conditionals, use the full pattern, meaning if a first name exists, use it, otherwise use the default. A list of any size has empty name fields, so the fallback isn’t an edge case, it’s a guaranteed path that deserves the same design attention as the happy one.
Then QA both paths before anything sends. Preview with real contact data, then send seeds to yourself across Gmail, Outlook, and mobile, using two test contacts, one with a name and one without, and checking every layer, both formats, subject, preheader. Two habits prevent most recurrences. Save old templates as new copies rather than editing in place, which clears caching quirks, and never paste copy directly from Word or Google Docs, routing it through a plain-text editor first to strip the invisible formatting that breaks tags.
Make the greeting robust, not just repaired
Once the tag resolves, the next embarrassment tier is resolving it badly, greeting someone as “Hi, MAYA” because the import came in all-caps, or “Hi, admin_account_42” because that’s genuinely what’s in the field. Most platforms offer simple filters worth applying by default, title case to fix shouting imports, trimming to remove stray spaces, and where the tooling allows, a graceful fallback when the value looks like a system artifact rather than a human name. The greeting should survive ugly data, because ugly data is the normal condition of a list that’s been growing for years.
Then standardize so the fix outlives the person who made it. Build the greeting as a reusable snippet or partial so every campaign inherits the proven token and fallback instead of re-typing it, and document your platform’s approved tags in a one-page reference so nobody imports a foreign dialect again. If your team lives in Mailchimp, that page belongs next to your notes on audiences, tags, and segments, since confusion between those structures is where mapping errors are usually born.
The durable version of the fix is upstream, in the data. Collect first name as its own validated field on your forms rather than parsing it from somewhere later, audit fields periodically, and normalize the records you already have, which is ordinary list maintenance paying an outsized return. Personalization failures are really automation failures in miniature, a system doing something confidently wrong at scale, and the same monitoring instinct we described in spotting workflow mistakes before they get expensive applies here, meaning seed yourself into your own sends and treat the first “Hi, FNAME” report as a process gap rather than a typo.
Merge tags aren’t temperamental. They’re literal, and literal systems reward exactness. Match the dialect, map the field, configure the fallback, test both paths, and the greeting does what it was always supposed to do, which is quietly convince each subscriber that this email was meant for them.
