The Push Analytics Manifesto: why dashboards are losing the next decade of work
Dashboards are a pull model in a world that has moved to push. The case for replacing the dashboard ritual with scheduled, AI-narrated deliveries into the tools people already use.
TL;DR
Push analytics is the practice of delivering specific business metrics to specific recipients on a schedule, in the tools they already use, so insights arrive without anyone opening a dashboard. It is the model that wins when work has already moved into Slack, when AI can write the narrative, and when integration coverage makes synthesis cheap. Dashboards remain useful for exploration. Routine reporting is now a push problem.
I have spent the last decade watching teams build dashboards no one opens. Sometimes the dashboard is gorgeous; sometimes it's a hack. Doesn't matter. The pattern repeats: someone builds the thing, someone shares the URL, and within four weeks the link gets stale because everyone forgot to check it.
This is not a tooling failure. It's a model failure. A dashboard is a pull model — it assumes the person who needs information will take an action to get it. In a world where attention is the scarce resource, that assumption is dead.
The model that wins is push: the right metric, sent to the right person, on the right cadence, in the place they already work. This post is the case for it.
The three things that changed
Push analytics is not a new idea. People have been emailing weekly KPI summaries since email existed. But for most of the last decade, doing it well required a full-time analyst per pulse — someone to pull the numbers, write the paragraph, click "send" on Monday morning. The cost was prohibitive and the result was inconsistent.
Three things changed.
Work moved into Slack and Teams. Around 2020, "open a new tab to check a dashboard" stopped being something working professionals did. The center of attention is now a chat client. If a metric isn't there, it isn't in the field of view.
AI made narrative cheap. The most expensive part of a useful report was always the sentence: "MRR up 3.1% week-over-week, driven by 4 new enterprise plans." That sentence took an analyst 20 minutes to write — pull the data, eyeball it, decide what to say. Generative AI does it in milliseconds. The economics of routine reporting collapsed.
Integration coverage expanded. A push that says "MRR up, driven by 4 new enterprise plans" requires joining billing data with CRM data with maybe support data. Five years ago that was a warehouse project. Today it's a configuration. Cross-tool synthesis is no longer the bottleneck.
The combined effect: the cycle of pulling numbers, pasting into Notion, summarizing in Slack — the most expensive ritual in most companies — can be automated end-to-end. The product surface for that is push analytics.
Push vs. pull, concretely
| Dimension | Pull (dashboard) | Push (this argument) |
|---|---|---|
| Who initiates | Recipient | System |
| Default behavior | No view | Delivered view |
| Editing burden | Show everything | Show one thing |
| Failure mode | Ignored | Spammy / muted |
| Good for | Exploration, deep dives | Routine reporting, alerts |
| Time-to-insight | Minutes (open tab → scan) | Zero (it arrived) |
Both have a role. The mistake is asking pull tools to do push work.
The objections, and what's wrong with them
The pushback on push analytics is consistent. Let me address the three most common.
"But people need to look at the full context, not just one number"
Sometimes. Most of the time, no. The Monday revenue update doesn't need the full dashboard — it needs the number, the delta, and the why. If the recipient wants to explore, the link is one click away. Push doesn't replace exploration; it replaces the ritual of pretending to explore.
"Push will become spam"
It will, if you do it badly. The whole discipline of push analytics is editorial: choosing what not to send. A team sending 12 daily pulses to a 200-person channel is doing dashboard culture in a new skin. The skill is sending one pulse to five people. See the anti-patterns section of /push-analytics for the failure modes.
"Real-time is better"
Almost never. Most metrics don't need to be real-time. Real-time is the cadence of choice for people who haven't decided what the actual signal is, so they send everything and let the recipient triage. That's pull behaviour in push clothing. The right answer is the slowest cadence that still lets the recipient act in time. For most business metrics, that's daily. Often weekly.
The hybrid model
I'm not arguing for the end of dashboards. I'm arguing for honest job assignment.
A working analytics stack has three layers:
- Push layer: the routine reports, the threshold alerts, the daily/weekly cadences. Goes to Slack/email. Most numbers most people see should come from here.
- Pull layer: the dashboards. Used when someone has a specific question that the push didn't anticipate, or when an investigation is underway.
- Query layer: the warehouse / SQL / notebook. Used by analysts and data engineers for ad-hoc work, hypothesis testing, and feeding the push layer.
The mistake of the dashboard era was conflating layers 1 and 2. The fix is to put push back in front of pull. Most teams have layer 2 wildly over-built and layer 1 nonexistent.
We had eight Looker dashboards no one opened. We replaced six of them with a daily Slack pulse and an email digest. Two months later, finance discussion in the company is louder, not quieter. The dashboards weren't generating the conversation. The push is.
How to start
Don't try to migrate everything. Pick one ritual you already do every week — the metric you manually paste into Slack every Monday, the email someone sends to investors, the spreadsheet the agency manager pastes into a client channel — and replace the manual half of it with a scheduled pulse.
Then add the next one.
The temptation to wire up the full analytics stack at once is the most common reason teams give up. Push analytics rewards focus.
For Chartcastr specifically, create a new pulse, pick a source (Google Sheets, HubSpot, Shopify, BigQuery, whichever you have), pick the metric, pick the recipients, pick the cadence. The first one takes ten minutes. The second one takes two.
Predictions
Three things I expect to be true within the next 24 months:
- "Dashboard-only" BI tools will lose share to push-first products. Looker, Tableau, Metabase will all add push features. The companies that started with push as the primitive will iterate faster.
- AI Mode in chat tools will become the dominant exploration surface. Pull, when it does happen, will increasingly happen through "ask the bot" rather than "open the dashboard". This is push's exploration cousin, not its enemy.
- The job title "BI engineer" will narrow. Less time on dashboard design, more time on semantic layer + pulse design. The work shifts from rendering to routing.
What this isn't
Push analytics is not a renaming of "alerts" or "dashboards-in-Slack" or "scheduled exports". It's not a feature. It's the model that becomes obvious once you stop assuming the recipient will come to you.
If you want the longer technical definition, the /push-analytics pillar page has the principles, the anti-patterns, and the comparison table. If you want the data backing the timing claims, the Slack chart delivery engagement benchmark has it. And if you want to see what the pattern looks like for your team, you can start with one pulse and add from there.
The dashboard era was a long detour. We're walking back to the obvious answer.
