Static List
A static list is a fixed group of contacts captured at a point in time that only changes when someone manually adds or removes records.
Key takeaways
- Membership is a stored set of contact identifiers, usually with the date each was added.
- The list survives data model changes because it depends on no field staying populated.
- Global suppression still overrides membership, so unsubscribes and hard bounces are honoured.
- A static list records who was contacted; it is not a record of consent.
- Name every list with a date, or a database of them becomes unauditable sprawl.
In depth
Underneath, membership is a stored set of contact identifiers, usually with the date each one was added. Rows arrive by import, by manual selection, by a workflow action, or as a one-time export from a query that was run on a particular day. Removal is always a deliberate act. Because the list depends on no field staying populated, it survives changes to the data model that would break a rule-based audience: rename a property tomorrow and the membership is unaffected.
The value is immutability and the cost is that nothing propagates. If a contact changes role, leaves the company or stops matching the reason they were added, the list does not notice. Global suppression is the exception, since unsubscribes and hard bounces are honoured at send time regardless of membership. A list exported from a query also inherits whatever that query returned on the day, including any mistake in its logic, which is then frozen alongside the correct rows.
Used well, a static list is the unit of record for one bounded thing: an event, a launch week, an experiment cohort, a specific import. Name it with a date so it can still be identified a year later. In a scorecard funnel it is the right way to freeze everyone who answered a particular version of the quiz, so a comparison of follow-up copy stays valid even after the questions or the scoring bands are changed.
A static list is a poor primary organising structure. Used for anything ongoing it drifts immediately, and a database organised around dozens of them becomes sprawl in which nobody can say which is current. It is also not a permission record. Consent lives on the contact, along with its source and timestamp, so being on a list proves you sent to someone rather than that you were entitled to. Keep those two questions separate, and store the answer to the second one on the record itself.
Example in practice
How to measure it
Because the audience is fixed, rates behave properly across a sequence. The denominator does not move between the first email and the fifth, so a declining click rate is genuine fatigue rather than a changing population, which makes a static list the right basis for any multi-step comparison. Report reach as the share of original members still deliverable, and expect that figure to fall steadily.
Track decay explicitly by re-checking the list before each reuse: how many members now bounce, have opted out, or no longer meet the condition that put them there. When a large minority fails any of those tests, the list has expired as an audience even though it remains perfectly valid as a record of what happened. Keep those two purposes in separate reports.
Common mistakes
The most common misuse is treating a static list as an ongoing audience. A list called Customers, built once, drifts within weeks as accounts churn and new ones arrive, and the team keeps mailing a snapshot of last quarter without noticing. Reserve static lists for things that genuinely finished: an event, a launch week, an experiment cohort. If the group is supposed to keep growing on its own, it needs a rule rather than a stored set.
The other habit is deleting contacts by hand to keep a list tidy, which destroys the one property that made it worth having. Once rows are gone, the list no longer answers who was contacted, and the trail cannot be rebuilt. Leave membership fixed and let global suppression decide who must not be mailed. Undated names compound the problem, since three lists called Webinar Attendees cannot be told apart six months later.
Frequently asked questions
Do contacts ever leave a static list on their own?
No. Membership only changes through manual edits, imports, or workflow actions you explicitly configure. That is exactly why static lists can drift out of date if not maintained.
When should I use a static list instead of a smart list?
Use a static list whenever the group is defined by something that already happened: attending a webinar, being part of a test, arriving in a particular import. Use a smart list when membership should follow current data. The question to ask is whether you want the same people next month, or the people who match next month.
Do unsubscribes apply to contacts on a static list?
Yes. Opt-outs and hard bounces are enforced at send time through global suppression, which sits above any list membership, so an unsubscribed contact still on the list will not be mailed. That is why you should never delete rows manually to honour an opt-out; the platform already handles it and the record stays intact.
How do contacts get added to a static list?
Through a file import, a manual selection in the interface, an automation step that adds a contact when something happens, or a one-time export from a filtered view. The last route is the most common and the most easily misread, because the result reflects the filter as it stood on that day, not as it stands now.
How long does a static list stay usable?
As an audience, only as long as the reason for building it stays true, which for business contacts is often a matter of months. As a record of what was sent, indefinitely. Re-verify deliverability before reusing one that is more than a quarter old, since address decay alone will have removed a noticeable slice.
Can I turn a smart list into a static list?
Yes, and it is a routine operation: export the current members and save them as a fixed list, which freezes the query result at that moment. Do this before reporting on a campaign or before running an experiment, so the cohort you analyse afterwards is exactly the cohort you sent to.
Is a static list proof that contacts consented?
No. Consent belongs on the contact record together with its source, timestamp and wording, because that is what a compliance question asks about. A list only shows that a contact was included in a send. Keep the two separate, and never infer permission from membership in a list somebody assembled by hand.