By Theo Brandt ยท Updated
SaaS Email Personalization: Beyond First Name
Personalization that changes what the email says and asks for, driven by something the reader did in your product.
A first name in the greeting does not make an email relevant. What does is a change in the message itself: a different next step, a different feature, a different recipient role, triggered by something the person did or did not do. For a SaaS product that means feeding four kinds of data into the email tool, choosing the one or two that change the call to action, and handling missing values before the first send. The platform matters mostly for how it treats incomplete data, which is where most real-world personalization breaks.
Prices checked 7 October 2026; each price links to the vendor page it came from.
Four data sources, and how each one fails
| Source | Examples | Changes the email by | Typical failure |
|---|---|---|---|
| Profile | Name, company, role, signup source, language | Greeting, tone, which docs link to show | Blank name or role on imported contacts |
| Product events | project_created, teammate_invited, integration_connected | Next step, skipped lessons, exit from the sequence | Event arrives late or under two names |
| Billing | Plan, trial end date, last payment status | Upgrade prompts, payment notices, who gets promotions | Stale plan field after a downgrade |
| Account | Number of seats, admin or member, account owner | Which person on the account receives which message | One person in two accounts gets mixed content |
Most teams start with the profile because it is easy and then stall. The gains come from the second and third rows, because those are the only two that tell you what a person should do next. If you can send just one product event to your email tool this month, pick the one that marks activation, such as the first report created or the first teammate invited, and use it to end the onboarding sequence for anyone who has already done it.
How Customer.io, Loops and Userlist handle the data
Customer.io uses Liquid. Its Liquid documentation splits the data into three objects: {{customer.attribute_name}} for what you know about the person, {{event.attribute_name}} for data on the event that triggered an automation, and {{trigger.attribute_name}} for the data behind a transactional message or API-triggered broadcast. A fallback looks like {{customer.first_name | default: "there"}}. The docs add two limits worth planning for: event keys only work in event-triggered automations, and the default filter needs the latest Liquid version, which accounts created on or after 28 November 2023 use. Essentials is $100 a month at 5,000 profiles and $145 at 10,000 on its pricing page.
Loops works with tags rather than a programming syntax. Its personalizing emails guide says campaign emails use contact properties, workflow emails use contact and event properties, and transactional emails use data variables. A contact property is the API name in braces, for example {teamName}; event properties take an {EVENT_PROPERTY:name} prefix and transactional data variables a {DATA_VARIABLE:name} prefix. The guide notes that fallbacks cannot be inserted inline inside a tag, so you set them in the editor panel, and conditional sections can show or hide content based on any of the three data types. The free plan on Loops' pricing page covers the 1,000 newest contacts with 4,000 sends per rolling 30 days, and paid plans list $99 a month at about 10,000 contacts.
Userlist approaches personalization from the account side. Its site describes separate segments for users and companies, which helps when the message depends on an account-level fact such as seat count rather than only on the individual. Basic is $149 a month for up to 10,000 users and Professional is $349 on Userlist's pricing page. The Userlist vs Customer.io comparison covers when that account focus is worth the price.
One email, three versions: a week-two activation message
Here is how the data above turns into a single decision. The product is an invoicing app; the goal is for a new account to send its first invoice. The email goes out seven days after signup and the table shows which version each person gets.
| If the data says | The email opens with | The single call to action |
|---|---|---|
| invoice_sent exists | Nothing is sent; the person exits the sequence | None |
| client_added exists, no invoice | A line naming the client they added, and how a draft turns into a sent invoice | Open the draft for that client |
| No client yet, role is admin | The two-minute path: add a client, then create the first invoice | Add the first client |
| No client yet, role is member | A note that an admin has to set up billing, with a one-click request to the admin | Ask the account admin |
The second row would read something like this: "Hi [first name], you added [client name] last week. Your draft is ready: add the line items and send it." The merge fields are the smallest part of that sentence. The work is in the rows, and in the exit on the first row, which stops the sequence from nagging someone who has already succeeded. Build that exit before you write copy.
Failure modes to test before the first send
- A missing value blocks delivery. Customer.io's documentation says a Liquid statement that does not evaluate, such as a person with no first_name, stops the message and shows as failed in the logs. Loops says that without a value the email will not send. Every merge field needs a fallback, and the fallback must read naturally in the sentence ("Hi there" works; "Hi Customer" does not).
- Stale data. A plan field copied once at signup will be wrong after an upgrade. Update billing attributes from the billing system's events, and send the event rather than a daily snapshot if the email depends on it.
- Edge cases in names. Test a hyphenated name, a very long company name, a name in another script and an empty string. Truncation and capitalization rules differ by tool.
- Variants nobody maintains. Three well-kept versions beat nine that drift. If a branch has fewer than a few dozen recipients a month, merge it into its neighbor.
- Lines that read as surveillance. Reference what the person did in the product, in the product's own words. Leave out anything inferred from outside data they never gave you.
Create three test contacts before launch: one with every field filled, one with only an email address, and one in the middle. Send the real workflow to all three and read the results, not just the preview pane, because the preview often shows sample data.
Measuring whether it worked
Opens say little in an era of image prefetching, so measure the action the email asks for. For the invoicing example that is the share of eligible accounts that sent a first invoice within a set window after the email. Where volume allows, hold out a random slice that gets the generic version, and compare the two on that action. Where it does not, compare cohorts from before and after the change and say plainly that the comparison is rough. The SaaS email metrics guide covers the measurement side in more detail, and the onboarding email guide shows where behavioral branches fit in a full sequence.
Which tool to pick for this
Choose Customer.io when your content owner is comfortable with Liquid and wants to branch on event data and attributes in the same workflow; it is the most flexible of the three, at $100 a month for the first 5,000 profiles. Choose Loops when a small team wants tag-based merge fields, a visual editor and conditional sections without learning a template language, and can live with the free plan's limits or the $99 stop at about 10,000 contacts. Choose Userlist when the account is the unit you sell to and messages should differ by role inside it. The wider ranking lives in the lifecycle email guide and the customer education platforms list.
Frequently asked questions
What should I personalize first in a SaaS onboarding sequence?
Start with one product fact that decides what the reader should do next, such as whether they created their first project or invited a teammate. Customer.io can branch on an event and an attribute inside the same workflow, and Loops can do the same with contact and event properties. Add name and company only after the behavioral branch works.
What happens when a merge field has no value?
In both Customer.io and Loops the email can fail to send. Customer.io documents that a Liquid statement which does not evaluate, for example a missing first_name, stops the message and logs it as failed; its default filter supplies the fallback. Loops documents that without a value the email will not send, and asks you to set a fallback in the editor. Define a fallback for every field before you publish.
Do I need Liquid or a similar templating language?
You need some way to show or hide content by data. Customer.io uses Liquid across email, push and in-app. Loops offers merge tags plus conditional sections that react to contact properties, event properties or data variables. Userlist leans on segments for users and companies rather than inline code. Pick the one your content owner can maintain without an engineer.
How do I keep personalization from feeling intrusive?
Use only data the person knowingly created inside the product, and describe it the way the product shows it: the project title, the integration they connected, the plan they chose. Skip inferences about the person that they never entered. If a line would make a customer ask how you know that, rewrite it.