From Data to Decisions: Analytics Infrastructure

Three months into my role as a PM at the data team, I asked a simple question about one the KPIs we were supposed to track. Four different people gave me four different answers. None of them matched the description on the platform. That’s when I realised we had a data problem masquerading as a communication problem.

Analytics infrastructure isn’t sexy. It doesn’t make for compelling product demos or impressive launch announcements. But it’s the foundation upon which every data-driven decision rests. Get it wrong, and you’re building on quicksand. Get it right, and you unlock a level of clarity and speed that transforms how your team operates.

The challenge isn’t collecting data — that’s the easy part (well, in most cases). The challenge is building infrastructure that makes data accessible, trustworthy, and actionable. Here’s what I’ve learned from building analytics systems, and the mistakes I wish I’d avoided.

Core Process: Building Your Foundation

Start With the Questions, Not the Tools

I used to think analytics infrastructure was primarily a technical problem. Pick the right tools, set up the pipelines, and you’re sorted. Oh boy was I wrong.

The best analytics infrastructure I’ve seen starts with clarity about what questions the business needs to answer. Not “what data can we collect?” but “what decisions do we need to make?”

Here’s the framework that worked for me:

List your key strategic decisions
Identify what information would inform each decision
Work backwards to determine what data you need to collect
Design your schema around those data points
Build in flexibility for questions you haven’t thought of yet

That last point is crucial. You can’t predict every question you’ll need to answer. But you can structure your data in ways that make new questions answerable without rebuilding everything.

The Three-Tier Architecture That Actually Works

Every analytics infrastructure tutorial will tell you about data lakes and warehouses. What they often skip is the practical architecture that makes data useful for different audiences.

Here’s what I’ve found works:

Tier 1: Operational Data - Real-time metrics for daily operations. These live close to your production systems. Customer support needs to see user activity instantly. Engineering needs to monitor system health. This data prioritises speed over comprehensiveness.

Tier 2: Analytical Data - Your data warehouse. This is where the bulk of your analytical work happens. Data is structured, cleaned, and optimised for querying. Most teams should spend 80% of their analytics effort here.

Tier 3: Aggregated Metrics - Pre-calculated KPIs and dashboards. These trade flexibility for speed. Your exec dashboard doesn’t query raw data—it pulls from pre-aggregated tables that update hourly or daily.

The mistake I see most often is trying to serve all needs from a single tier. Executives end up waiting 30 seconds for a dashboard to load because it’s querying raw data. Or analysts can’t answer ad-hoc questions because everything’s pre-aggregated.

Segment them. Let each tier serve its purpose.

Advanced Techniques: Making It Scale

The Metadata Layer Nobody Builds

Here’s something I learned from Airbnb’s data team: the biggest challenge as you scale isn’t volume—it’s understanding what data means.

You’ll have hundreds of tables, thousands of columns. Different teams will name things differently. Business logic will be scattered across SQL queries in a dozen repositories. New team members will spend weeks just figuring out what data exists and what it means.

The solution is a metadata layer — essentially a living dictionary of your data landscape. We built ours with dbt. But the tool matters less than the discipline.

Every data transformation needs to answer:

What business concept does this represent?
How is it calculated?
What are its limitations?
Who owns it?
When was it last updated?

The investment pays dividends. When someone asks “what’s our churn rate?” you want to point them to a single, well-documented metric, not start a Slack thread about which of the three churn calculations they should use.

Data Quality as a First-Class Concern

I once launched a feature to improve onboarding completion. Three weeks in, the data showed a significant drop in conversion. We panicked, started planning rollbacks, questioned everything.

Turned out the tracking was broken. A code change had accidentally disabled the completion event. The feature was fine. Our data wasn’t.

Since then, I’ve treated data quality with the same rigour as code quality. That means:

Validation at ingestion - Check data types, required fields, value ranges. If something looks wrong, flag it immediately. Don’t let bad data into your warehouse in the first place.

Automated testing - Write tests for your critical metrics. If daily active users drops 50% overnight, you want an alert. If the sum of regional revenue doesn’t match total revenue, you want to know.

Lineage tracking - When a number looks off, you need to trace it back to its source. Which raw events fed into this metric? What transformations were applied? Clear lineage makes debugging possible.

Segment does this brilliantly. Their data quality tools catch issues before they propagate downstream. A malformed event gets flagged in real-time, not three days later when someone notices a weird spike in a dashboard.

Maintenance and Iteration: Keeping It Healthy

The Quarterly Data Audit

Every quarter, schedule a data audit. It’s tedious but necessary.

Pull up your most used dashboards and metrics. For each one, ask:

Is this still relevant to current business goals?
Is the calculation still correct?
Are people interpreting it the way we intended?
What questions does this answer? What questions does it miss?

Last quarter, we discovered that three of our top 10 dashboards weren’t being used anymore. The questions they answered weren’t relevant to our current strategy. We archived them. This freed up maintenance time and reduced cognitive overhead for new team members.

We also found a metric that everyone used but interpreted differently.

Measuring Your Analytics Infrastructure

How do you know if your analytics infrastructure is working? Here are the metrics I track:

Time to insight - How long does it take from “we need to understand X” to “here’s what the data shows”? In early days, this was days or weeks. Now it’s usually hours.

Query reliability - What percentage of queries complete successfully on the first try? If analysts are constantly debugging broken queries, something’s wrong with your data quality.

Data freshness - How old is your data? Real-time isn’t always necessary, but you should know and control the lag. If people are making decisions on yesterday’s data thinking it’s today’s, that’s a problem.

Self-service adoption - What percentage of data questions get answered without involving the data team? High numbers mean your infrastructure empowers people. Low numbers mean it’s too complicated or untrustworthy.

Key Takeaways

Building analytics infrastructure that truly serves your business requires:

Start with decisions, not data - Map the questions you need to answer, then work backwards to the data you need. Don’t collect everything just because you can.
Layer your architecture - Operational, analytical, and aggregated tiers serve different needs. Don’t try to serve everyone from a single system.
Invest in metadata and documentation - As you scale, understanding what data means becomes harder than collecting it. Build the metadata layer early.
Treat data quality as seriously as code quality - Automated testing, validation, and monitoring aren’t optional. Bad data is worse than no data.
Audit and iterate regularly - Your business changes. Your analytics infrastructure needs to change with it. Quarterly reviews keep it aligned with current needs.

Closing Thoughts

The analytics infrastructure at that fintech startup never became our competitive advantage. But it enabled dozens of decisions that collectively shaped our success: which features to prioritise, which customer segments to focus on, how to allocate our limited engineering resources.

Good analytics infrastructure is invisible. When it works, people just make better decisions. They don’t think about the pipes and plumbing underneath. That’s exactly how it should be.

Your first version doesn’t need to be perfect. Start simple, focus on answering your most important questions reliably, and evolve from there. The companies with the best analytics infrastructure didn’t build it all at once—they built it iteratively, learning from what worked and what didn’t.

What’s one question your team needs to answer that you currently can’t? Start there.

Have questions or thoughts? Get in touch - I’d love to hear from you!