How To Use Custom Fields In Email Personalisation

Custom fields are the pieces of information attached to an individual contact record that go beyond an email address and the standard name fields. They might describe a customer’s preferred product category, membership tier, nearest location, renewal date or selected content interests.

Used well, they let an email programme adapt to information the recipient has shared or created through a genuine interaction. Used badly, they produce awkward greetings, irrelevant offers and emails that feel uncomfortably watchful. The difference is rarely the email platform. It is the quality of the data model, the rules around its use and the care taken before a message is sent.

This article focuses on permission-based marketing and lifecycle email. A custom field is not a licence to enrich a list with guessed, scraped or purchased data.

What custom fields do in an email programme

Most email platforms call these fields by a slightly different name: custom properties, profile attributes, merge fields or audience fields. The basic principle is the same. A field holds a value against a person’s record, and a personalisation token inserts that value into the email at send time.

For example, an outdoor retailer could store:

• preferred_activity: hiking, cycling or camping
• nearest_store: Bristol
• loyalty_tier: Gold
• last_purchase_category: waterproof jackets
• renewal_date: 2026-11-15

A merge tag or personalisation token then turns a generic template into an individual message. In a platform such as Mailchimp, an audience field is associated with a merge tag that is replaced with the contact’s stored value when the campaign is sent. The same fields can also be used in segments. Mailchimp’s merge-field documentation provides a useful illustration of the underlying model.

Custom fields are therefore useful for more than putting a first name in a greeting. Their greater value is in deciding which message, content block, timing or next step is most appropriate.

Separate fields, events, tags and segments before you build

Personalisation becomes fragile when every piece of data is stored in the same way. Before adding fields, distinguish between four related concepts.

Type	What it represents	Example	Typical use
Profile field	A relatively stable attribute of a person or account	Preferred language; home store	Greeting, language selection, regional content
Event data	Something that happened at a particular time	Registered for a webinar; placed an order	Confirmation, follow-up or trigger-based journey
Tag	A flexible label, often applied by a person or automation	VIP-event-invite; migrated-2026	Operational grouping and temporary campaign eligibility
Segment	A saved rule that selects contacts meeting conditions	Gold members whose renewal is within 30 days	Audience selection and suppression

Do not turn an event into a permanent profile field without a clear reason. last_webinar_attended may be useful if it is deliberately maintained, but it is not a substitute for a proper event history. Equally, a tag such as interested_in_running is a weak basis for content personalisation if it has no defined source, expiry or owner.

Keep the source of truth clear. Order data should normally come from the commerce platform; subscription preferences from the preference centre; membership status from the membership system. The email platform may hold a synchronised copy, but it should not quietly become the only place where critical customer data is edited.

Choose fields that make the message more useful

Start with a communication decision, rather than a request for more data. Ask: “What would we send differently if we knew this?” If the answer is “nothing”, the field probably does not deserve to be collected or maintained.

Good early candidates are usually transparent, low-risk and directly useful:

• Preferred language or region for the right language, currency, delivery information or local event details.
• Declared interests for selecting newsletter modules or product education.
• Customer status for separating onboarding, active customer and lapsed-customer messages.
• Renewal or appointment date for timely service reminders, where the recipient would reasonably expect them.
• Account or product context for useful lifecycle email, such as setup guidance for the product someone actually uses.

Begin with a small number of fields that can be kept accurate. A long catalogue of sparsely populated attributes makes templates harder to test and encourages teams to make assumptions. It also makes it difficult to explain why the organisation holds the data.

The UK GDPR’s data-minimisation principle requires personal data to be adequate, relevant and limited to what is necessary for the purpose. Accuracy and storage limitation matter too. The ICO’s guidance on purpose limitation, data minimisation, accuracy and storage limitation is a useful starting point when defining a field and its retention rules.

Design each field as a small product

A field name alone is not a specification. For every field used in email, record its meaning and operational rules in a short data dictionary. This prevents a label such as status being interpreted differently by marketing, customer service and engineering.

A practical definition includes:

