Avoiding death by dashboard
1. Avoiding death by dashboard
In a past role, I used to watch more senior analysts with total admiration. They had this amazing ability to receive vague requests, like, show me which products perform best in Q3, but don't forget those external factors. They're able to produce spot on, neatly packaged insights from this. I found this impressive, but when I tried it, it was often not as straightforward as it seemed. I'd take what I thought my manager was asking me and craft a query to get the answers, only to later realize I'd misunderstood what perform best really meant. Did they want the products with the highest revenue, or is the margin more important? What are these elusive external factors, and how exactly was I supposed to handle them? I'd end up with numbers that weren't quite right, leading to a lot of follow up questions and frustrated stakeholders. Meanwhile, the senior analysts never seemed to be bothered by this. When a request came in, they'd casually ask a few extra questions. Can you clarify what you mean by when you say best? Or they would adjust their approach on the fly, by interpreting what the user was really asking for. They had a really good sense of this. For me, it felt like playing phone tag with incomplete information. I knew how to write really good SQL, but the real trick was decoding what was really meant when they tossed out terms like perform best and factor in. I wanted the interpretation ability that I saw from more senior people around me. It finally dawned on me it was about bridging the gulf between fuzzy human language and the data I had on hand. And even when I leveled up to become a senior analyst that understood the nuances between my stakeholders' requests and how they connected to the data, I had a growing list of requests to complete. This caused my stakeholders to sometimes wait days or weeks for answers to their questions. So today, in order to be effective in business, you need to be able to reliably answer questions based on structured organizational data. In a short timeframe, minutes are better than hours, hours are better than days or weeks, and seconds would be pretty cool too. Decision makers need to have fast and accurate information so that they can respond to changes in the market environment as they happen. Imagine I tried to solve this by building a dashboard. This dashboard displays the information that I was asked to gather and updates daily. I have created a persistent tool, but one that is purpose-built to answer a single question or a single series of questions that were determined in the initial request. Over time, more follow-up requests come in. I modify the dashboard or create a new one for each new request that comes in. But after a while, these dashboards really start to pile up, and this can result in death by dashboard. Dashboards that may see little use or be subject to constant change requests. This sounds like it's trending towards a desire for a personal assistant that can quickly and accurately answer any question asked of it. More on that later. You may have dealt with this firsthand. I know I have. Bespoke query generation is not time-efficient, and neither are dashboards. We can do better. Situations like these would be better served by an immediate answer to a question in a natural language anyone can understand, English. But the person who comes in with a question will not ask you, what was the sum of rev between Jan 1 and end of March? They might ask you, which sales region had the highest single-day earnings, and what was the amount? This leaves you decoding the request, creating the bespoke query, and then going about making a dashboard or writing a report. You're manually doing all of the steps that a text-as-equal application can do. This is the old way, but it's not the only way. In this module, we'll untether ourselves from the death-by-dashboard spiral and build an app that provides direct access to structured data for decision makers, business users, and executives to query and use directly, all done with natural language. So let's talk about what we will cover in this module. You'll learn how to use the Cortex Analyst API to create a text-as-equal app in a Snowflake Notebook. You'll learn all about semantic models and how they can give LLMs the power to write accurate SQL that works on your complex database. And you'll learn how to take SQL generated by Cortex Analyst, dynamically execute it, and use LLMs to interpret the result back into natural language. Full circle. And then you'll take that, and you'll bring it into Streamlit, so you can bring this functionality to your users. This will free up time that you've used in the past to manually query structured data, which you can now use for higher-level work. Excited? Let's get started.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.