Skip to main content

​
Notification preferences

Consent is not a checkbox your code carries around. In Notifizz it is a small system: you name the kinds of message you send, your subscribers choose which ones they want, and the platform applies those choices before every single send — without your orchestrator having to know. Three roles meet on this page. Marketing defines the categories and lives with the four-category cap. Dev needs to know what is enforced, in what order, and what a dropped recipient looks like in the statistics. Ops answers the person who says they unsubscribed and got mail anyway.

​
TL;DR

  • Two kinds of category: transactional (mandatory, never opt-out-able) and promotional (optional). Defined once per organisation, shared by every environment.
  • At most four promotional categories. The cap is deliberate — beyond it the opt-out page pushes people to unsubscribe from everything.
  • Every promotional email carries a one-click unsubscribe and a footer link to a hosted preference centre, themed with your Brand Kit. Transactional email carries neither.
  • Before every send, two layers run in order: suppression (hard, organisation-wide, fail-closed), then subscription preferences (promotional only).
  • Absent means subscribed. Preferences are an opt-out model; a person who never touched the page receives everything.
  • Nothing is swallowed: recipients dropped for consent are counted in the campaign’s statistics, by reason.

​
Categories

A category answers one question: why is this message being sent? That single answer decides whether the person may refuse it.

​
The two types

The split is not cosmetic. It decides three separate behaviours — whether the message can be refused, whether it ships with an opt-out surface, and where it sits in the sending order — from one declaration.

​
Where categories are defined

Settings → Subscribers & privacy → Unsubscribe categories. Each category carries a name and an optional description, and both are shown to your subscribers on the preference centre — write them for the reader, not for your backlog. Weekly digest and Product announcements are categories; Campaign batch 3 is not. Categories are per organisation, not per environment: the same set applies to production, staging and every sandbox, so a preference expressed once is understood everywhere. Two constraints worth knowing before you start naming things:
  • The type is fixed at creation. You can rename a category and rewrite its description afterwards; you cannot turn a promotional category into a transactional one. Promoting a message people opted out of into a category they cannot refuse is precisely the move the platform will not let you make quietly.
  • Deleting a category is not blocked by the campaigns that reference it. Repoint those campaigns first, or you leave them pointing at a category nobody can see or manage any more.

​
Why only four promotional categories

Because the fifth one costs you subscribers. The cap exists to protect the page the subscriber actually reads. Past roughly four choices, a preference centre stops being a menu and becomes a wall of switches — and the reliable human response to a wall of switches is the big button at the bottom that turns everything off. Worse, a long list of narrow categories is a recognised unsubscribe-evasion pattern: it looks like choice while making a full opt-out tiring to express. The API refuses the fifth promotional category outright, and the settings screen tells you the count as you go (Promotional · 3/4). Transactional categories are uncapped — they never appear on the page, so they cannot crowd it. Start with two or three broad groups and split further only if you see real opt-out friction. Fragmenting early is easy; merging categories once people have expressed preferences against them is not.

​
Attaching a category to a campaign

A campaign carries a campaign category, chosen in its category editor: So the named categories you define are attached to Product campaigns. A transactional campaign never carries one, and a marketing broadcast is governed by the global promotional opt-out rather than by a theme.
The campaign category and its named sub-category can only be changed while the campaign is in Editing. Once it has moved on, the classification is frozen — create a new editing version to change it. Consent classification is not something to flip under a Live campaign.

​
The preference centre

Every promotional email leads to a hosted page where the person manages what they receive from you. You do not build it, host it, or link it by hand.

​
What the subscriber sees

  • Their address, masked — a•••@example.com. Enough to confirm which inbox they are managing, never enough for the page to leak an address to whoever opens the link.
  • One row per promotional category, with its name and description, and a checkbox. The category the email they just received belongs to is highlighted, so the obvious action is to silence that theme rather than everything.
  • A single button: Unsubscribe from all, or Re-subscribe if they are already opted out of everything.
  • Your logo, brand name and colours, taken from the global Brand Kit. The page is never an unstyled orphan page that looks like a phishing attempt.
Turning off everything shows an explicit reassurance rather than leaving them guessing: they still receive transactional messages — receipts, security alerts — and the per-category switches go quiet until they re-subscribe.

​
Two states that are not failures

Both are deliberate. A page that explained exactly why a token failed would be a probing tool, and a page that let a suppressed address re-subscribe itself would undo a legal obligation with a mouse click.

​
The opt-out model

