Delivery history and stats
Notifizz exposes two distinct surfaces for “what happened”: Delivery History (what got sent) and Statistics (aggregated funnel per campaign). They share data sources but answer different questions.TL;DR
- Delivery History is a top-level page (
/org/:org/app/inbox) — the timeline of every notification sent across all campaigns. - Stats are funnel charts embedded in each campaign detail view — not a standalone page.
- Stats use a cache layer for fast aggregation; the durable source of truth is per-message delivery writes.
- Read / opened / clicked are recorded by the widget (NC) or by Notifizz’s own open pixel and link redirect (email); each is a distinct funnel step.
- On email, opens and clicks are recorded only for recipients covered by open and click measurement. Where nothing was measured, stats say Not measured, not 0 %; where only some recipients were, the figure is marked partial.
Delivery History
The top-level view answers “what was sent in the last hour / day / week?”. It lists every workflow instance and every per-recipient delivery, with filters for campaign, recipient, channel, status, and time range.What you can do here
- Trace a specific delivery by message id or correlation id.
- Filter by user to see “did
u_42receive the welcome notification?”. - See the raw event payload that triggered each delivery — useful for “did the orchestrator see what I expected?”.
- Inspect the rendered template — the snapshot stored at message creation time, with variables resolved.
Retention
A sent message keeps its recipient and rendered content for your organisation’smessageRetentionDays (default 7 days), then is redacted: the delivery record stays, naming no one, until it is deleted 180 days after sending. In-app inbox messages are the exception — kept with their content for notificationCenterRetentionYears (default 5), then deleted; they name their recipient by user id only (see redaction). Aged-out records still keep their aggregate counters in stats — you lose the per-message detail but the campaign-level funnel survives.
Statistics (per campaign)
The campaign detail page shows a funnel:What each step means
Read vs Opened is the distinction most users miss — Read means the message was rendered in the list (passive), Opened means the user actively engaged with that specific message.
Not measured
Email opens and clicks exist only for measured recipients: who is measured follows your organisation’s open and click measurement declaration and the consent or refusal your backend passes on for each person. Until your organisation declares, production emails carry no open pixel and record no clicks. Where a step depends on that measurement and nothing was measured, the stats show Not measured instead of a percentage. A 0 % would claim that nobody opened; Not measured says that nobody was looked at.Partial
Where only some of your production recipients are measured, or Notifizz can no longer vouch that all of them are — under All my recipients have consented, any answer passed on for an individual person or a refusal a recipient expressed from an email; under Only those who consented, consents passed on — the open and click figures are shown followed by partial. They count measured recipients only, while rates are computed against every send: read them as a floor, not the total. Delivery, bounces and the Notification Center funnel do not depend on this setting.Cache and durability
Funnel counts are computed from per-message events. To keep the dashboard responsive at scale, Notifizz caches the aggregations.
The cache is invalidated on every write; you’ll see new data within seconds of a delivery.
How events are recorded
Each event is keyed by
(messageId, eventType) — duplicates are deduped (a user clicking twice doesn’t double-count).
Performance notes
- Aggregation queries hit the cache first. A cold cache for an unusual time window pays a backend round-trip; subsequent loads are fast.
- Per-message events are written directly to the inbox store — no in-memory queue. Each event is recorded on its own, so reads scale with the time window rather than the lifetime of the campaign.
- Real-time updates on the widget side use a real-time stream. Stats updates on the dashboard side use polling — refresh the page to recompute.
FAQ
Open rate is below delivery rate — is that wrong?
Open rate is below delivery rate — is that wrong?
No — it’s the design. Delivery means the message landed in the user’s inbox. Read means they saw it in the list (passive). Opened means they actively clicked into it. Each step strictly subset-reduces the previous, so percentages decrease down the funnel. A 100% open rate would be suspicious.
Our email open rate dropped — did engagement fall?
Our email open rate dropped — did engagement fall?
Probably not. Two separate things are at play. Opens are a noisy statistic with every email tool: mail clients load images in advance and security scanners fetch them before anyone reads. And on Notifizz, recipients who are not covered by open and click measurement are not counted at all — so the measured rate falls on the day that coverage changes, even if nobody behaves differently. The setting’s journal gives you that date.
An email step says Not measured — is something broken?
An email step says Not measured — is something broken?
No. None of the step’s recipients was measured — your organisation has not declared yet, or it declared Only those who consented and your backend has not passed on any consent — so the email carried no open pixel and clicks were not recorded. Sends, deliveries and bounces are still counted, and every link still worked. See open and click measurement.
Export delivery history?
Export delivery history?
Yes — the Delivery History view has an export button (CSV). For programmatic access, the public read API exposes deliveries by campaign / time window. Both honor the same per-org retention.
Data retention — what's the default?
Data retention — what's the default?
Per-message detail (recipient, rendered content): 7 days, then redacted; the emptied delivery record stays until 180 days after sending. In-app inbox messages: 5 years, kept with their content. Aggregate counters in stats: indefinite (the count of messages sent in 2024 doesn’t expire just because the messages themselves do). The 7 days and the 5 years are per-organisation dials — see retention configuration; the 180 days are fixed.
Stats are stale — when does the cache refresh?
Stats are stale — when does the cache refresh?
On every write that affects the aggregation. If you see stale numbers, the cause is usually time zone — check the time window selector in the funnel. The “all-time” window is always live.
Find one specific delivery for a user?
Find one specific delivery for a user?
Two paths: (1) Delivery History → filter by
userId; (2) the per-user inbox via the dashboard’s user search. Both surface the same data; the user-search path is faster when you know the user.What about A/B test branches in the funnel?
What about A/B test branches in the funnel?
Branches in the orchestrator translate to separate workflow instances per campaign-version pair. The funnel slices by branch when the campaign declares branches explicitly; otherwise the aggregate sums them.
See also
Campaigns
Statuses, lifecycle, versioning.
Observability
Correlation IDs, tracing one delivery end-to-end.
Activity log
Audit trail of campaign edits.
Troubleshooting
“My notification didn’t arrive” — checklist.