Skip to main content

Personalisation Token Tester

What it does

The Personalisation Token Tester takes an email template with merge tokens ({first_name}, {{company}}, %industry%) and a CSV of recipients, then renders sample emails for each row to confirm tokens resolve correctly. Missing values are flagged explicitly so the embarrassment of “Hi [MISSING: first_name]” hitting a prospect is caught before sending. Particularly useful for cold email, sales sequences, and any merge-driven campaign.

Common situations

You’ve built a cold email sequence with five tokens ({first_name}, {company}, {industry}, {recent_news}, {sender_name}) and you’ve imported a CSV from your data provider. Before scheduling the send, the token tester confirms every recipient has values for every token. Catches the rows where {recent_news} is blank because data didn’t pull through.

A previous campaign hit prospects with “Hi {first_name}” because tokens didn’t render. You want to make sure it doesn’t happen again. Run new templates through the tester before every send; the missing-tokens count tells you whether your data is complete.

You’re handing a campaign over to a junior team member and want to verify their setup. The tester surfaces issues like “the template uses {firstname} but the CSV has first_name” — a single character difference that breaks every row.

You’ve changed the data source for a campaign (new CRM, new export format) and want to verify the token names still align. Different CSV exports use different conventions (camelCase vs snake_case vs Title Case); the tester surfaces mismatches before they break sends.

You’re debugging why a specific cold email looked broken to one prospect. Find that row in the CSV, render it through the tester, see exactly what was missing.

What you need to know

Three token formats are common in email and outreach platforms:

Single-brace ({first_name}): used by Mailchimp, Lemlist, and many cold-email tools.

Double-brace ({{first_name}}): used by HubSpot, Marketo, and most templating engines (Mustache, Handlebars).

Percent-sign (%first_name%): used by older Mailchimp configurations and some legacy systems.

The tester recognises all three. The token name (between the delimiters) matches against CSV column headers exactly — so a token {first_name} requires a CSV column named first_name. Case sensitivity and underscores matter; {firstName} won’t match a first_name column.

What gets rendered:

For each CSV row, the tester walks through the template token by token. If the column exists and has a non-empty value, it substitutes. If the column doesn’t exist or the value is empty for that row, it shows [MISSING: token_name] — the literal placeholder so you can see exactly which row + which token is missing.

The summary view counts:

  • Total recipients — rows in the CSV
  • Clean — rows where all tokens have values
  • Missing tokens — rows with at least one missing token

The token coverage indicator separately shows:

  • Covered tokens — present in both template AND CSV headers
  • Missing in CSV — referenced in template but not a CSV column. These will fail for every row.

Common token issues this catches:

  • Missing column entirely: template uses {industry} but CSV has no industry column. Every row fails.
  • Empty values per row: template uses {company}, CSV has the column, but it’s blank for some prospects (often: data enrichment didn’t return a result).
  • Case mismatch: template uses {FirstName} but CSV column is first_name. Doesn’t match.
  • Whitespace in values: CSV column has " Acme Corp " with leading/trailing spaces. The tester preserves whitespace; ESP behaviour varies.

What the tester doesn’t do:

  • Doesn’t send the emails — it’s a pre-send check, not a sender. Use your ESP for actual sending.
  • Doesn’t validate the recipients — pair with Email List Cleaner for that.
  • Doesn’t check spam scoring — use Inbox Reachability Checker for that.

Frequently asked questions

What token formats are supported?

{token}, {{token}}, and %token%. The tester recognises all three in the same template if needed (rare but possible if you’ve copied from multiple sources).

Do CSV column headers need to match token names exactly?

Yes — case-sensitive, underscores matter. {first_name} matches first_name but not First Name or firstName. Standardise either side to ensure matching.

What about nested or computed tokens?

Most email platforms support simple substitution only. Some advanced platforms (Lemlist’s spintax, HubSpot’s smart tokens) support conditional logic — those won’t be evaluated by the tester. The tester does straightforward find-and-replace.

Can I test conditional content (if/else logic)?

The tester treats template content as straight strings. If your platform uses {% if first_name %}Hi {first_name}{% else %}Hi there{% endif %} syntax, the tester won’t evaluate the conditional — it’ll show the literal markup with the inner token substituted. For full templating-engine validation, use the platform’s preview tool.

What if my CSV has columns the template doesn’t use?

That’s fine. The tester only substitutes columns referenced by the template; extra columns are ignored. Useful for keeping context columns (lead score, source) without affecting rendering.

What if a token appears multiple times in the template?

Each occurrence is substituted with the same value. So if {first_name} appears in the salutation and the CTA, both render with the same value from the CSV.

How big a CSV can I test?

The tester runs in your browser, so it’s bounded by browser memory. A few thousand rows is fine; tens of thousands may slow down. For very large lists, sample a representative subset rather than testing the full list.

Does the tester send anything?

No. Everything is local — template, CSV, rendered samples all stay in the browser. Nothing is uploaded.

Common problems

Problem: All rows show missing tokens but the column exists.

Probably a case or whitespace mismatch. The token {First_Name} won’t match a column named first_name. Check the exact spelling and case of both. Strip whitespace from CSV headers if needed.

Problem: Some rows have values but show as missing.

Empty cells in the CSV register as missing. If the column is present but the value is empty for a row, the tester treats it as missing — same as the email service would. Either fill the empty values or exclude those rows from the send.

Problem: Token format {{token}} rendering as {first_name} instead.

The tester recognises both {token} and {{token}}. If the rendering looks wrong, check whether the template has mixed formats — some sections using single, some using double. Standardise on one format per template.

Problem: Template renders fine in tester but breaks in actual ESP send.

The ESP may have its own token format quirks. Some ESPs need specific syntax (*|first_name|* for older Mailchimp, {{contact.firstname}} for HubSpot). The tester’s three formats cover most cases; for ESP-specific syntax, run a real test send to a small list first.

Problem: Personalisation token contains a special character.

Special characters in token names (spaces, hyphens, dots) usually break tokens at most platforms. Stick to alphanumeric + underscores in token names: {first_name}, {company_industry}, etc.

Tips

  • Always test with a real CSV, not a sample. Real data has the gaps your sample doesn’t have.
  • Test each template once per data source change. New CRM exports may have different column names.
  • For cold email specifically, focus on the rows the tester flags as missing — those are the ones that’ll embarrass you with [MISSING: company] in front of prospects.
  • Consider fallback values for optional tokens. Some platforms support {first_name | "there"} defaulting to “there” if missing — better than “Hi {first_name}”.
  • Pair with Email List Cleaner — clean the list first, then test tokens. Order matters because the cleaner removes some rows.

Related tools in this suite

The Email List Cleaner handles syntax and address quality; this tool handles merge data quality. Together they cover both halves of “is this list ready to send to”. The Inbox Reachability Checker covers content; this tool covers data.

What this looks like at scale

For a single campaign, the tester is sufficient. For high-volume cold email or marketing automation, token validation should be automated — pre-send checks built into the workflow that prevent campaigns with missing tokens from launching. Most outreach platforms (Apollo, Lemlist, Outreach) have built-in token validation; the tester is the free fallback for platforms that don’t.

Take it further

If your team consistently has token-related issues across campaigns, the structural fix is usually data-quality work upstream — better data enrichment, stricter validation at import, fallback values configured per template. Talk through the situation and we can scope what data improvements look like.