Real-time analytics are overrated (for most companies)

I once spent six weeks building a real-time analytics pipeline for a B2B SaaS company. Custom Kafka setup, streaming into a data warehouse, live dashboards updating every 30 seconds. The whole thing cost about €40K in implementation and ran about €2K/month in infrastructure.

Three months after launch, I checked the dashboard usage logs. Two people had looked at the real-time view. Twice. Both times were during the first week, when everyone was excited about the new shiny thing.

Every actual business decision at that company happened in Monday morning meetings based on weekly reports.

I’m not proud of this project. But it taught me something I now tell every client: unless you can name the specific decision you’ll make differently because data arrived in 30 seconds instead of 30 minutes, you don’t need real-time analytics.

The seduction of live dashboards

I get it. Real-time dashboards look incredible in presentations. Numbers ticking up. Lines moving across charts. A little animation every time someone converts. It feels like you have your finger on the pulse of the business.

There’s a reason every analytics vendor demos real-time features prominently. It sells well. Nobody gets excited watching a batch job run at 3 AM.

But looking impressive and being useful are different things. And in my experience, about 80-85% of companies that ask for real-time analytics would be perfectly served by data that refreshes every hour, or even every day.

The question isn’t whether real-time data is nice to have. Of course it is. The question is whether it’s worth the cost. And that cost is almost always higher than people expect.

What real-time actually costs

Let’s get specific. I’m going to compare three tiers of data freshness and what each typically runs for a mid-size company processing 50-100 million events per month.

Daily batch (overnight processing):

• BigQuery with scheduled queries: $50-200/month
• dbt Cloud on a schedule: $100/month (Team plan)
• Looker Studio dashboards: free
• Total: $150-300/month
• Engineering time: a few hours per month for maintenance

Near-real-time (15-60 minute refresh):

• BigQuery with streaming inserts: $300-800/month
• More complex dbt models with incremental builds: $100/month
• Dashboard tool with auto-refresh: $0-500/month depending on tool
• Total: $400-1,300/month
• Engineering time: 1-2 days per month

True real-time (sub-minute):

• Streaming infrastructure (Kafka/Pub-Sub/Kinesis): $500-2,000/month
• Stream processing (Flink, Dataflow): $800-3,000/month
• Real-time database (Redis, ClickHouse): $200-1,500/month
• Real-time dashboarding tool: $500-2,000/month
• Total: $2,000-8,500/month
• Engineering time: 2-4 days per month, plus on-call

That’s a 10-30x cost difference between daily batch and true real-time. For the same data. The same eventual answers. Just faster.

And I’m not counting the initial build. Getting a reliable real-time pipeline from scratch typically takes 4-8 weeks of senior engineering time. At €800-1,200/day for a contractor, that’s another €16K-48K upfront.

When real-time actually matters

I want to be fair. Real-time analytics isn’t always overkill. There are situations where it genuinely changes outcomes. Here are the ones I’ve seen in practice.

Flash sales and limited-inventory events. A fashion retailer I work with runs 24-hour flash sales twice a month. During those sales, they need to see conversion rates, stock levels, and revenue by hour. If a product page has a broken “add to cart” button, they lose €5K-10K per hour. Finding that in tomorrow’s daily report isn’t useful. Finding it in 3 minutes is.

Live advertising campaigns with large budgets. If you’re spending €50K+ on a single-day campaign (product launch, event promotion, Super Bowl ad), knowing within minutes whether traffic is converting or bouncing lets you shift budget in real time. One client caught a broken landing page UTM parameter 8 minutes into a €30K campaign day. Without real-time monitoring, they would have wasted the entire day’s budget on untracked traffic.

Site reliability and error detection. This is probably the strongest case. If your checkout suddenly starts throwing 500 errors, a real-time alert saves real money. But this is more DevOps monitoring than analytics. Tools like Datadog, Sentry, or even basic uptime monitors handle this without building a full real-time analytics pipeline.

Media and publishing. Newsrooms that optimize headlines in the first 30 minutes after publication based on click-through rates have a legitimate need for near-real-time. Same for live streaming events where you’re adjusting content based on audience response.

When it doesn’t matter (which is most of the time)

B2B with sales cycles over 30 days. Your deals take 3 months to close. Knowing that a prospect visited your pricing page 45 seconds ago versus learning it tomorrow morning changes absolutely nothing about how your sales team operates. I worked with a B2B software company that had real-time lead scoring. Their average response time to a new lead was still 4 hours because the sales team checked their CRM at set intervals regardless.

