Using merge tags, with fallback values
Personalize every send without breaking it for incomplete profiles.
The four tokens Sumezi actually supports
Four merge tags are wired all the way through to a real subscriber field: {{first_name}}, {{last_name}}, {{email}} and {{city}}. First and last name are split from the subscriber's single Name field on the first space; city comes from the city field on their subscriber card.
| Token | Comes from |
|---|---|
| {{first_name}} | First word of the subscriber's Name field |
| {{last_name}} | Everything after the first word of Name — empty if the name has no space |
| {{email}} | The subscriber's email address, always used as-is |
| {{city}} | The city custom field on the subscriber |
The Subscribers page's field-visibility toggles also list {{phone}} and {{birthday}} (off by default). Those are cosmetic column labels only — the subscriber record has no phone or birthday field to fill them from, and the function that actually personalizes a send doesn't recognize them. Typing either one into a template sends it literally, braces and all.
Two ways to place one
Type {{first_name}} directly inside a Heading or Text block — the editor recognizes the {{...}} pattern as you type and highlights it inline. Or drag the dedicated Token block onto the canvas for a standalone personalized line; its only property is the raw token text plus alignment.
Hoi {{first_name}}, we hebben de winkel opnieuw ingericht. Warme eik, zacht linnen en een paar stukken die je het hele jaar door blijft gebruiken.
That example is the exact opening line of the editor's own starter document (in Dutch, this workspace's default content language) — proof the syntax works fine inline, mid-sentence, not just as its own block.
What happens when a value is missing — verified
Personalization runs server-side, at the moment a send actually goes out (real campaigns and test sends alike), by scanning the fully compiled HTML for those four token strings and replacing them per recipient — regardless of whether the token sits in a Heading, a Text block, a Token block, or even inside an HTML block's raw markup.
For first_name, last_name and city, an empty value doesn't leave a gap — it's replaced by one shared fallback string, configured once in Settings → Personalization (empty by default). Set it to something like "there" so "Hi {{first_name}}" degrades to "Hi there" instead of "Hi ," for a subscriber with no name on file.
Email is the one exception. It's always the subscriber's real address, never the fallback — a missing email is a data problem to fix in Subscribers, not something a merge tag should paper over. And there's only one fallback string for all three other tokens; you can't set a different one per field.
Typos aren't tokens
The replacement is a literal string match on exactly {{first_name}}, {{last_name}}, {{email}} and {{city}}. Anything else — {{First_Name}}, a trailing space, a token in another language — isn't recognized, and gets sent to every recipient completely literally, braces included.
The editor's inline highlighting doesn't check this either — it lights up any {{word}} pattern in a Heading or Text block whether or not it's one of the four real tokens, so a highlighted tag on the canvas is not proof it will actually be filled in.
Common mistakes
- A typo ships literally: there's no error or warning at send time — the only way to catch a misspelled token is to read the compiled HTML or send yourself a test first.
- No fallback set, many subscribers without a name: lines like "Hi ," go out looking broken — set a fallback in Settings before your first real send to a mixed list.
- Expecting {{email}} to use the fallback: it never does — a blank email is a Subscribers data issue, not a personalization gap to patch over.
- Typing {{phone}} or {{birthday}}: those field-toggle labels aren't wired to anything — use only first_name, last_name, email and city.