> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Open and Click Measurement — Recipient Consent
> Whether your emails carry an open pixel and record who clicked is decided by your organisation's consent declaration and by the consent your backend passes on for each person. Three states, a refusal that always wins, a dated journal, sandbox testers who consent for themselves, and what changes on your numbers.
# Open and click measurement
An email can tell you two things about the person who received it: that **they** opened it (an invisible image, the open pixel, loads when the email is displayed) and that **they** clicked a given link (the link goes through Notifizz first, which notes who followed it). European rules treat both as trackers: measuring an individual's opens and clicks requires that person's prior consent.
Your organisation collects that consent — the recipients are your customers. Notifizz does not collect it and never guesses it: it applies your instructions to every email it sends. There are two of them: one organisation setting, declared by a person on your team, dated and journaled; and, person by person, the consent or refusal your backend passes on.
Three roles meet on this page. **Marketing** makes the declaration and reads the numbers. **Dev** passes on each person's consent, and needs to know what is in the email and what is recorded. **Product / Ops** answers "why did our open rate drop?".
## TL;DR
* One organisation setting, three states: **Not declared** (the starting point), **Only those who consented**, **All my recipients have consented**.
* Your backend passes on each person's consent or refusal with the SDK's `setMeasurementConsent()` — once, when it is given or withdrawn, not on every send.
* Who is measured in production: under **Not declared**, nobody; under **Only those who consented**, the people whose consent you passed on; under **All my recipients have consented**, everyone except the people who refused.
* **A refusal always wins.** It follows the person — designated by email address or by your user id — across all their records, and it also stops the counting on emails already sent.
* **Refusing measurement never removes anyone from a send.** It changes what is observed, never who receives. Links still take the reader to the right page, and unsubscribe always works.
* A member of your team declares, in the dashboard, under **Settings → Subscribers & privacy → Opens & clicks**. Both *Only those who consented* and *All my recipients have consented* are certifications; every answer is appended to a journal, with the version of the wording that was on screen.
* **Organisations that existed before this setting start as Not declared**: nothing is measured until someone declares.
* **Sandbox testers consent for themselves**, on the page that verifies their address — a separate box, unticked by default.
* Two separate facts about your numbers: opens are a **noisy statistic everywhere**; and your **measured** numbers will be **lower**, because recipients who did not consent are not counted.
* Where nothing was measured, statistics say **Not measured**, never 0 %; where only some recipients were, the figure is marked **partial**. `Click` and `Read` objectives become **partial**; objectives on your own business events are unaffected.
## Why consent is required
The open pixel is unique to each email, so its loading says *this person opened this email, at this time*. A link that goes through Notifizz says *this person clicked this link*. European data protection authorities read the ePrivacy rules as covering both — pixels in emails and per-recipient links are named explicitly. Several national regulators, in France and Italy among others, require **prior consent** to measure them per person, and the French regulator has explicitly ruled out legitimate interest as a basis, B2B email included.
The roles follow from who the recipients are:
| | Your organisation | Notifizz |
| - | - | - |
| Role for your recipients' data | **Controller** | **Processor** |
| Collects consent to measurement | Yes — in your product, your forms, your contracts | No |
| Decides what is measured | Yes — through this setting, and the consent it passes on for each person | No |
| Applies the decision on every email | — | Yes, closed by default |
Regulators also expect the sending platform not to emit a measurement request without a consent signal. That is why the default is closed: silence, an abandoned onboarding or a skipped screen all mean **no measurement**.
**Consenting to receive and consenting to be measured are two different things.** Whether a person
receives a promotional email is governed by [categories and subscription preferences](/docs/concepts/notification-preferences).
This setting only decides whether the email is measured. A person can receive everything and be
measured on nothing.
## The three states
| State | Who is measured in production | Links reach their destination | Unsubscribe |
| - | - | - | - |
| **Not declared** | Nobody — not even people whose consent you passed on | Yes | Works |
| **Only those who consented** | The people whose consent your backend passed on, unless they refused since | Yes | Works |
| **All my recipients have consented** | Everyone, except the people who refused | Yes | Works |
For a measured recipient, the email carries the open pixel, and their opens and clicks are recorded. For anyone else, the email carries no pixel and nothing is recorded; everything else about the email is the same.
* **Not declared** is where every organisation starts. Nobody is measured, even a person whose consent your backend has already passed on: measuring needs an active instruction from your organisation first. Refusals passed on in the meantime are kept, and apply from the moment someone declares. The dashboard keeps a notice on every screen until someone decides.
* **Only those who consented** measures exactly the people your backend vouched for, one by one. Until you pass on a first consent, it measures nobody. It is a certification: see [the declaration](#the-declaration).
* **All my recipients have consented** measures every production recipient individually, except those who refused. It is a certification too, and the broader one.
## Consent person by person
Whatever the state, your backend can tell Notifizz what a given person decided: they consented to the measurement of their opens and clicks, or they refused it or withdrew it. It is one call to the backend SDK, `setMeasurementConsent()`, available since version 3.0.0 of the [Node](/docs/sdks/event-tracking/node-js#measurement-consent), [Java](/docs/sdks/event-tracking/java#measurement-consent) and [PHP](/docs/sdks/event-tracking/php#measurement-consent) SDKs. The FAQ below shows it.
* **Once, when it changes.** Consent is a lasting property of the person, not of an event: call it when the person gives or withdraws their consent — not on every send, and not as a property of your events.
* **The person, by address or by user id.** You designate them as for `identify()`: by email address or by your own user id. The signal reaches every record Notifizz holds for that person in the environment of your key — including an address you linked to that user id with `identify()`, whether the link came before or after the signal. A person Notifizz has never seen is recorded with the signal: a refusal, or a consent passed on for a user id, applies from their very first email.
* **For the same person, the latest answer replaces the previous one.** A consent passed on after a refusal you passed on switches the person back; a refusal the person [expressed from an email](/docs/concepts/notification-preferences#the-recipients-own-choice-on-measurement) prevails over any consent you pass on. Passing on the same answer again changes nothing, and the date of the last change is kept.
* **A refusal always wins.** Where records disagree — a refusal passed on for an address, a consent for a user id, and the two never linked — the person is not measured. A refusal also stops the counting on emails that already left.
* **A consent is never lent.** It counts only for the person it was given for: another of your users who shares the same address never borrows it. A consent passed on for an email address counts for a person only if you linked that address to them with `identify()`, or if they are the only person among your users who holds it. When an address belongs to several people you have not linked together — several of your users, or one of your users and another address you linked it with — a consent passed on for that address changes no existing answer — the one exception to "the latest answer replaces the previous one". It is only recorded where that address had no answer yet, and then counts at most for the user that address is currently linked to with `identify()`, while that user has no refusal. Every user keeps their own answer, a refusal included — even one passed on earlier for that same address — and while one of them keeps a refusal, emails sent to that address are not measured. To record a consent for one of them, pass it on under their user id. A refusal passed on for that address reaches all of them.
* **Detaching undoes what a merge spread.** While two identities are linked, a consent passed on for one reaches both. `detach()` therefore clears every consent on the records of both sides, the detached one included and whatever its origin — nothing records which link brought which consent — and keeps every refusal. Pass the consents on again, under each user id.
* **Production only.** The call acts in the environment of your SDK secret key. Only production emails reach real recipients, so a call made with a non-production key is accepted and has no effect; sandbox testers [consent for themselves](#sandbox-testers).
* **From your backend only.** The call needs your environment's secret key. There is no browser equivalent: a call from a web page could name anyone.
* **Nothing is asked at send time.** Notifizz applies what you passed on. It never calls your systems about consent when an email leaves.
## What never changes, whatever the state
* **Links keep working.** In a measured email, every link goes through Notifizz and lands on its destination; in an email that is not measured, links point straight at their destination, so a later change of consent can never record a click on it. Following a link is the service the reader asked for; only *recording* the click depends on consent.
* **Unsubscribe is never touched.** The unsubscribe link never goes through the link redirect, and works in every state.
* **Nobody is dropped from a send.** Making delivery depend on accepting measurement would make that consent forced — and your transactional email would stop leaving. The decision applies to the pixel and to the recording, never to eligibility. A refusal passed on for a person changes nothing about what they receive.
* **Everything else is still recorded**: what was sent, to whom, when, why, and how it was delivered. The [delivery history](/docs/operations/delivery-history-and-stats) does not depend on this setting.
## Scope
The setting covers **email**, every category included — transactional too. It applies to emails from your **production** environment; emails sent outside production only ever reach sandbox testers, who [consent for themselves](#sandbox-testers).
It is read **at the moment of the open or the click**, not only when the email left. Moving away from *All my recipients have consented*, or passing on a person's refusal, therefore also stops the counting on emails already in your recipients' inboxes.
**An email whose personal data has been erased is never measured.** At the end of your message retention period, a sent email is [redacted](/docs/concepts/privacy-friendly#redaction): nothing on it says who received it any more, so nothing can check whether that person refused. Its later opens and clicks are not recorded, whatever the state — its links keep working.
Notification Center reads and clicks happen inside your own product, through the widget, and are not governed by this setting.
## The declaration
**Where.** In **Settings → Subscribers & privacy → Opens & clicks**. Until someone answers, nothing is measured, and a notice stays at the top of every dashboard screen — it cannot be dismissed, and it links to that page. The answer can be changed there at any time.
**Who.** Any signed-in member of your organisation. The instruction must come from the controller, so Notifizz staff cannot declare on your behalf, and neither can an AI assistant connected over MCP: the declaration is only made by a person, in the dashboard.
**What each answer certifies.** Both answers are instructions from your organisation as the controller for its recipients, and each one commits it to its own statement.
By choosing **All my recipients have consented**, your organisation certifies that:
* every recipient of its production emails gave **prior, separate consent to the individual measurement of opens and clicks**;
* it **keeps the proof** of that consent;
* it **passes withdrawals on** to Notifizz.
By choosing **Only those who consented**, your organisation certifies that:
* every consent it **passes on** for a person reflects that person's **prior, separate consent** to the individual measurement of opens and clicks;
* it **passes withdrawals on** to Notifizz.
Under the second answer, a person for whom no consent was passed on is not measured. Both statements end the same way: a choice expressed by the recipient always prevails over the declaration.
The full wording is shown on screen before you confirm, in your language, and the version you saw is recorded with your answer. Each answer has one wording for every market, written for the strictest reading: a consent given specifically to measurement, distinct from the consent to receive.
**Withdrawals** are passed on person by person, with the same call as consent: the [refusal](#consent-person-by-person) takes that person out of the measurement under every state, emails already sent included. One recipient withdrawing no longer means changing your organisation's answer.
**Declared *Only those who consented* before that answer had a statement?** It used to certify
nothing, because nobody could be measured under it. Now that it certifies the consents you pass on,
an earlier answer counts as **Not declared** until a member confirms the statement: the notice
comes back, and nobody is measured in the meantime. Confirm it in **Settings → Subscribers &
privacy → Opens & clicks**.
## The journal
Every answer is **appended**, never edited:
| Recorded | Example |
| - | - |
| State before → state after | Not declared → All my recipients have consented |
| Who | The member who confirmed, by their member ID — shown as *you* on your own answers |
| When | Date and time |
| Where | From Settings — or *automatic setup* for the first line Notifizz writes |
| Wording | Version and language of the text shown |
The current state is simply the latest entry, and the journal is shown under the setting. It is what you hand over when a regulator or a customer asks *when did you start measuring, and on whose instruction?* — and it dates any break in your open and click series to the day.
The journal holds your organisation's answers. What your backend passes on for a person is kept with that person — the answer, and the date it last changed — and appears in their [right-of-access export](/docs/concepts/audience#answering-a-right-of-access-request). An answer passed on for an email address Notifizz had not yet linked to the person is kept with that address alone, and appears in their export once you link the address to them with `identify()`.
## Organisations created before this setting
They start as **Not declared**. From that day, their production emails carry no open pixel and record no opens or clicks, until someone declares. The first line of their journal is written by Notifizz and marks that date.
Nothing else stops: sends, links, unsubscribe, delivery history and objectives on your own business events carry on as before. The dashboard shows a notice until a person has declared.
## Sandbox testers
[Sandbox testers](/docs/concepts/campaigns#send-scope) are the verified test inboxes of your organisation — at most five, shared by all your non-production environments. They receive, for real, the emails sent outside production: campaigns in `Review`, rehearsals, and `Live` campaigns fired from a non-production environment.
A tester can be anyone you invite, not only a colleague, so your organisation's declaration does not cover them. **Each tester decides for their own inbox**:
* The page that confirms their address carries a **separate box**, **unticked by default**, to accept measurement. Confirming the address without ticking it is fine: they receive the review emails, unmeasured.
* **Testers verified before this setting existed are not measured** until they accept. From the *Review sandbox recipients* list (**Settings → Email → Sender**), send them a new link: the page they land on asks for that consent.
* Removing a tester from the list ends both: no more review emails, no more measurement.
* What your backend passes on does not reach them: a call made with a non-production key has no effect.
The rule is the same as in production: an unmeasured tester's review email has no open pixel, and their clicks are not recorded. That is expected — it is exactly what the same email will do in production for a recipient who is not measured.
## What changes on your numbers
Two separate facts. Keep them apart: they have different causes, and mixing them makes the second one look like something was hidden.
### 1. Opens are a noisy statistic — everywhere
Apple Mail, with its privacy protection on, loads every image in advance. Corporate security gateways and antivirus software fetch images and follow links before anyone reads the email. An "open" is often a machine. This is true of every email tool, and it has nothing to do with consent.
What is reliable and actionable: **what was sent to whom, when and why** — always recorded — and **clicks** from the recipients who are measured, which are closer to intent than opens.
### 2. Your measured numbers will be lower — for a different reason
When measurement follows consent, recipients who did not consent, or who refused, are **no longer counted**. Open and click rates drop not because people engage less, but because part of your audience is no longer observed. The drop starts on the day the state changes; the [journal](#the-journal) gives you that date, so a before/after comparison is read with it in mind. Under *Only those who consented*, the measured share then grows as your backend passes consents on.
### "Not measured" is not 0 %
Where a figure depends on this measurement and nothing could be measured — *Not declared*, or *Only those who consented* before a first consent is passed on — statistics screens show **Not measured** instead of a number. A 0 % would claim that nobody opened; *Not measured* says that nobody was looked at. Sends, deliveries and bounces are always shown.
### "Partial": some recipients measured, not all
Where only some of your production recipients are measured, or Notifizz can no longer vouch that all of them are, statistics screens show the figure followed by **partial**:
* under *Only those who consented*, from the first consent your backend passes on;
* under *All my recipients have consented*, as soon as your backend passes on an answer for an individual person, or a recipient refuses measurement from an email. A refusal takes someone out of the count. A consent alone takes nobody out, but it shows that your backend answers person by person: the figure is then no longer presented as covering everyone.
A partial figure counts the opens and clicks of measured recipients only, while rates are still computed against every send: they are a floor, not the total.
### Objectives
* **`Click` and `Read`** objectives read the same signals: on email, they only see measured recipients. Unless every production recipient is measured, the campaign editor flags them as **partial**. A recipient who is not measured and clicks is not credited — and if the campaign stops its sequence once the objective is reached, that person keeps receiving the follow-ups.
* **Objectives on your own business events** (`invoice.paid`, `migration.completed`, …) are unaffected: they come from your `track()` calls, not from the email. Prefer them whenever the act you want is something your product can see. See [objectives](/docs/concepts/objectives).
## The recipient's own choice
A measured email lets its recipient refuse measurement from the email itself, on their [preference page](/docs/concepts/notification-preferences#the-recipients-own-choice-on-measurement), and keep receiving. That refusal prevails over your declaration and over anything your backend passed on, emails already sent included — which is why both statements say so. Unticking it only removes their own refusal.
## FAQ
No. Every email still leaves, with working links and a working unsubscribe. Only the open pixel and the link redirect are left out: links point straight at their destination, and opens and clicks are not recorded.
From your backend, with the SDK, once — when the person gives their answer or changes it:
```ts theme={null}
// The person withdrew their consent (preference centre, CRM, support request…)
await client.setMeasurementConsent({
subject: { type: "AppUserSubject", identifier: "u_42" },
consented: false,
});
// …or gave it
await client.setMeasurementConsent({
subject: { type: "EmailSubject", identifier: "alice@example.com" },
consented: true,
});
```
Designate the person by your user id or by their email address. `consented` must be a real boolean: a string such as `"false"` is refused, and nothing is written. The call is idempotent, and the SDK does not repeat it for you: on a network error or a server error, call it again until it succeeds — a withdrawal that never reaches Notifizz is not honoured. Java and PHP carry the same call — see the [Java](/docs/sdks/event-tracking/java#measurement-consent) and [PHP](/docs/sdks/event-tracking/php#measurement-consent) references.
Check, in this order: your organisation has declared *Only those who consented* or *All my recipients have consented* (under *Not declared*, nobody is measured); the call was made with your **production** key (other keys have no effect); no refusal was passed on for another of that person's records — an address not linked to the user id, for instance (a refusal always wins); a consent passed on for an email address counts for a person only if you linked that address to them with `identify()` or if they are the only person among your users who holds it — not for an email sent under a user id that does not hold that address, nor for an address held by several of your users you have not linked together; for an address that belongs to several people you have not linked together, it also changes no existing answer and lifts no refusal, even one passed on for that address (in every case, pass it on under the user id); no `detach()` has cleared the consent since it was passed on (pass it on again); and the email is recent enough to still be tied to its recipient (a [redacted](/docs/concepts/privacy-friendly#redaction) email is never measured).
No. It is a lasting answer, kept with the person until your backend passes on a different one. Call it when the person answers and whenever they change their mind; nothing is needed at send time.
Not today. The setting covers every email category, transactional included.
No. A [custom tracking domain](/docs/operations/tracking-domain) changes which hostname serves the pixel and the links, not what they measure. The pixel is only present for measured recipients, whatever the domain.
Not by design. The delivery provider's own open and click tracking is switched off on every sending server, and Notifizz checks it every hour: if it were ever switched back on, our team is alerted and switches it off. Notifizz's own pixel and link redirects follow this setting.
No. The declaration is your organisation's instruction as controller, so it is made by a signed-in member of your team, in the dashboard. Notifizz staff are refused, and the setting is not exposed over MCP.
The dashboard shows you the new version and asks you to confirm again. An answer is only ever recorded against the exact text that was on screen.
Sandbox testers are outside that declaration: each one accepts measurement for their own inbox, on their verification page. Send them a new link from the *Review sandbox recipients* list (**Settings → Email → Sender**).
No. Recipients who are not measured are no longer counted, so the measured rate falls even if nobody behaves differently. Check the date in the journal: the change in your series starts there.
Counting *unique* opens means knowing which email loaded the pixel — which is precisely measuring an individual. A count that ignores whose email it was can no longer tell one reader opening twice from two readers, and it is inflated by the machines described above.
## See also
What Notifizz stores, what it doesn't, and for how long.
Consent to receive: categories, preference centre, suppression.
The funnel, and what "Not measured" and "partial" mean there.
Why a business event beats a click as an objective.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.