Brand marketing and awareness campaigns. You’re measuring sentiment, reach, recall. These metrics don’t change minute to minute. They barely change week to week. Real-time data on a brand campaign is noise shaped like a signal.

Content marketing. Blog posts don’t go viral in the first 30 seconds (and if they do, you probably don’t need to do anything about it). Content performance is measured over weeks and months. A daily report is more than sufficient.

Most e-commerce outside peak events. Your standard Tuesday? Daily batch is fine. You’ll make the same decisions about product placement, pricing, and email campaigns whether you look at yesterday’s data or this-second’s data. Save the real-time infrastructure for Black Friday and known sale events.

Any company under €5M annual revenue. At this scale, the cost of real-time infrastructure is disproportionate to the decisions it enables. You have bigger problems to solve and better places to invest that money. A solid analytics setup for SaaS will serve you far better.

The hidden cost nobody mentions: alert fatigue

Real-time data naturally leads to real-time alerts. And real-time alerts lead to alert fatigue faster than you’d think.

I’ve seen this pattern at four or five companies now. Week one: everyone’s excited, responding to every alert. Week three: people start muting notifications. Month two: alerts go to a Slack channel nobody reads. Month four: someone asks “do we still pay for this?”

The problem is that real-time data is noisy. Conversion rates fluctuate wildly at small time scales. Your conversion rate at 3 AM on a Tuesday is not meaningful. Getting an alert that it dropped 40% compared to the same hour last week is not actionable. It’s just a small sample size doing what small sample sizes do.

Useful alerting requires careful threshold tuning, proper statistical baselines, and someone who understands when a fluctuation is signal versus noise. That’s a data engineering role, not a marketing role. And it’s ongoing work.

Compare this to a simple approach: a daily email with yesterday’s key metrics and a flag if anything deviates more than 2 standard deviations from the 30-day average. Takes an hour to set up in any BI tool. Catches genuine anomalies. Doesn’t wake anyone up at 3 AM because 7 people visited the site in the last hour instead of the usual 12.

What I actually recommend

For 90% of my clients, here’s the setup that works:

Daily batch processing for analytics. GA4 BigQuery export on daily schedule. dbt models that run overnight. Dashboards that update by 7 AM. This covers all strategic and tactical decisions. If you’re not sure where to start with this, my guide on building a marketing data warehouse walks through the full stack.

Near-real-time for operations. Set up streaming to BigQuery (it’s cheap) and create a single operational dashboard that shows the last 2-4 hours. Use this for monitoring during campaigns, sales, or product launches. Don’t look at it on normal days.

Specific real-time alerts for emergencies. Three to five alerts, maximum. Checkout error rate above 5%. Payment success rate drops below 90%. Homepage response time exceeds 3 seconds. Site goes down. These should go to the engineering team, not marketing.

That’s it. This setup costs $300-600/month. It covers every decision cycle I’ve seen at companies under €50M in revenue. And nobody gets an alert because the homepage had 3 fewer visitors between 2:14 and 2:15 AM.

The meta-lesson

The desire for real-time analytics is usually a symptom of something else. Sometimes it’s a lack of trust in the data (“if I can see it live, I’ll believe it”). Sometimes it’s anxiety about missing something (“what if something breaks and we don’t know for hours?”). Sometimes it’s just the appeal of a cool demo.

None of these are bad instincts. But real-time infrastructure is an expensive solution to each of them.

If you don’t trust your data, fixing data quality is cheaper and more effective than making it arrive faster. Bad data in real-time is still bad data.

If you’re worried about outages, invest in proper monitoring (Datadog, Pingdom, your hosting provider’s built-in tools). These are purpose-built for the job and cost a fraction of a custom real-time analytics pipeline.

If you want a cool demo, build one dashboard with a real-time view. Use GA4’s built-in real-time report. Don’t architect your entire data stack around it.

I’ve built real-time systems that saved companies real money. I’ve also built real-time systems that ran for a year without informing a single decision. The difference was always the same: whether someone could tell me, before we started building, exactly what they’d do differently with faster data.

If you can answer that question with something specific, build it. If the answer is “well, we’d just… know things faster,” save your money. You’ll know things fast enough with a daily batch job and three well-configured alerts.