• Technical name: a stable, machine-readable identifier, such as preferred_language.
• Plain-English definition: what the field means and what it does not mean.
• Data type: text, number, date, true/false or a controlled list of values.
• Permitted values: for example, en-GB, fr-FR and de-DE, rather than free-text language entries.
• Source: preference centre, checkout, CRM, event feed or manual service update.
• Update rule: which system can overwrite it, and when.
• Expiry or review point: particularly important for interests and inferred preferences.
• Email use: the specific template, segment or journey decision it supports.
• Fallback: what happens if it is blank, invalid or unavailable.

Use controlled values wherever possible. A free-text field for “country” can produce UK, United Kingdom, Great Britain and spelling errors. A controlled country code is easier to segment, safer to use in conditional logic and far less likely to break a template.

Date fields deserve particular care. Store dates in an unambiguous format in the underlying system, decide whether the year is meaningful, and format them in the email for the recipient. A renewal date should not be displayed as an unexplained timestamp, and a birthday campaign should not accidentally reveal a birth year when only the day and month are needed.

Populate fields through useful, expected interactions

The most dependable fields generally come from one of three places: information someone submits, information created by a transaction or service relationship, and preferences that someone can update.

A preference centre is often better than a lengthy sign-up form. Ask for the minimum needed at subscription, then invite subscribers to choose topics, frequency or location when there is a clear benefit. This produces data that is easier to explain: “You told us you want running advice”, rather than “We think you may be interested in running.”

Where data is synchronised from a CRM, commerce system or product database, specify field ownership and precedence. If a customer changes their preferred store in their account, that value should not later be overwritten by an older import file. If values arrive from several systems, establish a hierarchy before launching any personalisation.

Do not confuse a value being technically available with it being appropriate to mention. A customer may have provided an address for delivery, for example, without expecting a marketing email to call out their postcode. Personalisation should feel like a service, not evidence that every available data point is being watched.

For UK organisations, direct marketing involving personal data must have an appropriate lawful basis under data protection law, alongside any applicable electronic-marketing rules. The ICO’s direct marketing guidance explains the need to consider both. Fields revealing or implying health, religion, political views, ethnicity or other sensitive matters require especially careful legal and privacy review; they should not be introduced casually for campaign targeting.

Use custom fields in layers of personalisation

There are three broad levels of use, each requiring progressively stronger data and testing.

1. Simple insertion

This is direct substitution: “Hi Priya”, “Your local collection point is Leeds”, or “Your membership renews on 15 November”. It works when the value is factual, current and natural in the sentence.

Do not force a first-name greeting merely because a first-name field exists. Names can be missing, malformed, shared between people, entered in all capitals or unsuitable for the form of address. A neutral greeting such as “Hello” is often preferable to a brittle fallback.

2. Conditional content

Conditional content changes part of the email according to a rule. A sports retailer might show a trail-running content block to people who selected trail running, while everyone else sees the general seasonal guide. This is usually more valuable than changing the greeting.

Give every conditional block a default. Microsoft’s documentation on conditional content in Customer Insights – Journeys describes how conditions are evaluated in order and how default content is used when no condition matches. That logic applies more widely: a field can be empty, mistyped, delayed in a sync or outside the values envisaged when the template was built.

Keep variations proportionate. Six variants of one product tile may be manageable. Fifteen overlapping conditions across an entire newsletter can make it nearly impossible to know what any one person will receive.

3. Journey decisions and timing

Custom fields can determine who enters a journey, which branch they follow and when they receive a message. Examples include a welcome path based on the topic selected at sign-up, a renewal sequence keyed to a service date, or a customer-education series based on product type.

These decisions have a larger operational impact than changing copy. A wrong branch could mean an irrelevant offer, a missed service reminder or inappropriate contact pressure. Build eligibility and suppression rules around the journey, including unsubscribes, consent status, recent sends and known customer-service exceptions.

Always plan for missing, stale and unsafe values

Personalisation should fail gracefully. If the email cannot safely render a field, the recipient should see sensible general content, not an empty sentence, raw token or a message intended for somebody else.

Set a fallback at two levels:

• Field-level fallback: a neutral value where this is genuinely appropriate, such as “there” in a greeting.
• Content-level fallback: a default module, image, link or call to action when a recipient does not qualify for a specific variant.

Mailchimp, for example, supports default merge values and conditional merge logic for empty values. Its guidance shows why a direct field insertion without a fallback can result in a blank space, while a conditional rule can display a generic alternative. Mailchimp’s explanation of default merge values and its conditional merge-tag examples are useful practical references.

