Every simulation runs against exactly one population. Change the population and you have changed who is answering, which changes the answer more than any other field on the form.
How one is defined
A population is a short, readable definition rather than a black box. It has four parts, and you will usually only touch the first two:
Who is in it. Filters over the base population: age range, location, household type, behaviour, whatever the underlying studies measure. "Adults 25 to 54 in mid-size metros." "Households with a child under ten."
What shape it should have. The composition you want it to match. By default a population matches the public within your filters. You can instead tell it to match your customers — see below, because this is the most valuable thing on the page.
What to bring in. Extra depth from other studies: spending, time use, attitudes. Usually left at the default.
How many. The size of the group. A few thousand is normal.
You can write this yourself, or describe the group in a sentence and have it drafted for you, then edit it. Either way you end up with a definition you can read, share, argue with and reuse — which matters when a result is questioned six months later.
Making it your customers, not the public
Most groups you care about are not the general public. They are your buyers, your lapsed subscribers, the people who considered you and went elsewhere.
The strongest thing you can do, and the easiest, is tell us the shape of that group. If you know your buyers are 61% women, skew under 35, are mostly suburban and cluster in a particular income band, that is enough. The population is reweighted until it matches you on every dimension you named. The people are still real survey respondents; the mix is now yours.
This is worth doing before anything else, because:
- You almost certainly already have these numbers.
- No customer records change hands, so there is nothing to consent, transfer or delete.
- It changes the answer more than any other adjustment available to you.
Going further with your own data
When the shape is not enough, you can bring records. Two levels:
Add what you know about behaviour. Upload data and map your columns to what we hold — purchase frequency, tenure, category mix. That behaviour is attached to the twins whose profiles match, so the group behaves like your customers and not just looks like them.
Use your customers directly. Where you hold rich records with a lawful basis for this use, your customers become the twins. This is the highest groundedness available and the only case where "twins of your customers" is literally accurate. Twins built this way belong to your workspace and are never visible to anyone else.
Your own research
Interview transcripts, sales call notes, support tickets, review corpora. These are used to measure your group and to sharpen the environment — what your customers actually talk about, in the words they use, and how you and your competitors come up. What they are not used for is putting one person's quote into a different twin's mouth. See Source.
Checking the group you built
Every build reports back:
- Composition against target. Every dimension you asked it to match, side by side with what it achieved.
- Thin spots. Where a slice of your population rests on very few real people. Stated plainly — "3% of your population rests on 11 people" — because that quietly widens the uncertainty on your results.
- Groundedness. How much real evidence stands behind these people.
- Anything we could not support, and what was done instead.
- Ten twins, rendered in full. Read them. Nothing catches a population that is subtly not your customer faster than a person saying "that isn't them."
Versions
Editing a population creates a new version rather than changing the old one. Simulations stay pinned to the version they ran against, so an old result keeps meaning what it meant and a comparison is never contaminated by the group having moved.