Say you want to know how many people signed up this week, and where they came from. Simple question. But to answer it you probably end up exporting your events to a warehouse, modeling them, pointing a BI tool at the result, and writing some SQL. All to chart something you were already collecting.
You're already sending these events somewhere. They're structured, they're typed, and they pass through one place on the way out. The data is right there. Getting a chart out of it shouldn't mean standing up a second stack.
the data was already here
Here's a pipeline you might already run. Every signup comes in, gets enriched, and fans out — the high-value ones ping Slack, all of them land in Postgres for keeping. Flip between the diagram and the file.
representation
01source
02pipeline · 1 steps
- 01ENRenrich.person$event.payload.email → name + company
03destinations · 2
- toslackSlackchannel#growthwhen$person.plan == "growth"
- towarehouse.pgPostgrestableevents.signups
Nothing exotic. But look at what's true by the time that event reaches its destinations: it has a type, a timestamp, and a structured payload — plan, source, country — and it's been captured. Everything you'd need to chart it already exists, because you're already sending it. (Routing one event to several places is its own small craft — more on fan-out here.)
chart your events in place
So we closed the loop. Charts read the same event stream the pipeline already feeds — pick an event type, count it over the last 7, 30, or 90 days, and optionally break it down by any attribute on the payload. No export, no second warehouse, no new tracking code, because the events are already here.
- landing-page84%
- signup-demo14%
- (none)2%
That's two questions answered on one board: signups over the last month, split by $event.payload.source so you can see landing-page versus demo at a glance; and checkouts over the same window with the trend against the month before. Both drawn from events you were already sending — the chart is just a lens on them.
group them into dashboards
Charts live on dashboards, and you can keep as many as you have things to watch — onboarding on one, revenue on another, a launch on a third. Each board remembers its own time window and opens to whoever needs it. Break any count down by a payload attribute and the single number splits into a colour-keyed view with each value's share; the top values stay, the long tail folds into (other) so it stays readable. The docs cover the model.
what it doesn't do yet
I'll be straight about the edge: this is counts and breakdowns, not funnels. If you need cross-step conversion — signed up, then activated, then paid, correlated per person — that's still a join the warehouse export is better at, and we keep that path open. Charts answer the “how many, trending which way, broken down by what” questions, which turn out to be most of the questions you ask in a day.
The thing I keep coming back to: every event you send is already structured, already typed, and already sitting in one place because you sent it through a pipe to get there. Making you leave to look at it was the artificial step. We ingest it, we transform it, we route it — all in one pass — so seeing it should be the same surface, not a second stack you maintain.
Send an event and chart it — the dashboard reads what you're already piping, with no warehouse in the middle.