Metrics, Apps, & Sigma's Big Bet

Welcome to this edition. I’ll be working to make this more of a newsletter in the coming weeks adding new sections. This will be exclusive to the email version.

A quick note: I'm now part of Sigma's influencer programme and will be creating sponsored content (my first ever ‘sponsor’ 🤩) with them in the near future. They haven't had prior sight of this newsletter, and won't have prior sight of any sponsored content. The views here (and in the future) are entirely my own. If you've followed my Tableau content over the years, you'll know I've always retained my independence of thought, even as part of their community programme. Integrity isn't claimed, it's demonstrated, and I'd rather you judge that for yourself hence this note. Right back to it!

I think a huge amount of the work and rework in analytics teams comes down to one thing: the lack of clarity around three concepts that most people in the industry use interchangeably. Metrics, reports, dashboards, and I’ll add a fourth, apps. These words get thrown around constantly, and almost always without a shared understanding of what each one actually means.

I think that confusion is a big part of why so much of what gets built in analytics rarely gets used. We over-complicate things by building the wrong product. Someone asks for a number, and we give them a dashboard. Someone needs a workflow, and we give them a report, leaving them to solve the last mile themselves. The output doesn't match the need, so it gets ignored, or people rebuild their own workflow around what we give them, and then we wonder why adoption is low.

So let me define these four things the way I evolved to think about them.

A metric is a quantified measure of something that matters to the business. Revenue. Churn rate. Average order value. Net promoter score. A metric has a name and a definition. That definition contains a calculation and a specified grain, telling you what you're measuring and at what level of detail. You might also add constraints to your metric. A constraint tells you what you can and can't do with it. Can it be aggregated? Can it be divided or multiplied, and if so, with which other metrics? For example, you can sum revenue across regions, but you can't average an average. Constraints make those rules explicit, so people don't misuse the metric downstream.

Carrying on, you append a time component. That time component could be a snapshot of right now, all time, or a comparison like this month versus last month. It adds context about when you want to look at that metric. Finally, dimensions are the perspectives applied to that definition, the ways you slice and aggregate the data based on the grain you've specified: by region, by product, by team. A combination of all of these things, the calculation, the grain, the constraints, the time context, and the dimensions, forms the metric. If that sounds familiar, it should!

This is essentially what OLAP cubes were trying to solve decades ago: pre-computed measures, sliced by dimensions, with defined aggregation rules. The difference is that cubes were a technical implementation, a physical thing locked inside a specific platform. What I'm describing here is the logical contract of a metric, separated from any infrastructure. The idea isn't new. But treating it as a portable, tool-agnostic asset rather than something baked into a particular system is. Metadata stores and data catalogues get part of the way there. They capture definitions, ownership, lineage. But in practice, the actual logic of a metric, the calculations, the constraints, the rules, mostly lives scattered across every analytical surface; workbooks, SQL queries, and Python notebooks etc.

We exchange these between teams without ever realising how much the definitions drift as the business questions we try to answer change and adapt. Someone tweaks a filter in a workbook. Someone adjusts a WHERE clause in a query. Each change makes sense in isolation, but over time the same metric quietly becomes five different metrics, and nobody notices until the numbers stop matching. The heart of the problem is we've spent decades letting that agreement live inside tools instead of above them.

A report is a structured, usually static, presentation of one or more metrics over time or across dimensions. A monthly sales report. A quarterly finance pack. An operational summary. Reports answer the question: what happened? They follow a repeatable format, they're often delivered on a schedule, and they can live in a BI tool, a spreadsheet, a PDF, or a slide deck. In most analytics contexts, reporting is largely covered by the metric definition above. If you've defined your metrics properly, with the calculation, the grain, the time context, and the dimensions, then a report is really just a packaging of those metrics into a format someone can consume.

