​

Privacy friendly

​

TL;DR

• No warehouse sync. Customer profiles stay in your systems. The orchestrator fetches what it needs at notification time via enrichers — never copies it.
• Plain email is bounded by a window (default 90 days without a send to the person, configurable down to 7). Past it, the address is masked in Audiences, and what outlives it there is a keyed hash (HMAC), scoped to your organisation — enough to find the person by typing their address, to de-duplicate and to honour a past unsubscribe, never enough to email again. The next send makes the address readable again — see plain email lifecycle. The hash has a term too: 180 days after the last send to the person — or the last time identify() created an identity for them —, and never before the address is masked, a person known only by their address is removed, and a person known by your user id keeps only that id — except anyone who opted out of something, who keeps their hash for as long as the opt-out stands. Copies kept elsewhere — an in-app inbox message that displays the address, the exceptions listed under erasure — follow their own term.
• Expired messages are redacted, not deleted. Everything that names the person is emptied; the delivery record survives so your Outbox keeps telling the truth about what shipped. It keeps a one-way reference to the person, used only to honour access and erasure requests — the person’s campaign history, shown to your team —, to attribute conversions and to count each person once in your campaign statistics (aggregated, never shown per person), until it is deleted 180 days after sending.
• The enricher cache is bounded, not a sync. Per (org, env, enricher, params) keying with a TTL declared at registration. Eviction is automatic; only recently used records exist.
• Five retention dials, configured per organisation, with conservative GDPR-aligned defaults and platform-enforced bounds.
• Email opens and clicks are measured only with consent. Only recipients covered by your organisation’s declaration are measured — everyone under All my recipients have consented, the people whose consent your backend passed on under Only those who consented — and never someone who refused, whether your backend passed the refusal on or the person gave it from an email. Until your organisation declares, production emails carry no open pixel and record no opens or clicks; links and unsubscribe keep working. See open and click measurement.

​

Why it matters

​

The three pillars

​

1. Enrichers — no warehouse copy

client.enricher("fetchUser", {
  input: z.object({ userId: z.string() }),
  output: z.object({ id: z.string(), email: z.string(), plan: z.string() }),
  cache: { ttl: "1h" },
  handler: async ({ userId }) => {
    const user = await db.users.findOne({ id: userId });
    return { id: user.id, email: user.email, plan: user.plan };
  },
});

• Privacy surface stays in your systems. Notifizz processes; you store.
• No drift. The user’s email is whatever your DB returns at notification time, not what last night’s sync ran with.
• No schema migration. New attribute? Add a field to the enricher’s output. Renamed? One file changes.

​

2. Email hashing — plain text only when needed

​

Normalisation, then hash

​

Plain email lifecycle

​

Hashed address lifecycle

• A person known only by their address is removed — their record, its hash and their preferences. Their Audience goes with it when nothing else is left in it, and so do the statistics records that carry only the person’s one-way reference: the markers that keep a unique open or a conversion from counting twice, the records that stop a sequence once its objective is reached, and the entries of the “Who converted” list that name no one, even before their own term. A measurement consent you sent by address, kept without an Audience, stays as long as another record in its environment holds the same address; an opt-out, wherever it is recorded, is kept for as long as it stands (below).
• A person known by your user id keeps the user id and loses the hashed address. Audiences shows them by your user id, and searching by the address no longer finds them.

​

3. Cache — bounded, not a sync

​

What Notifizz stores — and what it doesn’t

​

Retention configuration

​

Set by the platform

​

Redaction

​

What a redacted record still points to

• Access goes all the way. The person’s campaign history — on their record in Audiences, shown to your team, and your answer to a right-of-access request for what was sent — lists their redacted records alongside the others: campaign, channel, status and date, never the content. That is the 100 most recent deliveries, up to 180 days.
• Erasure goes all the way. When you erase a person — the whole person, or the last channel identity they had — their redacted records are found through the reference and deleted with them, instead of waiting out their 180 days. So are the statistics records that carry only the reference: the markers that keep a unique open or a conversion from counting twice, and the records that stop a sequence once its objective is reached.
• Conversions are attributed. When one of your events reports that the person converted, Notifizz still recognises them as someone the campaign wrote to after the message is redacted, and a sequence set to end when the objective is reached stops for them — for as long as the record exists, up to 180 days after sending. That window follows the record and is not configurable.
• Statistics count people, not records. Your campaign statistics recognise the person behind a redacted record through the reference, so a person still counts once after redaction: a click on a redacted web push counts under them, and the delivery figures of a run in the Outbox or of a broadcast report count people, not records. These figures are aggregated: the reference is never shown per person.

​

Measurement after redaction

• An email is no longer measured. An open or a click on a redacted email is not recorded, whatever your organisation declared for open and click measurement: the record no longer says who received it, so Notifizz can no longer check that this person may be measured. Its links keep working, and its line in the person’s campaign history keeps the status it had when it was redacted.
• A web push is still measured. Its clicks keep counting. The reason email stops does not apply here: the measurement setting covers email only.

​

Suppression and right to be forgotten

• Unsubscribe, from the link in an email or the one-click header → recorded on the person’s own subscription preferences, not on the suppression list. Before a promotional send, the incoming address is hashed and matched against those preferences, so the plain email is not needed. The opt-out holds until the person re-subscribes from the preference centre; transactional mail still goes out.
• Spam complaint, hard bounce, or an address your organisation adds itself → the email is hashed and added to the per-org suppression list. Subsequent sends hash the incoming address and check the list before dispatch. The plain email is not retained. Each entry is kept for a set number of years, then removed; a bounce is lifted earlier if the provider reactivates the address.
• Right to erasure → declared by your system as part of your own user-deletion flow. Three routes, depending on what you are erasing:

• the event log behind your counters, about three to four months (see the table above);
• what the internal queues still hold for them — a send, or the event behind a reminder or a digest: about two days after that work finished (see the table above);
• 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 — until their own term; erasure no longer holds the address to find them by;
• a one-way reference to the erased user id — a keyed hash, never the id — that stops the sequences already running for them (below), for as long as a sequence that started before the erasure is still running;
• on a sequence still running for them: the event that started it, and, for each step it still plays, what your enrichers returned about them and which of your conditions applied to them — kept with the sequence: 180 days after it started, or until it ends if that is later;
• an objective evaluation that names the person only through your own event properties, or only by push id or phone number — 180 days;
• the statistics of people erased before this behaviour shipped, in October 2026 — until their retention ends.

• the stop applies in the environment of the erased record — the suppression of the address, above, applies in all your environments;
• a notification already handed to delivery when the erasure happens — typically seconds before it — still goes out, and creates a new record for them;
• a sequence that starts after the erasure, or while it is being processed, counts as a new sequence even when it was set up before: an inactivity reminder or a digest armed before the erasure, or an event you sent just before it and still waiting to be processed, reaches the person;
• a person erased before this behaviour shipped, in October 2026, can still be reached by a sequence that was already running, until that sequence ends.

​

How this composes with the rest

• Enrichers — the no-copy primitive, the largest single reason Notifizz is privacy friendly.
• Recipients — recipients carry only id + email (plus arbitrary fields you control); never absorbed into a profile store.
• Authentication — widget auth modes keep authenticated and anonymous traffic strictly separated, in line with the CNIL January 2026 recommendation.
• Open and click measurement — whether your emails carry an open pixel and record clicks is your organisation’s declared instruction, dated and journaled, closed by default — refined person by person by the consent or refusal your backend passes on.
• Activity log — the audit trail of campaign work. Organisation-level choices — retention dials, open and click measurement — keep their own journals.

​

FAQ

​

See also