Skip to main content

​
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 the email provider’s callback (email); each is a distinct funnel step.

​
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_42 receive 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

Delivery records are retained per the org’s plan (typically 90 days for the standard plan, with longer retention available). 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:
Each step is a count, with a percentage of the previous step. The funnel applies per channel (NC, email) and per time window (24h, 7d, 30d, all-time).

​
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.

​
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

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.
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.
Per-message detail: 90 days on the standard plan. Aggregate counters in stats: indefinite (the count of messages sent in 2024 doesn’t expire just because the messages themselves do). Adjust per-org via your plan settings.
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.
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.
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.