A dashboard is where things get interesting, because I think a lot of what passes for dashboarding today is actually reporting, and alot of what we consider reporting to be should just be a series of metrics delivered in a light way format rather than the heavy handed mechanisms we use today. People build something in a BI tool, put a few charts on a page, maybe add a date filter, and call it a dashboard. But what they've really built is a report that happens to live inside a BI tool. A true dashboard is an interactive, visual interface that lets someone explore metrics in real time. The key difference is exploration. Dashboards answer: what's happening now, and why? They're built for ongoing use, and they let you filter, drill down, compare, and investigate. If the person consuming it is just reading a fixed set of charts on a schedule, that's a report. If they're actively exploring, asking follow-up questions of the data, changing the scope, comparing segments, that's a dashboard.

And there are some types of information that genuinely need a dashboard. Take analysing Airbnb locations in a particular city. You might have a list showing the most expensive rentals, but you simultaneously need to interact with a map to see where those locations are. It's the multi-modality of those two things, the tabular information and the geospatial information, working together in the same view that makes it a dashboard use case. Only a dashboard can cross those different representations and let you explore the relationships between them. But if all you needed was a list of the most expensive rentals? That's a report. You don't need a dashboard to do that job.

An app is a fairly new addition to the analytics landscape. Applications have existed for a long time, obviously, but in the BI space they've not been a common part of how we talk about what we build. Maybe I'm pushing it too far to say it's a term we all need to get familiar with. But I'm including it here because Sigma Computing, a relatively new tool, is positioning its entire brand around this concept. So let me first define what I think an app is, and then we'll talk about how Sigma frames it, because there's some overlap but also some key differences.

To me, an app is a purpose-built, interactive experience that goes beyond viewing data. Apps collect input, trigger workflows, and write data back. They're designed around the user's workflow rather than around the data model. But I don't think it's quite right to say that apps answer the question "what should I do?" That implies the user already knows what action to take, and the app just facilitates it. In reality, a well-designed app guides you through a specific workflow that progressively reveals the actions you need to take.

Think about finding an Airbnb listing. You don't open the app already knowing which property you're going to book. The app guides you through a workflow: enter your dates, set your budget, browse locations, compare options. Each step exposes new information and narrows the possibilities until you arrive at a decision. The app didn't answer a question for you. It walked you through a process that led you to a conclusion. It's the same with something like filling in an insurance claim. You have a bunch of parameters in your head that you know you'll need to enter, but you don't already know which policy is right for you. You expect the interaction with the application to help reveal that. That's what separates an app from a dashboard. A dashboard helps you understand what's in front of you. An app puts you on a path and doesn't let go until you've reached the end of it.

These four things sit on a spectrum. Metrics are the foundation. Reports present metrics. Dashboards let you explore them. Apps let you act on them. Each one builds on the one before it, and each one requires a progressively more sophisticated delivery mechanism.

Here's the point I want to make: metrics cover the majority of use cases for most people. If we started from that foundation and built solutions outward from it, things would be faster, easier, and far less wasteful. Instead of jumping straight to a dashboard or an app, you start with the metric and then graft on only the added capability that each format is truly good for. Need exploration across multiple representations? That's when you reach for a dashboard. Need a guided workflow? That's when you build an app. But for the vast majority of what people actually need from analytics, a well-defined metric, delivered simply, does the job.

If you get your framework for metrics right, everything else becomes simpler. And if you get them wrong or even miss the opportunity to frame them as such, nothing else matters.

We're heading into a world where the tools change faster than we can evaluate them. AI is accelerating everything. New BI platforms appear every year. The warehouse ecosystem is evolving rapidly. And every time a company switches tools, or adds a new one to the stack, they have to rebuild everything: the dashboards, the reports, the calculations, the logic. Because all of that intelligence is locked inside the tool. OSI aims to solve this but I have my reservations.

This brings me to something I've been hinting at for a while and that is Sigma and Apps. Sigma wasn't the first to conceptualise this idea. Alteryx has had this concept within its platform for a while, and it follows largely the same recipe. You give an interface to an existing process, and you're able to interact with that process by intercepting specific decisions in the workflow. Change the input, change the output, change any part of the process to arrive at a radically different outcome. The idea is that by exposing those decision points, you let someone shape the result without needing to understand the mechanics underneath.

