Demographic Segmentation: Age, Location, and Beyond
The demographic splits that change what you send, and why most collected demographic data never gets used.
On this page
The short version
- Most collected demographic data is never used, because knowing an attribute rarely changes what you have to say.
- The exceptions are real and narrow: location where it affects timing, currency or law; role where the same product serves genuinely different jobs.
- Every demographic field costs completions at the form. Collect it only where a specific downstream thing consumes it.
Demographic segmentation is the split most programmes build first, because the fields are easy to imagine and easy to add to a form. It is also the one most often abandoned, and the reason is worth stating plainly: an attribute is only useful if it changes the message, and most do not.
Knowing that a subscriber is a marketing manager at a fifty-person company is interesting and changes nothing about the deliverability guide you were going to send.
Where it genuinely earns its cost
Location, where it affects something concrete. Send timing across time zones, currency and pricing, legal requirements that differ by jurisdiction, and events that are physically somewhere. All of these change the email.
Role, where the same product serves different jobs. A tool used by both an agency owner and an in-house practitioner is genuinely two different value propositions, and the emails should differ.
Company size or type, where it changes what is possible. Advice that assumes a team of eight is wrong for a sole operator, and the difference is large enough to be worth two versions.
Outside those, demographic data is usually a record rather than a segment.
Two demographic fields
Changes the send
- Country — pricing, tax wording, event dates
- Time zone — when the send goes
- Role — which version of the argument
- Team size — whether the advice is achievable
Collected and never used
- Job title as free text
- Industry, on a list serving one industry
- Company name, with no account structure behind it
- How they heard about you, when you already know
Inferred, declared and derived
Declared data comes from the person and is accurate about what they believe, which is not always accurate about the world. Job titles in particular are inconsistent enough between organisations that segmenting on them produces groups that are not what they appear.
Inferred data — location from IP, company from email domain, seniority from title patterns — is cheap and wrong often enough to matter. It is fine for a low-stakes decision like send timing and poor for anything the reader would notice being wrong.
Derived data, from behaviour, is usually better than either. Someone who reads the agency-focused material is more usefully classified as agency-interested than someone who ticked a box six months ago.
Collect it later, if at all
Where you do need a demographic field, the signup form is the most expensive place to ask. The same question in the first email, on the confirmation page, or in a preference centre costs nothing in list growth because the subscription has already happened.
Progressive collection also produces better data. Someone who has read three of your emails and is asked one question answers it more thoughtfully than someone typing whatever will get them past a form.
And it lets you ask a question shaped by what you now know about them, rather than a generic field that has to serve everybody.
Demographic field check
- A specific downstream process consumes this field
- That process exists, rather than being planned
- The field is collected after signup, not on the form
- Free-text roles are avoided in favour of a small option set
- Inferred data is only used where being wrong is harmless
- Anything unused for six months is removed from the form
Frequently asked questions
Should I ask for a first name?
Only if it changes something a reader would notice. A greeting merge tag is not that, and it costs completions — which makes it one of the most commonly collected fields with the least justification.
Is inferring location from IP acceptable?
For send timing, yes — being wrong costs a mistimed email. For anything the reader sees, such as currency or a stated location, ask rather than infer, because being wrong is visible and looks careless.
What about job title for lead scoring?
Free-text titles are too inconsistent to score reliably. A short list of roles you actually distinguish between is more useful and asks less of the person filling it in.