NextWave Insight
An Independent Overview of the Latest Trends & Technologies in Embedded Analytics.
Articles posted are my own thoughts and are not commissioned by any vendor.
NextWave Insight
An Independent Overview of the Latest Trends & Technologies in Embedded Analytics.
Articles posted are my own thoughts and are not commissioned by any vendor.
I've had several conversations lately where, at some point, I get the question "which vendors provide data product capabilities?" It only took me hearing this question 5 or 6 times before I thought that perhaps I should create a list of embedded analytic providers.
My hope is that this will provide a good starting point for product leaders trying to select a vendor for their analytic application.
Note: this isn't a list of recommended vendors or platforms, it's just... a list. If I've left out a vendor that you feel should be included, please let me know.
During the implementation of my first analytic application, it was only near the end of the project that I realized that we weren’t showing data in a single, common currency. We had euros mixed with rubles combined with the currency we were supposed to be using — U.S. dollars. The lesson? Take data preparation seriously. Here’s my checklist for data prep.
Each time I start a new project helping a team build analytic into their application, I start at the same place: the plan. Often I’ll hear the same thing — “we don’t need to talk about that; we’re past all that.” That’s what I thought too, back when I built my first data application. It wasn’t until later in the project, when I started having some issues, that I realized I’d skipped over a few things in the plan.
When I speak with product teams about the best practices for building analytical applications, there's one story I always tell. It's about how in those first few projects I made a huge number of mistakes but I managed to do one thing right: I wrote down what I learned from all those mistakes. It occurred to me that perhaps the best use of those lessons isn't keeping them all to myself, parceling them out over time in presentations here and there. Maybe it's better to combine them all into a series of learnings that I can share with others. And that's what I've done here.
Today, the world has changed. In that myriad of analytic platform options, there is a wide range of technologies, from those developed dozens of years ago to those that are only a year or two old. As a result, the capabilities of platforms are much more wide-ranging than they were five years ago. If I were making my decision these days, I’d start by identifying those platforms designed for the future, that have modern functionality, that take advantage of new technologies and approaches to delivering analytics. But what makes a platform “modern”? Here’s what I think of when I separate the analytic platforms of today from those of yesteryear.
When I get an email from an analytic platform vendor asking if I’d like to check out a new feature release, it feels a bit like Christmas. It’s like getting a present that’s oddly-shaped where you have no idea what lies inside. Will it be that awesome new gadget I wanted or will it be an ill-fitting sweater?
When I heard from GoodData that they had a new release that they wanted to share, all sorts of images popped into my head. Would this be a new iPad or a pair of pink bunny-shaped earmuffs? Hmmm…
I was prepared to be unimpressed when I received a product announcement email from Periscope Data a few weeks ago. I assumed that they had added new theme options, could now connect to some obscure database, or had received some fresh new certification. Boy, was I wrong. This is a game changer.
When I received the task of monetizing the data generated within a company that first time, it’s possible that I was… a bit… perhaps… overconfident. I mean, it’s theoretically accurate to say that I thought I knew way more than I really did when looking back at that first project. I’ve heard it said that the human body completely regenerates itself every ten years, so I feel completely confident in saying — that other guy made a lot of mistakes.
The new me, however, has learned from that other person’s missteps.
When you look at the analytic landscape, it becomes apparent that most platforms are either directly focused on enterprise analytics or are derived from platforms intended for use inside a businesses walls.
It’s rare to find a platform that works both for internal analytics and for data product teams. Looker is that rare platform that, while initially focused on internal use cases is an excellent choice for those seeking to build data products with embedded analytics.
Looker’s cloud-based approach offering fast, flexible, and powerful analytics allow data product teams to focus on creating value for their customers rather than on the care and feeding of analytical systems.
Data products are different from enterprise analytics, and as a result, product owners need to seek out slightly different functionality when selecting a platform on which to base their data-driven functionality.
Beyond the data loading and visual analytic requirements, product teams need:
Building a data product can be a real nightmare for a product leader.
An actual nightmare as in, it can keep you up at night working about all of the things that can go wrong.
Will it function in an embedded environment? Will it scale to thousands of customer tenants? Will it make life difficult when I need to rollout a new version? Will the vendor “pivot” and stop focusing on data products?
If you are building an application with customer-facing embedded analytics and you value your sleep, you need to make the right choice when you pick a platform.
I’d like to introduce you to Izenda—a platform purpose-built for embedded analytics backed by a team that understands what it means to make analytic-powered applications successful.
Often analytics fall into one of two camps: either you’ve got powerful functionality that can serve the needs of the data scientists inside your business, or you can have flexible, user-friendly analytics that are suitable for use by customers as part of a data product.
The “analyst” oriented tools are extremely powerful, but they require expert knowledge of databases, data modeling, and languages like SQL, R, and Python. The “customer” oriented platforms look great and are easy to use, but often lack the capabilities to perform the sophisticated analysis required by analysts (or many power users).
The use cases just don’t overlap—you’d never use one product for both of those scenarios. Or would you?
What if you built a data product and no one came? What if you spend months evaluating vendors, connecting to data sources, designing beautiful dashboards and no revenue was generated? If your customer-facing analytical application became a cost center rather than a tool to drive customer engagement and revenue? It's not a far-out scenario — it happens, and it happens frequently. And it happened to me.
Being a product owner is a little like being a parachute packer… Nobody pats you on the back and congratulates you for each successfully completed task. People only seem notice when you get it wrong—and then, they really notice.
One of the first tasks faced by product owners building a data product (analytical functionality embedded in a core product) is to decide: should we buy it or build it?
Recently, I’ve been frustrated with some of the articles I’ve read about building great analytics dashboards. Their titles often led me to believe that they contained must-have insights about creating dashboards that engage users, but in the end, most are about use of color, pretty charts, and the latest feature a particular vendor has launched. And in my experience as a data product builder, these things aren’t what will make your embedded analytics product a success.
Not too many years ago, I was charged with building my first analytics-based product for the company I had just joined. I wrote user stories, worked with Engineers and interaction designers, and visited users. I did everything right.
Except I didn’t.
It's the nightmare that keeps analytics leaders up at night:
Our analytics—the ones we spent so much time and money on—the analytics that were supposed to generate new revenue and new customers, are failing.
Whether you are building a customer-facing data product or implementing analytics inside your organization for internal use, the fact is that some analytics projects do fail. But when they fail, they almost never fail the way you think they're going to...
As a data product builder — someone building customer-facing analytics that to will be part of a product — the needs are no different but achieving agility can be a real challenge. Oh sure, every analytics platform provider you might consider claims that they can connect to any data, anywhere, but this leaves a lot of wiggle room. Can you really connect to anything? How easy is it? How hard is it to change later? What about [insert new technology on the horizon here] that I just heard about? If you want to build an agile data product, you've got a tough road ahead... as I found out.
It's one of the most important decisions you can make when adding analytical capabilities into a product. And, unfortunately, it's an easy one to get wrong. What platform should you choose? There are a hundred options these days—each claiming to have what you need. How do you decide? Here are three tips...
Before you start evaluating features or selecting vendors, you need to get a handle on what YOU mean when you ask for analytics in your product. Although it seems simple, it really isn't so straightforward. There are many ways to "embed" analytics in a product and the method you choose can create limitations for your product roadmap and determine the overall user experience for your customers.
A great place to start is by understanding the "Three Faces of Embedded Analytics". It's a great starting point because this simple concept is directly tied to defining the underlying data you'll need to access and to the ways you might offer your data product to users. Get it wrong and you can end overlooking some valuable ways to generate revenue.
It happens every time. Every single time.
From the moment I meet a customer for that very first session, the clock is ticking. It might be seconds, it might be minutes, it might be hours—but it always happens. They always ask the same question: "how can I make money with my data?"
Back in the early 1990's, I created one of the first metric dashboards for the telecommunications company I had just joined to help improve business processes. My goal was simple: build a web-based dashboard that let management view charts showing the performance of key processes. Sounds pretty simple, right? Today it would be, but 20 years ago creating "business intelligence dashboards" was a convoluted process at best.
Here's what the workflow looked like back then. First, I created the intranet site that would serve as the holder for the dashboard charts. It was pure Microsoft FrontPage with a black background, animated GIFs, and crazy colors...
In my experience building data products over the last ten years, the technical parts of the project are rarely what will jeopardize success. Between the sophistication of today’s embedded analytic platforms and the implementation services offered by vendors, you’re pretty much covered when it comes to the technical side of things. It’s the non-technical stuff that’s going to be your downfall if you’re not careful.