Sigma has been leaning into this concept much harder, and it represents a fairly new take on it. Their tagline reads "AI Apps and analytics built on trust." First of all the AI part of that feels forced. Most apps, most good apps don't need AI in my opinion but hey you have to have AI on your landing page right? Carrying on, they've gone as far as defining what a real data app is versus what they call "imposters." A CSV uploader? Not a data app. A dashboard with a button? Not a data app. A real data app, in their framing, is a repeatable workflow built on your cloud data that can write back to the warehouse and be built without code.

The instinct is right! The analytics industry has spent years building tools that are fundamentally about consumption. You connect to data, you build a chart, someone looks at it. The interaction model is read-only. The idea of moving beyond that, of building things that let people interact with data, trigger actions, and write back to the warehouse, whilst isn’t new, is a genuinely important shift thats gaining traction especially alongside the conversation around AI.

But here's where I think Sigma is making a mistake, and it's one I've seen before. Sigma builds everything inside what I'd call the traditional BI framework. Workbooks, pages, tables, actions, charts, filters, layouts. That framework is great for analysis, reports, and dashboards. It gives you lineage, governance, a semantic understanding of data relationships. But apps are a fundamentally different thing. Software applications do bizarre, wonderful, highly specific things with data precisely because they're not bound by the abstract constraints of business intelligence. Apps work with multiple data formats, combine inputs from different systems, and have complex navigation, conditional logic, and user flows that look nothing like a dashboard with some filters on top. Additionally most apps use a data architecture not underpinned by SQL. Web apps in particular usually function off a push or pull system with API calls between and semi-structured data structures such as JSON and they run lightning fast. If your into web development and have ever used an app built on Svetle, you know what i mean.

I've seen this play out in Tableau for years. People try to build apps inside Tableau using parameter actions, navigation buttons, dynamic zones, and conditional formatting. I've called them hacks for many years and I've personally avoided them at every possible opportunity. Sometimes the results can be impressive and repeatable. But you're fighting the tool the entire way because it was designed for a different job. I see Sigma heading down the same path: we have a powerful BI engine, so let's extend it to do apps as well. The reality is that the interaction model for building an app is fundamentally different from the interaction model for building a report, and trying to serve both through a single framework means neither one gets the experience it deserves.

What Sigma should really consider is a separate design interface for apps, maybe even a different query architecture. Something that doesn't inherit the constraints of the workbook model. Keep the BI framework for what it's great at: exploration, analysis, reporting. Give apps their own space. The two can share infrastructure under the hood, the same warehouse connections, the same governance, the same semantic definitions. But the authoring experience and the mental model for the person building the thing should be different, because the jobs are different.

I will say that Sigma is a relatively young entry to the analytics market, only reaching $100m in ARR in 2025. I mention this because if I think back to Tableau, it was about this age when they really started to run.

I recall the ideas and then features coming thick and fast, and they learnt a ton about their own product in that same period. If I'm reading this right, Sigma has likely learnt a ton about how its customers want to use apps, all the corners customers have got themselves into, and the key solutions they need to build into what I'll nickname Sigma Apps 2.0. Sigma could learn a lot from Retool. Retool, like Sigma, targets the same "app builder" customer profile, but it's more aimed at developers and engineers who want to build tools quickly. It wouldn't be a good fit for even an experienced analyst or BI developer, but their tooling and the app-building experience is not tied down by a BI framework. That freedom shows.

And this connects directly back to the metrics argument. If apps were built on top of a tool-agnostic metrics layer rather than inside a BI framework, they'd be free to do what apps do best without inheriting the limitations of how the analytics tool happens to organise information.

The future isn't about building everything inside one tool. It's about building the right foundation, getting your metrics right, and then letting the best tools for each job sit on top. The companies that figure this out won't just move faster. They'll stop rebuilding the same thing every time the landscape shifts, and in this industry, that's the closest thing to a competitive advantage you can get.

As always, I'd love to hear your thoughts. Over the next 4 weeks I'm going to explore some relatively "new" tools in our space. Each week, focus on one tool. On my list to explore Sigma, Enso, Hex and Omni. Why these? They excite me and I see others getting excited about them too, that's all. I'll share why in the coming weeks.

AI use : I want to be transparent going forward.