Also treat imported text as untrusted input. Names and free-text responses can contain unexpected punctuation, markup-like characters or content that does not fit the email’s tone. Use the platform’s supported personalisation features rather than inserting unescaped data into custom HTML. Avoid placing unvalidated field values inside URLs. Where a link must identify an account or recipient, use a properly designed, access-controlled mechanism rather than exposing sensitive values in the address.

Test the data, not just the design

An email can look perfect in the editor and still render incorrectly for real contacts. Personalisation testing needs representative records as well as visual checks.

Create a small internal test audience that covers the situations your logic must handle:

• a complete, valid profile;
• a blank field;
• each permitted value;
• an obsolete or deliberately invalid value;
• a contact who qualifies for no variation;
• a contact who could qualify for more than one condition, if that is possible.

Preview each variation and send live tests where the platform requires them. Some systems do not resolve contact-specific values in ordinary test sends. Mailchimp specifically notes that audience-field merge tags are contact-specific and recommends previewing with live merge information or testing against a small live segment. Its merge-tag testing guidance also warns that a typo can leave the raw tag visible to recipients.

Test the entire message, including subject line, preheader, header, body, links, images, footer and plain-text version. A conditional link or product image is just as capable of being wrong as a personalised sentence.

Finally, check the send population before launch. A sound template cannot correct a flawed segment, stale data sync or accidental inclusion of unsubscribed contacts. For larger programmes, keep an audit trail of the source query, field definitions, template version and approval. It makes later investigation far easier.

Measure whether the field earns its place

Do not assume that more personalisation is better. Measure the outcome that matches the message: completed setup, repeat purchase, renewal, attendance, fewer support queries or preference-centre updates. Engagement metrics can provide context, but they should not be the only measure of value.

Where practical, compare a personalised treatment with a sensible generic control, and review results by variation. More importantly, watch for warning signs: rising unsubscribes, spam complaints, customer-service feedback or a pattern of people correcting the same field. These may indicate that the data is inaccurate, the logic is too broad or the message crosses the line from useful to intrusive.

Deliverability also benefits from restraint. Relevant email sent to people who asked for it is a stronger foundation than aggressive segmentation or ever-more elaborate content variations. If a programme’s personalisation is being introduced alongside poor engagement, inconsistent consent records or excessive contact frequency, those underlying issues need attention first. In a deliverability audit or managed recovery project, Email Foundry may review audience quality, suppression handling and contact pressure alongside sending infrastructure, because a sophisticated template cannot compensate for weak sending practices.

Make personalisation maintainable

Custom fields are an ongoing operational commitment. Assign an owner for each important field, review values and usage regularly, and remove fields that no longer support a real communication purpose. Update documentation whenever an integration, form or lifecycle journey changes.

The aim is not to make every email look individually written. It is to use a limited set of trustworthy information to make messages clearer, more relevant and easier to act on. When the data is expected, accurate and easy for the recipient to control, custom fields become a practical tool for better email rather than a source of avoidable risk.

Frequently asked questions

What is the difference between a custom field and a merge tag?

A custom field stores data on a contact record, such as preferred language or renewal date. A merge tag, sometimes called a personalisation token, is the placeholder placed in an email template to display that field’s value at send time.

Should every subscriber have a first-name field?

No. Collect a first name only when there is a clear use for it and a reliable source. A neutral greeting is preferable to a blank, incorrect or awkwardly formatted name.

Can custom fields be used for email segmentation?

Yes. Many platforms allow segments based on custom-field values. Use controlled values, clear definitions and fallbacks, especially where fields decide eligibility for a journey or offer.

How often should custom fields be reviewed?

Review important fields whenever a form, integration or journey changes, and set regular checks for fields that can become stale, such as interests, location, account status and preference data.

Sources and further reading

• Direct marketing guidance — Information Commissioner’s Office
• Purpose limitation, data minimisation, accuracy and storage limitation — Information Commissioner’s Office
• Merge fields — Mailchimp
• Getting started with merge tags — Mailchimp
• Use conditional merge tags — Mailchimp
• How to use conditional content — Microsoft Learn