A category the person has never touched counts as subscribed. Preferences store refusals, not consents — so a category you add tomorrow is on by default for everybody, and nobody has to revisit the page to keep receiving what they already receive. Two consequences to hold on to:
  • Unsubscribe from all is recorded as a global promotional refusal and is honoured across your whole organisation — a person who opts out in one place is not reachable from another environment.
  • Updating preferences merges, never replaces. Changing one category leaves every other choice standing. The dashboard-side write and the subscriber-side write behave identically here, so your organisation can never silently overwrite a person’s own decision.

​
One-click unsubscribe

Promotional email also carries the opt-out in its headers — the one-click standard (RFC 8058) that Gmail, Yahoo and the other large mailbox providers now expect from bulk senders, and surface as their own Unsubscribe affordance next to the sender name. Three properties are worth spelling out:
  • One click means one click. The mailbox provider posts the opt-out and the person is unsubscribed from all promotional email; nothing asks them to confirm on a landing page. It is idempotent, and it is reversible from the preference centre.
  • The link is server-derived, per message. It is built at render time from the message itself and signed — the campaign’s AI orchestrator can neither produce it nor override it. A personalisation bug can break many things; it cannot break somebody’s opt-out.
  • A promotional email always ships with a working opt-out. If the template carries no unsubscribe link, a footer is appended deterministically. Templates you author must place the reserved unsubscribe placeholder exactly once, and never a hardcoded URL — the editor refuses the layout otherwise, because a hardcoded link would ship verbatim on a transactional send and never resolve to the recipient’s real opt-out.

​
What is checked before every send

Consent is enforced by the platform, after the campaign’s orchestrator has produced its recipient list and before fan-out — recipient by recipient. You do not re-implement it. On email, two layers run in this order: Suppression is checked first and always wins — a hard suppression overrides any preference, and the check is fail-closed: if the list cannot be read, the recipient is dropped rather than emailed. Emailing a suppressed address because of a transient glitch is the one failure that cannot be taken back. The preference read is deliberately the opposite, fail-open: a transient error must not silently drop a legitimate send. Transactional sends never consult preferences. There is no configuration that makes a password reset opt-out-able, and that is the point of the classification.

​
Other channels

​
Where the drops show up

Nothing disappears quietly. Recipients removed for consent are counted in the campaign’s statistics under their own reasons, next to the other drop causes:
  • suppressed — the address is on the suppression list, with a scope covering this send.
  • unsubscribed — a promotional send, refused by the global opt-out or by the category switch.
A campaign that reached fewer people than you expected is answerable from that breakdown, which is exactly why the reasons are distinct rather than merged into one “skipped” bucket.

​
FAQ

Almost always: it was transactional. A password reset, a receipt or a security alert is sent regardless of any preference, by design and by law in most regimes. Check the campaign’s category on the record in Audience — the campaign history shows which campaign the message came from.
No — the API refuses it, not just the screen. Merge two existing themes, or make the new one transactional if it genuinely completes a user action. If four feels tight, the usual cause is categories named after campaigns rather than after what the subscriber recognises.
No. The preference centre is hosted, themed from your Brand Kit, and linked automatically from every promotional email. There is nothing to deploy and no route to expose on your side.
If they simply opted out, yes — they re-subscribe themselves from the preference centre, using the link from any earlier promotional email. If they are on the suppression list, no: the page is read-only for a suppressed address, and there is no self-service removal. A spam complaint or an erasure request is terminal by design; the other entries age out with the suppression-list retention you configure.
The categories are — they are defined once for the organisation. A global promotional opt-out is honoured organisation-wide, and so is the suppression list. Per-person records themselves are per environment, so testing in a sandbox never touches a production subscriber’s choices.
Nothing stops the deletion, and the campaign keeps its now-dangling reference. The category disappears from the preference centre, so subscribers can no longer express a choice about it. Repoint the campaigns before deleting.
It is complementary, not redundant. The platform layer answers “this person must never be emailed again” — legally, organisation-wide, fail-closed. Your orchestrator answers business questions: not to free-plan accounts, not twice in one month. Keep the second, never re-implement the first: an orchestrator-level opt-out has none of the guarantees this one has.

​
See also

Audience

The per-person record — identities, history, and GDPR requests.

Campaigns

Where a campaign gets its category, and when it can still be changed.

Privacy friendly

Hashing, retention dials, and the suppression list’s legal floor.

Recipients

Where consent sits in the send pipeline, from the developer’s side.