Audience

Audience is the list of people your campaigns have actually reached, one record per person, per environment. Open a record and you see who they are on each channel, what your own systems say about them right now, and what your campaigns sent them — the 100 most recent deliveries, up to 180 days. This page is written for Product and Ops — the people who answer “did this customer get the email?” and “we have a deletion request, what happens now?”. The developer-facing view of the same subject — how a recipient list is produced, validated and filtered before a send — is recipients.

TL;DR

One record per person, per environment. A record appears the first time a notification is delivered to that person; nobody is imported beforehand.
A person can hold several channel identities. An application user id and an email address are separate identities until your code says they belong to the same person — see audience identity.
The profile you see is fetched live from your systems at the moment you open the record. Notifizz stores no traits.
What your campaigns sent the person is listed — the 100 most recent deliveries, up to 180 days —, channel by channel, with what happened to each message, including messages whose content has since been redacted.
This is the surface for a GDPR request. Right of access is a structured export; right to erasure is a one-way purge that also writes the address to the suppression list.
Export and erasure are API operations today — the screen shows the record, it carries no export or erase button.

What lands in the list

A record is created the first time a notification is delivered to someone in that environment. Nothing else creates one: there is no import step, no contact upload, no CRM sync. If a person has never been sent anything in this environment, they are not in the list, and that is the honest answer to “why can’t I find them?”. Each row shows the person’s display name — whatever your profile resolver returned, falling back to their email address, falling back to your own user id — with the address underneath, a channel count when the record holds more than one identity, a badge when one of those identities has an active web push subscription, and the date they were last reached. The list is scoped to one environment at a time — the selector sits at the top of the page. A person reached in production and in your sandbox has two independent records, which is what keeps test traffic out of your production answers.

Audience is a top-level entry in the dashboard sidebar. If you do not see it, it has been hidden from your own sidebar — the sidebar is customisable per user.

One person, several identities

Notifizz separates two things most platforms conflate:

A person — one record, the thing you open on the Audience screen.
A channel identity — how that person is addressable on one channel, in one environment.

Identity type	Identified by	Created when
`AppUserSubject`	Your own user id	A notification goes to a recipient carrying an `id`
`EmailSubject`	The email address — held hashed, plus the plain address until the retention window has passed without a send to the person or a new identity declared for them; after that, Audiences shows it masked. 180 days after the last send to the person or the last time `identify()` created an identity for them, and never before it is masked, the identity is removed, unless the person opted out of something	A notification goes to a recipient known only by their email

The identity API accepts two further types, for a browser identifier and for a custom channel; neither is produced by a delivery today. When a delivery carries both your user id and an email address, one identity is created and it holds both. When the same person is reached later by email alone — a mailing built from a different source, say — a second, unrelated identity appears, and the list shows two rows for what you know to be one human being. Once the two are linked, they collapse into a single row carrying a channel count. Notifizz never guesses that two identities are the same person. Merging is declared: your backend calls identify(), and only then do the two records become one. That is a deliberate refusal of probabilistic matching, which is fragile, hard to audit, and risks showing one person’s notification to another. The developer reference is in the SDK pages — Node, Java, PHP. Every link and every effective unlink is journaled with the actor, the source and the moment — the accountability trail a regulator asks for when you claim two identities were the same person.

Reading a record

Opening a row shows a header — the person’s name and address as far as they can be resolved — and then two blocks: what your systems say about them, and what Notifizz has sent them.

The live profile

Notifizz holds no customer traits — no name, no plan, no segment, no custom fields. To show you a real profile, the record calls a resolver your backend exposes, at the moment you open it, and displays whatever it returns. You declare it once in your backend SDK:

notifizz.enrichProfileData({
  handler: async ({ id, email }) => {
    const user = await db.users.findByIdOrEmail(id, email);
    return {
      name: user.fullName,
      plan: user.plan,
      locale: user.locale,
      signedUpAt: user.createdAt,
    };
  },
});

The resolver receives { id, email } — one person per call — and returns whatever fields you want on screen. Responses are cached for 24 hours, so opening the same record twice in an afternoon does not hammer your database. Three states, and the screen tells you which one you are in:

State	What you see
No resolver declared	A placeholder with a Configure enricher button that shows the snippet to add
Resolver declared, returned data	The fields, laid out as a grid
Resolver declared, returned nothing for this person	A one-line note saying exactly that — the call succeeded, the person is unknown to your systems; for a person known only by a masked address, no call is made — the next send restores the address

