> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Why Event-Driven Notifications Beat Scheduled Campaigns
> Notifications are reactions to product events. Scheduled segment-based campaigns are a downgrade. Event-driven matches developer intuition and real-time UX needs.
# Why event-driven
Notifications are reactions to things that happened. Scheduled marketing campaigns pretend they're proactive — they reach for users on a calendar, not a moment. The market has settled on the calendar model because that's what came out of CRM-era tools. We think that's a downgrade.
Event-driven isn't a feature. It's the unit of design. Pick the wrong primitive and every other decision compounds the mistake.
## What we believe
The right primitive for a notification platform is the **event**, not the segment. Events are how product engineers already think; events are what real-time UX needs; events compose into segments naturally; segments don't compose back into events. The platform that picks the lower-level primitive can express everything the higher-level one does — the reverse isn't true.
## The status quo
Customer.io, Braze, Iterable. Different brands; same model. The unit of work is a **campaign on a segment**: pick a saved audience, pick a delivery rule (now / on date / on schedule), pick a template. Send.
This made sense in 2010 when the inputs were a CSV and an event hadn't been invented yet outside Mixpanel. The mental model survives because:
* The visual canvas is easy to demo.
* Marketing teams hire from a pool that's been trained on this model.
* The backend is conceptually simple — it's a CRON job over a database.
But the model has three structural problems.
### Segments drift
A segment is a query at the time it ran. By the time the campaign sends, the world has moved. The user who matched "abandoned cart 30 min ago" three minutes before the send may have completed checkout in the interval. The segment isn't wrong — the *abstraction* is, because it asks the platform to make decisions ahead of the moment they're meant for.
### Real-time is bolted on
When the platform finally needs to react to a real event ("user just signed up"), the model doesn't bend gracefully. Customer.io's solution is event-triggered campaigns; Braze's is custom events; Iterable's is webhooks. Each is a feature retrofitted onto a segment-first foundation. The result: real-time campaigns and scheduled campaigns are different surface areas, with different UIs, different debugging stories, different limits.
### Lifecycle and marketing diverge
Transactional notifications ("your invoice is ready", "password reset") are first-class events. Marketing notifications ("we miss you") are scheduled segments. They live on different platforms, with different teams, different data, different tooling. The user receives them through the same email inbox but the company treats them as separate domains.
That divergence is artificial. Both are notifications; both react to product state; both should share infrastructure.
## The Notifizz alternative
One primitive: the event. `client.track(eventName, properties)` from your code; campaigns react server-side. The same primitive powers transactional ("order shipped") and lifecycle ("we miss you") notifications.
Lifecycle marketing on event primitives looks like:
```javascript theme={null}
// Triggered by a server-side timer when the user hasn't logged in for 30 days
await client.track("user.dormant_30d", { userId, lastLogin });
```
Same shape as `order.shipped`. Same campaign machinery. Same delivery pipeline. The "scheduled segment" disappears as a category — what looked like a saved query becomes an emit on a timer.
The benefits compound:
| Benefit | Why event-driven enables it |
| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Real-time UX** | Campaigns react to events as they happen. No polling, no scheduled sweep. |
| **No segment drift** | The event captures the moment exactly. The campaign decides at *that* moment, not later. |
| **Lifecycle + marketing convergence** | Same primitive for both. One activity log, one delivery history, one set of analytics. |
| **Debuggability** | One event → one notification → one trace. The full path is queryable end-to-end ([observability](/docs/operations/observability)). |
| **Developer intuition** | Events are how product engineers think about state changes. The model fits the team. |
Cited concretely in [events](/docs/concepts/events) (the grammar) and [Event Tracking](/docs/sdks/event-tracking/overview) (the wire format). The grammar RFC is 2026-04-19-event-name-grammar-and-slug.
## The unit of work matters
The pattern is a small instance of a general one in software design: **the lowest useful primitive wins**. SQL beat hierarchical databases not because it was easier but because relational expressed everything the hierarchical model did, plus more. Events beat scheduled segments by the same logic.
A segment is a query over events; you can always reconstruct it. An event is a fact; you can't reconstruct it from a segment that ran an hour later. The asymmetry is permanent.
## But what about…
Yes — and the wiring is explicit. There's no native "scheduled campaigns" surface in Notifizz. The pattern: your backend runs a cron that emits the event at the desired moment (`marketing.campaign.black_friday_open` at 9am EST). The campaign listening on it dispatches. The scheduling logic stays in your domain, which is where time-sensitive business rules typically belong — and it composes cleanly with everything else (idempotency, retries, observability).
Different layers. Segment is for **analysis** — billions of events per month, bulk-loaded into your warehouse. Notifizz is for **reaction** — selected events that should drive a notification, low-cardinality, sub-second latency. Pair them: instrument every analytic event in Segment, send the few "I want to react to this" events to Notifizz. The [Segment connector](/docs/sdks/how-to/connector-webhooks) makes the bridge cheap.
Only if every event drives a notification. The campaign decides — most events fire silently because no campaign listens; only the events with attached campaigns produce notifications. Volume control is a campaign decision (frequency caps, quiet hours, suppression lists), not an event decision. Engineering doesn't need to think about volume when emitting; Marketing controls the throttle.
They look complementary. They're not — they're substitutable, with one being strictly more expressive. A segment is a saved query over events; the platform can build segments by reading the event stream, not by maintaining a parallel data model. We pick the lower primitive on principle: it's everything the higher one is, plus the cases the higher one can't reach.
Then your campaigns won't notice. Notifizz event-driven campaigns can also fire on a daily roll-up — emit `daily.summary.ready` from a cron, react with a campaign. The point isn't that everything has to be sub-second; the point is that the *option* is there when you need it, without a separate platform.
Engineers already emit events for analytics — that work transfers. The Notifizz instrumentation overlap is selective: only the events you want to drive notifications need to go to Notifizz. For most teams, that's 5-20 named events covering the high-leverage moments (signup, payment, churn risk, key milestone). The rest stays in your analytics tool.
## Where to go next
The hero pillar that ties the four ingredients together.
Live data at notification time — no warehouse sync.
The grammar, properties, and idempotency.
The HTTP wire format every SDK shares.