Written by Pavel Kolesnikov |
You already own a great product–but your customers need to get more from the data they already feed into your product. Like 25% of product leaders, you know that embedding an analytics feature in your product is the logical next step. You know you need to add analytics features fast, and you are starting to understand what it takes to build and bring to market. Even if you’ve done the research, your organization can be at risk of underestimating this task if you treat analytics like any other feature, overtax existing teams, or neglect the importance of UI.
Let’s take a closer look at potential embedded analytics traps and some ideas on how to avoid them.
Trap 1: “It’s just another feature!”
- Your developers get tired of adding new and new pieces of SQL code and visualizations to satisfy a never-ending stream of requirements.
- The code base turns into a labyrinth of SQL spaghetti that makes hunting bugs painful–and slow.
- Your databases cannot handle the workload of concurrent analytics queries, so delivering analytics at scale for large customers and correctly charging small ones becomes a nightmare. This touches multiple teams, from technical operations to finance.
- The customer-specific code overtakes the base code–and makes adding new code next to impossible
- Canned dashboards are not enough for your users, and your engineers create a super-powerful ad hoc query tool, that is too complex for mere humans to use.
- You find out you don’t have any of these problems, but there are not enough engineers left in your organization to work on your core product.
Idea: Analytics is not just another feature. Instead, it’s a new product, with its own complexities, strategy, and quirks. That’s why many people embed analytics, choosing to create an embedded analytics product.
Trap 2: “We already do business intelligence!”
Just like the previous trap, this fallacy relies on overestimating the manpower already at your organization, and underestimating the challenge of data product. You probably have a team of data warehousing gurus who feed your executive team cool visualizations, and a team of analysts that can answer any question with data exploration tools. So, it may seem natural that these teams can scale their expertise into a data product for your entire customer base.
With all due respect to your data warehousing gurus and analysts, this is likely to turn out to be a very different project than they are used to:
- An analytics product for hundreds of your customers means a lot of concurrent analytics queries — which is not what your internal analytics usually handles.
- Absorbing new requirements is relatively simple for a single analytics system. How about distributing new functions to hundreds of your customers? And how about managing customer-specific customizations, while still being able to push updates to all customers? Not so simple.
Idea: None of this is rocket science but it resembles application development more than business intelligence. It may be a great learning experience for your data warehousing team–if you can afford learning from mistakes that may cause some customers to churn.
Trap 3: “They can handle raw data, right?!”
This also looks deceptively easy. You may think: let’s just dump the database and make it accessible to our customers’ database administrators and analysts, who will import it into their data warehouses (admins) or Excels or Tableaus (analysts). And for a while, this will work well. Until one of the following occurs:
- Your first change to the data model. This can break your valued customers’ data pipeline instantly.
- Your largest customers’ data grows to the point where data extraction will become enormously expensive.
- You learn that the majority of your customers really need a clean and easy-to-use user interface--since most business users don’t have the technical skills, and IT is overextended.
Idea: It’s okay to enable your customers to export the list of their accounts, support tickets, orders or whatever your product is about, in a business friendly format. It may be okay to share the raw data with a limited group of tech savvy customers if you get something in advance and if you set the right expectations. It may turn out to be what your biggest customers really need and it is perfectly okay to give it to them as premium solution. But it should never become the alternative of basic analytic capabilities of your product.
Navigate Complexity for Success
Embedded analytics can be a complex undertaking that requires the discipline of software development and a mix of data warehousing and application development skills. I don’t want to talk you out of building embedded analytics in-house with your existing application developers or your business intelligence team, but–trust me–you really don’t want to start by giving your customers raw data. Even if you go all in by building a prototype, you’ll likely run into one of the situations above. Ultimately, you’ll find that embedded analytics are the way to go.
So what’s the good news in your environment of traps? Here’s the silver lining: analytics creates value that your customers are willing to pay for. If you can fully understand the value you are bringing to the table, identify the premium features, and map them properly to your customer tiers, you are set up for analytics feature success. Avoid the traps and embed!
Written by Pavel Kolesnikov |