The distinction in the third row matters: “your resolver has nothing on them” and “you have no resolver” are different problems, and conflating them sends you debugging the wrong one.

Campaign history

The campaigns that reached this person, each with its current status, and one line per message underneath: which channel, how far the message got — Sent, Opened, Clicked, Read, or Failed with its reason — and the date it went out. This is the answer to “did they get it?”, per person, without going through the whole delivery history. What it covers, precisely:

The 100 most recent deliveries, up to 180 days. A person who received more than 100 messages in that period is shown the latest 100; there is no further page. An email or a web push leaves the history when it is deleted, 180 days after sending — or later, if your organisation keeps message content longer than that. An in-app inbox message is listed for as long as it is kept.
Redacted messages stay listed. Past messageRetentionDays (7 days by default), an email or a web push is redacted: it no longer names the person, but Notifizz still recognises it as theirs through a one-way reference. Its line stays — campaign, channel, status, date. The history never showed message content, and does not now.
An email stops being measured when it is redacted. An open on a redacted email is not recorded, so its line keeps the status it had at that moment: a Sent can hide an open from the eighth day. The line of an email or a web push never shows a click — clicks are counted in your campaign statistics, where a click on a redacted web push still counts.
After an unlink. When identify() merges two records, the history shows what was sent to both, redacted messages included. detach() usually corrects a mistaken merge, and it forgets every merge into the record the identity leaves, since nothing records which merge brought which identity. Redacted messages sent before a merge — to the detached identity, or to any other record merged into the one it leaves, in good faith or not — are then listed in no history. Messages sent to the detached identity while the mistaken merge was in place follow it as long as they name it; once redacted, they name no one and stay with the record it left.
After erasing one identity. Erasing a single identity takes the messages addressed to it, and leaves the person their redacted messages. The history can then list older messages and none of the recent ones sent to the erased identity.

Finding someone

The search box takes an exact email address or an exact user id from your own system — whichever the requester gave you. It matches the records that hold that address or user id — usually exactly one; when several of your users hold the same address, each of them is listed. An address is never attached to a second user once another holds it, so someone who shares a mailbox with another of your users is found by their user id, not by the address. It is not a fuzzy search, and it does not search the profile fields your resolver returns (those are fetched per record, not indexed). The address finds a person for 180 days after the last send to them — or the last time identify() created an identity for them; linking two records that already exist does not restart it — and never stops before the address is masked. Past that, a person known only by their address is no longer on file, and a person you identify is found by your user id only — unless they opted out of something, which keeps them findable by their address for as long as the opt-out stands. See hashed address lifecycle. Search is scoped to the selected environment, like the rest of the page. A support request that says “I never got the reset email” is answered in the production environment; the same address in your sandbox is a different record.

Answering a right-of-access request

GDPR Article 15 asks you to tell a person what you hold about them. The export endpoint returns their record — their identities and their preferences:

GET /v1/audiences/{audienceId}/export?environmentId={environmentId}

The audienceId is in the address bar once you open the person’s record, together with the environment.

{
  "audienceId": "…",
  "exportedAt": 1755859200000,
  "subjects": [
    {
      "subjectId": "sbj_…",
      "type": "AppUserSubject",
      "identifier": "u_8421",
      "clientIdHash": "…",
      "firstSeenAt": 1748736000000,
      "lastSeenAt": 1755772800000,
      "subscriptions": { "cat_…": { "email": false, "inApp": true } },
      "promotionalOptOut": null,
      "measurementConsent": { "value": "refused", "at": 1755600000000 },
      "recipientMeasurementRefusal": null
    },
    {
      "subjectId": "sbj_…",
      "type": "EmailSubject",
      "identifier": "alice@example.com",
      "identifierHash": "…",
      "identifierClear": "alice@example.com",
      "firstSeenAt": 1748736000000,
      "lastSeenAt": 1755772800000,
      "subscriptions": {},
      "promotionalOptOut": null,
      "measurementConsent": { "value": "refused", "at": 1755600000000 },
      "recipientMeasurementRefusal": null
    }
  ]
}

Read it as: one entry per channel identity, each carrying its identifier, when it was first and last seen, its subscription choices, its promotional opt-out and its measurement consent. Notifizz records no legal basis of its own: as the controller, your organisation holds the basis on which it contacts the person. A few details are worth understanding before you forward it to a requester:

