​

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. A transactional email carries the footer link only when its opens and clicks are measured for that recipient — never the one-click header.
• The preference centre offers three choices: keep receiving, keep receiving without measurement, or unsubscribe from all — which also refuses measurement. It speaks the reader’s language: English, French, Italian or Spanish.
• The recipient’s own refusal of measurement prevails over your organisation’s declaration and over any consent your backend passed on. Only the person can remove it.
• Before every send, two layers run in order: suppression (hard, organisation-wide, fail-closed), then subscription preferences (promotional only). Refusing measurement never removes anyone from a send.
• 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 preference centre

Every promotional email — and every transactional email whose opens and clicks are measured — leads to a hosted page where the person manages what they receive from you, and whether it is measured. 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.
• Keep receiving these emails, with a box: Don’t measure whether I open my emails or what I click. Ticked, their emails keep arriving, and neither their opens nor their clicks are recorded. See the recipient’s own choice.
• 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. Unsubscribing from all also refuses measurement; re-subscribing does not switch measurement back on — only the box does.
• 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.
• Their language: the page follows the language their browser prefers among English, French, Italian and Spanish, and falls back to English.

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. Opening the page never changes anything. Mail security scanners follow the links in emails before the person does; only a click on a box or a button records a choice.

​

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 recipient’s own choice on measurement

Your organisation declares who may be measured, and your backend can pass on each person’s consent or refusal. The preference centre adds the one voice missing from that picture: the person’s own, expressed from the email itself.

• A refusal from the preference centre prevails over everything else. It takes the person out of the measurement under every state of your declaration, whatever your backend passed on before or passes on afterwards: a later setMeasurementConsent() with consented: true is recorded, but does not switch measurement back on.
• It covers every record of the person in your organisation, and emails already in their inbox too: their opens and clicks stop being recorded from that moment, while the links keep taking them to the right page.
• Unticking the box only removes their own refusal. The person is then measured — or not — according to your declaration and what your backend passed on, exactly as before. The page never offers “measure me”: a person nobody else measures never becomes measured from it.
• It never removes anyone from a send. Receipts, alerts and the categories they kept all still arrive.
• You learn about it in two places. Under All my recipients have consented, your production open and click figures are marked partial as soon as one production recipient has refused. And the refusal, with its date, appears in that person’s right-of-access export as recipientMeasurementRefusal — on the records attached to their audience: a person Notifizz only knows from the link itself has no audience to export until identify() links that address to the person.

This is what the statements your organisation certifies already promise: a choice expressed by the recipient always prevails over the declaration.

​

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. Your organisation can’t change a person’s preferences on their behalf: only the person does, from the preference page or the notification center. What your organisation can do is add an address to the suppression list — which blocks more, never less. So it can never silently overwrite a person’s own decision — and the same holds for a refusal of measurement: your backend cannot lift it.

​

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. Five 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 — and, through Notifizz’s own unsubscribe link and header, measurement is refused along with it; nothing asks them to confirm on a landing page. It is idempotent, and the unsubscription is reversible from the preference centre.
• The link is server-derived, one per email. It is built at render time for the person the email goes to, and sealed — encrypted and authenticated with a key only Notifizz holds — so the campaign’s AI orchestrator can neither produce it nor override it, and an altered link opens nothing. On a promotional email, the footer and the one-click header carry the very same link; a link pasted into your content never replaces the recipient’s own footer. A personalisation bug can break many things; it cannot break somebody’s opt-out.
• The link keeps working for as long as the email sits in the inbox. It carries what the preference centre needs — the campaign and the category the email was sent under, the person as a one-way fingerprint and a masked address, never the address itself — so it does not depend on the email’s content, which your message retention clears on its own schedule.
• A promotional email always ships with a working opt-out. If the template carries no unsubscribe link, a footer reading Unsubscribe or manage preferences 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.
• No measurement without a way to refuse it, in the email itself. A transactional email carries Notifizz’s preferences footer, Unsubscribe or manage preferences, if and only if its open pixel does; your layout’s own unsubscribe link never ships on a transactional email. An email that is not measured is not click-tracked either: its links point straight at their destination, so a later change of consent can never record a click on it. On a promotional email, the label of the placeholder link is yours: since that link also leads to the measurement choice, word it for both — Unsubscribe or manage preferences, as the appended footer does.

​

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; or, on any channel, you erased the person after the sequence started (see privacy friendly). Shown as Blocked (bounce, spam or erasure).
• 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

​

See also