Search is the Future of Self-Service Analytics
Tl;dr: Previous iterations of self-service platforms have just been dressed-up SQL editors. Solving self-service means meeting non-technical users where they are. Natural language search is the solution that will finally bring all stakeholders off the sidelines and into the data fold.
Published on March 6, 2023 by John Willett
The broken promises of self-service platforms.
At this point there have been a few generations of analytics platforms that have gone to market under the ambitious banner of “self-service.” Products in this category have ranged from beefed-up SQL editors to heavyweight business intelligence platforms to Excel data loader plug-ins. More recently they’ve begun to conform more and more to the mold of pared-down graphical query builder.
These products have created value and have generally improved decision-making. But no one has managed to deliver on the promise of universal self-service across the org. Still the vast majority of corporate decision-makers cannot access or analyze their company’s data themselves.
At best, we’ve seen a new class of semi-technical workers rise on the margins. These are typically younger analysts (and sometimes managers) who have taken the time to learn the basics of one of these platforms.
The promise of true self-service is a lot more ambitious. The future of the space will erase the data viz silo entirely, such that anyone whose work is affected by a number is able to access that number herself—no matter her technical background.
These products have created value and have generally improved decision-making. But no one has managed to deliver on the promise of universal self-service across the org. Still the vast majority of corporate decision-makers cannot access or analyze their company’s data themselves.
At best, we’ve seen a new class of semi-technical workers rise on the margins. These are typically younger analysts (and sometimes managers) who have taken the time to learn the basics of one of these platforms.
The promise of true self-service is a lot more ambitious. The future of the space will erase the data viz silo entirely, such that anyone whose work is affected by a number is able to access that number herself—no matter her technical background.
The hard part of using SQL isn’t SQL.
Why haven’t previous iterations of self-service analytics platforms delivered on that promise? It’s because they’ve misdiagnosed the problem—or at least underestimated the depth of the problem.
The conventional pitch for these products goes something like this. First we’re asked to picture a non-technical business end user—let’s say a product manager named Alice—who commonly sends analytics requests over Slack to her colleague from the data team. Let’s call him Bob. Those requests look something like: "Hey Bob, get me a bar chart of our 2019 revenue broken down by product line.” This request goes onto Bob’s backlog. He can’t get to it until two days later. Once he finally sends it back to Alice, of course, the meeting she was prepping for has already happened. Alas, insight missed. Time wasted. Gasp.
Wouldn’t it be great—we’re asked— if Alice could just pull that number herself? Enter: a set of dropdown menus that styles itself “self-service.” Now, with just a few clicks Alice can replicate any Slack that she might send to Bob throughout the day and just build the chart herself.
It’s a compelling story, even tempting. The problem is not in the conclusion but in the opening premise. These platforms presuppose that non-technical business stakeholders are coming to work at 9:00am on any given Tuesday with a set of perfect, fully-formed SQL-style queries in their heads. They know not only which tables but which columns they want, what’s being aggregated on, where there should be a filter, what’s being grouped on, and the precise form that the answer should take. And the only problem is that they don’t know SQL.
Phrased like this, it’s not hard to see that this is too hopeful a picture. At their best, these platforms are user-friendly wrappers on SQL. At their worst (as we sometimes joke at Rogo), they are “lipstick on a pig.” As anyone who has written SQL knows, the hard thing about writing SQL isn’t learning SQL’s syntax, even for the relatively simple queries self-service platforms are aiming to aid. The real problem is that non-technical users tend to be armed with only relatively vague, underpowered business questions. And—relatedly—they don’t know enough about the structure of the relevant database(s) to use a query-builder effectively.
Readers who have been in Bob’s seat know that in real life those Slacks look less like “get me a bar chart of our revenue broken down by product line in 2020” and more like “which of our product lines have been resilient to the supply-chain issues in the Midwest?” or “which segments of our biggest buyers are least reactive to price changes?”
The conventional pitch for these products goes something like this. First we’re asked to picture a non-technical business end user—let’s say a product manager named Alice—who commonly sends analytics requests over Slack to her colleague from the data team. Let’s call him Bob. Those requests look something like: "Hey Bob, get me a bar chart of our 2019 revenue broken down by product line.” This request goes onto Bob’s backlog. He can’t get to it until two days later. Once he finally sends it back to Alice, of course, the meeting she was prepping for has already happened. Alas, insight missed. Time wasted. Gasp.
Wouldn’t it be great—we’re asked— if Alice could just pull that number herself? Enter: a set of dropdown menus that styles itself “self-service.” Now, with just a few clicks Alice can replicate any Slack that she might send to Bob throughout the day and just build the chart herself.
It’s a compelling story, even tempting. The problem is not in the conclusion but in the opening premise. These platforms presuppose that non-technical business stakeholders are coming to work at 9:00am on any given Tuesday with a set of perfect, fully-formed SQL-style queries in their heads. They know not only which tables but which columns they want, what’s being aggregated on, where there should be a filter, what’s being grouped on, and the precise form that the answer should take. And the only problem is that they don’t know SQL.
Phrased like this, it’s not hard to see that this is too hopeful a picture. At their best, these platforms are user-friendly wrappers on SQL. At their worst (as we sometimes joke at Rogo), they are “lipstick on a pig.” As anyone who has written SQL knows, the hard thing about writing SQL isn’t learning SQL’s syntax, even for the relatively simple queries self-service platforms are aiming to aid. The real problem is that non-technical users tend to be armed with only relatively vague, underpowered business questions. And—relatedly—they don’t know enough about the structure of the relevant database(s) to use a query-builder effectively.
Readers who have been in Bob’s seat know that in real life those Slacks look less like “get me a bar chart of our revenue broken down by product line in 2020” and more like “which of our product lines have been resilient to the supply-chain issues in the Midwest?” or “which segments of our biggest buyers are least reactive to price changes?”
Enter: natural language search.
Putting it all together, we reach a key insight: What needs to be minimized is not time from SQL-like thought to SQL query, but time from vague business question to SQL-like thought. That’s an ambitious problem statement, and one would be in good company if they were scratching their head on how it could be solved.
The good news? We’ve solved it once before.
(Or at least something like it.)
The good news? We’ve solved it once before.
(Or at least something like it.)
Think about the last time you Googled something. Perhaps you searched: “Who was the Prime Minister of Cuba in 1962?” If you did, good for you. That would be analogous to the original fictional question from Alice above. It’s a specific, well-powered, deterministic data pull. If you’d like, we could almost imagine (keyword: “almost”) a set of dropdown menus on Google’s home page that could help you get to this answer.
More likely, though, you Googled something like “Elon Chappelle” because you heard Elon Musk did something embarrassing at a Dave Chappelle show and you want to get the story. And then that search turned into additional searches about what else Elon has said or done recently, what people are saying about the incident, and how Dave and Elon even know each other. At the end of all that—perhaps 5 or 6 searches later—you felt satisfied that you understood what had happened.
More likely, though, you Googled something like “Elon Chappelle” because you heard Elon Musk did something embarrassing at a Dave Chappelle show and you want to get the story. And then that search turned into additional searches about what else Elon has said or done recently, what people are saying about the incident, and how Dave and Elon even know each other. At the end of all that—perhaps 5 or 6 searches later—you felt satisfied that you understood what had happened.
This model has proven arguably the most successful consumer workflow in tech history. The aim of search-based analytics is to replicate it in data. The goal is to give people an interface that gets them off the starting line and into their company’s data with as little friction as possible. The search bar provides an entry point that is as open-ended and low-barrier as it is familiar and intuitive. In many cases, the first thing the user pulls is not the precise answer they are looking for. That’s fine, because it gets them closer to what they actually want.
The bar for quality is high in the world of self-service analytics adoption. An important, if inconvenient, lesson we’ve learned over the last ten years is that non-technical business end users—particularly senior ones—are not going to widely adopt a platform that is more difficult for them than Slacking data analysts is for them. To really drive change within the org, an analytics product needs to be as easy, empowering, and stress-free as iterating with a data analyst, for at least a reasonable and reliable universe of simple queries.
With the recent explosion of LLMs meeting the explosions of cheap data storage and movement options and rich data models, natural language search finally has the potential to meet those standards. Over the last few years, the question has gone from “if” to “when,” and more recently it feels like the only important questions are “who” and “how.”
(Under the umbrella of natural language search, there are a few dominant approaches. Most recently, of course, a few companies have added text-to-SQL engines via GPT-3 in the hope they can cut down on data requests this way. Our view is that conventional end-to-end text-to-SQL models fail to meet the challenges mentioned here for some the reasons described above, along with a few others. We have a blog post on that topic coming soon.)
The bar for quality is high in the world of self-service analytics adoption. An important, if inconvenient, lesson we’ve learned over the last ten years is that non-technical business end users—particularly senior ones—are not going to widely adopt a platform that is more difficult for them than Slacking data analysts is for them. To really drive change within the org, an analytics product needs to be as easy, empowering, and stress-free as iterating with a data analyst, for at least a reasonable and reliable universe of simple queries.
With the recent explosion of LLMs meeting the explosions of cheap data storage and movement options and rich data models, natural language search finally has the potential to meet those standards. Over the last few years, the question has gone from “if” to “when,” and more recently it feels like the only important questions are “who” and “how.”
(Under the umbrella of natural language search, there are a few dominant approaches. Most recently, of course, a few companies have added text-to-SQL engines via GPT-3 in the hope they can cut down on data requests this way. Our view is that conventional end-to-end text-to-SQL models fail to meet the challenges mentioned here for some the reasons described above, along with a few others. We have a blog post on that topic coming soon.)
Sign Up
Rogo is super low effort for your team to set up. If you or your team wants to get more out of your data, sign up below.
Get up and running in five minutes, and make everyone in your company smarter.
Company
2023© Rogo Technologies, All Rights Reserved.
Privacy Policy & Terms of Use