identifierHash and identifierClear belong to an address. Every identity that holds one carries them: an email identity always, your user id too when an address was linked to it. An identity without an address carries only the identifier it is addressed by. An entry without those two fields is not a truncated export.
A user-id identity also carries clientIdHash, the pseudonymised form under which Notifizz stores your user id. identifier is the value the person can recognise.
identifierClear is present only while the plain address is still held. Once the address is masked — the retention window has passed without a send to the person — only identifierHash remains and identifier shows the masked form; an export that shows a hash and no address is not a bug. A new send makes the address readable again — see plain email lifecycle. 180 days after the last send to the person or the last time identify() created an identity for them, the hash goes too, unless the person opted out of something: a user-id identity then carries neither field, and an email identity is no longer on file.
measurementConsent is the answer your backend passed on with setMeasurementConsent(), as recorded on that identity — "granted" or "refused", and at, the date it last changed. See open and click measurement. recipientMeasurementRefusal is the refusal the person expressed themselves from the email footer, with its date; it wins over anything your backend passed on. promotionalOptOut is the person’s refusal of all promotional messages, per channel. All three are present on every identity: null means that identity carries no such answer, not that a field was left out.
An answer given for an address not yet linked to the person is not in it. A consent or refusal your backend passed on for an email address Notifizz had never seen, or a choice made from the link in an email before that address was attached to anyone, is kept with the address alone. It appears in the person’s export once you link the address to them with identify().
The export covers identities and preferences. The delivery detail — which campaign, which channel, what happened — is the campaign history on the record itself: the 100 most recent deliveries, up to 180 days, redacted messages included. Message content past its own retention window has been redacted. Timestamps are epoch milliseconds.

The policy behind all of that — what is stored, hashed, redacted, and for how long — is privacy friendly.

Answering an erasure request

GDPR Article 17 asks you to remove the person. Three routes, depending on how much you are erasing:

Route	Erases
`DELETE /v1/audiences/{audienceId}?environmentId={environmentId}`	The whole person — every channel identity, every subscription
`DELETE /v1/subjects/{subjectId}`	One channel identity
`DELETE /v1/subjects/by-external-id/{externalId}?environmentId={environmentId}`	One channel identity, addressed by your user id

Erasing the whole person removes, in one pass: the channel identities, their subscription choices, the delivery history held for them, their rows in campaign statistics — the “Who converted” list, objective evaluations —, and any web push subscriptions registered against their identity. It also stops every sequence already running for them: a step still to play writes to them on no channel, and creates no new record — see privacy friendly. A person who has not received anything yet has no record: erasing them by your user id answers 403, and still stops the sequences already started for them. The response reports the counts — identities and subscription entries — and whether the suppression list was updated, so the operation leaves you something to file. An email address is not a person, and erasure treats it that way: the messages sent to the erased person’s address go too, except those addressed to another of your users who is still on file, in any environment — two of your users sharing a mailbox never lose each other’s history. The address itself, though, goes on the suppression list when Notifizz still has it on file: from then on no email reaches it, whichever of your users it is sent to. A person you identify whose hashed address reached its term no longer has an address on file, so erasing them blocks no address — see hashed address lifecycle. Campaign statistics follow the same rule: a conversion recorded at that address by another of your users still on file is kept. An erasure that meets an identity change on the same person at the same moment — a link or an unlink from your backend — answers 409 with identity_concurrent_update: nothing was erased, and the call is safe to repeat at once. An erasure is always whole or nothing. Erasing a single identity keeps the rest of the person: the running sequences stop for the erased user id only, and keep reaching the person under their other identities. If it was the last one, the person’s record goes too; otherwise the record’s counters are recomputed so it keeps telling the truth.

Erasure writes to the suppression list, and it is one-way. Before purging, the hash of every address still on file for the person is written to the suppression list for the configured number of years. This is deliberate: a person erased today must not be emailed again tomorrow because a fresh import reintroduced them. The address itself is gone — a hash cannot be emailed. An erasure-driven suppression is never lifted programmatically.

These are console operations, not SDK calls. The export and erasure routes authenticate as a signed-in member of your organisation — the same session the dashboard uses — not with an SDK key. There is no SDK shorthand for erasure, and no export or erase button on the Audience screen today.

Erasure is not an unsubscribe

They answer different questions and they are not interchangeable:

	Unsubscribe	Erasure
What the person asked	Stop sending me this kind of message	Remove me
What survives	The whole record, minus a preference — and its hashed address, for as long as the opt-out stands	The hash of each address still on file, on the suppression list, and — for as long as a sequence that started before the erasure is still running — a hash of your user id that stops those sequences
Transactional mail	Still delivered	Blocked as well
Reversible	Yes, from the preference centre	No

