Two rules cover almost all of it. Every merge field gets a fallback defined at template level, not decided in the send. And every send goes to test rows that simulate the data you are missing, not just to a seed address with a complete profile.
The rest is judgment about which fields deserve a generic replacement, which deserve a suppressed block, and which sentences need rewriting so the field can go missing without leaving a hole. Catching a broken fallback before send is one check inside the broader discipline of campaign production management, a step that happens in front of your ESP, not inside it.
What does a "Hi ," incident actually look like?
Tuesday, 7:00 a.m. A points-expiry reminder goes to 41,200 contacts. The subject line is {{ first_name }}, your points expire Sunday.
At 7:22 the first reply lands: ", your points expire Sunday". By 9:15 there are 60 of them plus one from the client's head of CRM, who is on the seed list.
The postmortem found three things. First, 3,880 contacts came from an in-store tablet signup that captured email and phone only, so first name was blank for 9.4% of the list. Second, the body greeting was fine, because someone had added a fallback to the template months earlier. The subject line was not, because subject lines get written in the brief, pasted into the ESP by whoever builds the send, and reviewed as copy rather than as code.
Third, and this is the real finding: nobody owned fallbacks. Marta wrote the merge field into the copy doc. The producer pasted it. QA checked rendering and links against the preview of a complete profile. The data owner knew about the tablet gap and was never asked, because nobody's job said "confirm the fallbacks." Every person did their own job correctly.
This is a process defect, not a copy defect. A pre-send checklist only catches it if a line item names the fields and their fallback values, and the person signing that line has the template open.
What fallback should you use for each field type?
Fallback strategy is not one decision. It changes by field type, and so does the failure mode.
Names. Use a plain greeting: "there", "Hi again", or nothing. Avoid "Valued Customer" and "Dear Friend", which read as visibly failed personalization and are worse than the neutral version. Casing matters as much as emptiness, because form data arrives as marta, MARTA, and mArTa. Normalize with the platform's title-case filter before you worry about the fallback.
Company. In B2B copy, "your team" covers most sentences. It does not cover a sentence that asserts something specific: "We noticed Acme added three seats last month" has no generic version. Suppress the block, or exclude the contact from the segment.
Dynamic offers and product data. Never fall back to a generic offer. A wrong discount code or a default price is a commercial problem, not a cosmetic one. The correct fallback for an offer module is to hide the module, and if the offer is the reason the email exists, to drop the contact from the send.
Dates. A relative phrase ("this month", "soon") works only if it is still true for everyone in the segment. And a fallback does nothing about format: a date can arrive as 2026-11-03 or 03/11/2026, both populated, one of them wrong in your market. That is a validation problem sitting behind the personalization problem.
Sometimes the right fallback is a rewrite. If you cannot write a replacement value that reads naturally in the sentence, the sentence is the thing to fix. Compare two subject lines for the same email:
{{ first_name }}, your points expire Sundayneeds a fallback that works as the first word of a sentence. Keep the comma inside the field or the conditional, never next to it, or a blank value leaves ", your points expire Sunday".Your points expire Sundayneeds no fallback. The name can then sit somewhere you can drop it and its punctuation together, which means a conditional block rather than a default value.
Move the field to a position where a generic phrase fits, or where deleting it costs nothing. Personalization that only works when the data is complete is not personalization, it is a dependency.
What is the fallback syntax on each platform?
| Platform | Fallback syntax | Worth knowing |
|---|---|---|
| Salesforce Marketing Cloud (AMPscript) | %%[ SET @fname = AttributeValue("FirstName") IF EMPTY(@fname) THEN SET @fname = "there" ENDIF ]%% then Hi %%=v(@fname)=%%, | AttributeValue() returns empty for an unknown field. Referencing an undefined field directly can fail the send with an unrecognized attribute error, so the safe getter is worth the extra characters. |
| HubSpot | Editor: insert the personalization token and fill the fallback field. Code: {{ contact.firstname|default("there", true) }} | The second parameter is not optional in practice. Without true, default fires only on undefined values, not on an empty string. Account-wide defaults live in the email personalization settings. |
| Braze | Hi {{${first_name} | default: 'there'}} | The Liquid default filter covers empty, nil, and false, so it behaves the way most people expect. The Add Personalization modal inserts the tag with your default already attached. |
| Klaviyo | Hi {{ first_name|default:'there' }} | Tags copied from the preview panel arrive with |default:'' already on them, which means an empty fallback is the easy thing to ship by accident. Chain |title to fix casing: {{ first_name|title|default:'there' }}. |
| Mailchimp | Audience field setting: "Default merge tag value". Per campaign: *|IF:FNAME|*Hi *|TITLE:FNAME|*,*|ELSE:|*Hi there,*|END:IF|* | Merge tags are case sensitive and break if you wrap them in square brackets. Contact-specific tags do not populate in a plain test email, so use preview with live merge tag info or send to a small real segment. |
Set the account or audience level default too, even where you write the fallback inline. It is the layer that protects you the day someone builds a send in a hurry.
Which test rows does every send need?
Five rows, in a test list you own, seeded once and reused.
Not a colleague's real profile, which is complete and therefore useless as a test.
- Empty field. Every personalized field blank. This row catches a missing fallback and the orphan punctuation around it: the comma in "Hi ,", the apostrophe in "'s order".
- Weird casing.
marta,MARTA RUIZ,mArTa. Catches unnormalized form data, which is the most common version of a name that renders but looks wrong. - Long value. A 40-character company name, an 80-character product title. Catches subject line truncation, button labels that wrap to three lines, and table cells that push the layout past 600px.
- Special characters.
Peña,O'Brien,Müller,Smith & Sons. Catches encoding faults and HTML escaping bugs, including the classic&that renders as&in the subject line. - Wrong type. A date field holding
N/A, a number field holdingtwelve, a URL field holding a bare domain with no protocol. This row matters because the field is populated, so no fallback fires and nothing looks broken until you read it.
These five test the data axis. Client coverage is a separate decision: see which email clients to actually test for how to size that side of the matrix. Run both on the version you intend to send.
The rows should live with the template, not the campaign, so nobody rebuilds them under deadline. Same for ownership. Whether the fallbacks were defined and the five rows were run needs to be recorded state on the campaign rather than something a producer remembers. That is the part LaunchSign handles between the brief and the ESP: a QA phase attached to the markup deliverable, with checklist items that have to be cleared before the version goes to the client for sign-off, and a record afterward of who cleared them.
Our pre-send checklist writes the fallback and test-row items out as lines you can hand to a producer. Get the checklist.
FAQ
What is a good fallback value for a first name?
"there" or nothing at all. "Hi there," reads like a normal email; "Hi Valued Customer," announces that a database lookup failed. If the sentence needs a noun, borrow one from the context: "We asked our customers" instead of "We asked Marta".
Why did my fallback not fire even though the field looked empty?
Because empty and undefined are different things to most template engines. A field that exists and holds an empty string, or a single space character, counts as populated. In HubL you need the second parameter, |default("there", true), to catch the empty string. Liquid in Braze covers empty by default. A field holding one space defeats all of them, so trim on import.
Do merge tags render correctly in test emails?
Not always, and this is a frequent source of false confidence. In Mailchimp, contact-specific merge tags cannot resolve in a plain test send, because the only data available is the address you typed. Use the platform's preview with live contact data, or send to a small segment of real profiles that includes the incomplete ones.
Should I exclude contacts with missing data instead of using fallbacks?
For offer-driven emails, often yes: no data, no send, and a smaller list beats a wrong price. For everything else, exclusion quietly shrinks your reach every send and leaves the data gap unfixed. The better pattern is fallbacks in the template, exclusions where the message is meaningless without the field, and a monthly count of how many contacts are hitting each fallback. That count is your data quality report.
