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.
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:
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). |
| Developer intuition | Events are how product engineers think about state changes. The model fits the team. |
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…
Marketing is date-driven (Black Friday). Does event-driven fit?
Marketing is date-driven (Black Friday). Does event-driven fit?
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).We track events with Segment. What does Notifizz add?
We track events with Segment. What does Notifizz add?
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 makes the bridge cheap.
Won't event-driven flood my users?
Won't event-driven flood my users?
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.
Aren't event-driven and segment-based complementary?
Aren't event-driven and segment-based complementary?
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.
Real-time isn't worth the complexity for our use case.
Real-time isn't worth the complexity for our use case.
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.Won't event-driven require my engineers to instrument more?
Won't event-driven require my engineers to instrument more?
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
Marketing autonomy
The hero pillar that ties the four ingredients together.
Why enrichers
Live data at notification time — no warehouse sync.
Events
The grammar, properties, and idempotency.
Event Tracking
The HTTP wire format every SDK shares.