A person who unsubscribes should not be erased — you would destroy the delivery history you may need to prove you honoured them. See notification preferences.

What the record does not hold

No traits. Name, plan, segment, custom fields — fetched live when you open the record, never stored.
No profile graph. Beyond the channel identities and their declared links, there is nothing to browse.
No cross-organisation correlation. Email hashes are scoped to your organisation: the same address in another Notifizz customer’s account produces an unrelated hash.
No inferred identity. Two identities become one person because your code declared it, never because two payloads looked alike.

FAQ

Someone contacted support saying they never got an email. Where do I start?

Search their address in the production environment, then their user id from your system. If neither finds a record, no notification was ever tracked for them — the question moves upstream, to the campaign and its recipient resolution. (An address already held by another of your users is never attached to a second one, so someone sharing a mailbox is found by their user id.) If there is a record, the campaign history says whether a message went out, on which channel, and what became of it — among the 100 most recent deliveries, up to 180 days. A message beyond those 100 still exists but is not shown; an email or a web push sent more than 180 days ago has been deleted (later only if your organisation keeps message content longer).

The same person appears twice. Why?

They hold two channel identities that have never been declared as the same person — typically an application user id from one campaign and a bare email address from another. Call identify() from your backend to merge them; the two records become one, and the counters are recombined.

The profile section is empty but I did declare a resolver.

Either the call succeeded and returned nothing for this person, or the person’s address has been masked and there was nothing to send: a person known only by a masked address is not looked up at all, and a person known by your user id is looked up without the address. The next send restores the address. Otherwise, check that the identifier the record holds is the one your resolver looks up: it receives { id, email }, and a resolver keyed on an internal id will find nothing for someone known only by their address.

Can I edit someone's preferences from the record?

No. Preferences are the person’s own: they change them from the hosted preference centre reached from any promotional email, or from the notification center — see notification preferences. Your organisation has no way to set them on their behalf; the record is a read surface.

Does erasing someone remove them from campaign statistics?

Yes, from everything that names them: their delivery history, their entry in the “Who converted” list, their objective evaluations, and the records that keep their unique opens and conversions from counting twice. One exception: once a person’s address has been masked, their conversions and objective evaluations that name them only by that address — not by your user id — stay until their own term; erasure no longer holds the address to find them by. Rows reached through a shared address but belonging to another of your users still on file are kept. The counters themselves are not rewritten — a campaign that counted their conversion still counts it, and the list shows one person fewer. The event log behind those counters is left in place and deleted on its own after about three to four months — see privacy friendly.

Why is the list per environment rather than per organisation?

Because a person reached in a sandbox is test traffic, and mixing it into the production answer would make every support and compliance question ambiguous. The suppression list is the deliberate exception: it applies across the whole organisation, so an entry on it — a hard bounce, a spam complaint, an erasure, or an address your organisation added — blocks that address in every environment for as long as the entry lasts. An unsubscribe is not one of those entries: it is recorded on the person’s own preferences — see notification preferences.

Notification preferences

Categories, the hosted preference centre, and what is checked before every send.

Privacy friendly

What is stored, hashed, redacted — and the retention dials behind it.

Recipients

The developer view: how a recipient list is produced and filtered.

Delivery history & stats

The campaign-wide view of the same deliveries.

Get started

Concepts

Use cases

SDKs

AI & MCP

Environments

Plans & usage

Monitor delivery

Glossary

Audience — The Person Behind Your Sends

Audience

TL;DR

What lands in the list

One person, several identities

Reading a record

The live profile

Campaign history

Finding someone

Answering a right-of-access request

Answering an erasure request

Erasure is not an unsubscribe

What the record does not hold

FAQ

See also

Notification preferences

Privacy friendly

Recipients

Delivery history & stats

​Audience

​TL;DR

​What lands in the list

​One person, several identities

​Reading a record

​The live profile

​Campaign history

​Finding someone

​Answering a right-of-access request

​Answering an erasure request

​Erasure is not an unsubscribe

​What the record does not hold

​FAQ

​See also

Notification preferences

Privacy friendly

Recipients

Delivery history & stats

Audience

TL;DR

What lands in the list

One person, several identities

Reading a record

The live profile

Campaign history

Finding someone

Answering a right-of-access request

Answering an erasure request

Erasure is not an unsubscribe

What the record does not hold

FAQ

See also