​

Product overview

Notifizz is the event-driven notification platform for your whole team. This page covers the mental model — what Notifizz solves, the four main concepts, where each lives in the dashboard. For the wire-level pipeline, read how Notifizz works.

​

TL;DR

• Emit one event from your backend with client.track(eventName, properties).
• A campaign in the dashboard reacts to that event.
• The orchestrator (campaign code, AI-generated, editable) builds the recipient list — directly from properties or via enrichers.
• Channels deliver the notification (Notification Center widget today, email next).

That’s the full surface. No SDK methods to memorise, no recipient lists at the call site, no client-side workflow targeting.

​

The four primitives

​

1. Events

What your code emits. A name (order.shipped) plus a JSON properties bag. Defined in your code; registered in the dashboard for visibility. See events concept.

​

2. Campaigns

What the dashboard configures. Each campaign listens on one event and decides what notification to send, to whom, through which channel. Statuses (Editing / Dev / Live / Offline / Archived) gate when it runs. See campaigns concept.

​

3. Orchestrator

The code inside a campaign that runs server-side per event. AI generates the boilerplate from the campaign description; you can edit it. It builds the recipient list — directly from event properties, via enrichers (live data fetches), or via dynamic recipient sources. See orchestrator concept.

​

4. Channels

How the notification reaches the user. Today: the Notification Center in-app widget (real-time via real-time stream). Coming next: email. The campaign picks the channel; the channel processor renders + dispatches. See channels concept.

​

Where each piece lives in the dashboard

​

What Notifizz is not

Three things Notifizz deliberately doesn’t try to be:

• Not an analytics tool. Use Segment/Mixpanel/Amplitude for “what did the user do”. Notifizz is “what notification should fire”. The two compose well via the Segment connector.
• Not a marketing automation engine in isolation. The pillar pages (Wave 2.5) make the case directly — Notifizz is event-driven first, marketing-and-product collaborative second. Pure marketing tools like Customer.io / Braze sit on a different point in the design space.
• Not a transactional email service. Email is a channel Notifizz dispatches through; it isn’t a generic SMTP relay. If you only need transactional email and never any in-app notifications, lighter-weight tools fit better.

​

Mental analogies

If you’re coming from a familiar tool, here’s the rough mapping: The Notifizz model is closest to the third row — it expects you to think in events first, then react to them with code. The dashboard layer sits on top to let marketing edit the reactions without redeploying.

​

Why this design

The core invariant is server-side routing. The SDK never picks a campaign, channel, or recipient list. Pushing those decisions to the dashboard means:

• Marketing edits campaigns without a dev deploy.
• The same product event drives multiple campaigns over time (transactional + marketing), no code changes.
• AI authoring works because the orchestrator has full visibility — the call site doesn’t hide intent in code.
• The audit trail is centralised — every campaign change goes through the dashboard’s activity log.

The pillar pages walk through each of these in offensive voice — see “why marketing autonomy”, “why event-driven”, “why enrichers”, “why AI”, “why whole team” (Wave 2.5).

​

Next steps