What’s the Difference Between BI & Product Analytics?

What exactly is the difference between Business Intelligence (BI) and Product Analytics?

Is Product Analytics just a subset of BI?

If my organization has a world-class BI team working with a best-in-breed BI platform, then we should be able to answer all our data questions – without adding in a Product Analytics practice as well, right?

These are questions I hear often from companies that are thinking about getting started with Product Analytics, and I fully understand why there’s a lot of confusion! After all, BI has been around for a long time, and Product Analytics is an emerging and rapidly-changing field – so for most people, learning about Product Analytics involves a steep learning curve.

I wrote this article to help explain the key differences between BI and Product Analytics, and to clear up some common misconceptions about the use cases specific to each.

First: basic definitions

Before we look at what makes BI and Product Analytics different from each other, let’s lay out the basic definitions.

‍Business Intelligence is a longstanding discipline for businesses to understand critical metrics for all parts of their organization.

Typically, these metrics are derived from your organization’s data warehouse, and are built using tools like Looker, Tableau, or Power BI. Metrics span different departments including Revenue, Customer, Operations, Marketing, etc.

In some companies, BI is a standalone team. In others, it’s a unit – or just one or two individuals – within a broader Data team composed of BI Analysts as well as Data Engineers, Analytics Engineers, Data Scientists, and an ever-evolving list of other data titles.

‍Product Analytics is a relatively new discipline that allows everyone from Product, Marketing, and Growth to understand how users are engaging within your digital products. You generally start with a tool or platform specific to Product Analytics, which allows end users to self-serve on large amounts of data, quickly. The field focuses primarily on time series data and typically results in cohorts or user segments based on behavior. It’s collected from your digital product – such as your app, your streaming platform, your website, your online store, your connected device(s), etc.

That data is streamed into your Product Analytics platform (traditionally, tools like Amplitude and MixPanel). There’s also a new generation of warehouse-native Product Analytics platforms – like Kubit (where I work) – which accesses the necessary data directly from your data warehouse.

(Note: You’ll sometimes see Product Analytics referred to as Digital Analytics, Web Analytics, User Journey Analytics, or Behavioral Analytics; I think some of these names might actually be more apt than “Product Analytics,” but that’s a topic for another blog 😆).

‍

Difference #1:
BI looks at the past,
Product Analytics looks at the present

I’ve found the best starting point to understand the difference between BI and Product Analytics is this: think of BI as helping you understand what happened, and Product Analytics as helping you understand what is happening.

When I’m asked to provide the biggest difference between these two capabilities, it always comes down to… “What are you trying to learn from this data?” What I mean by that is, do you need a monthly count of some number to show what happened? Or, do you need pathing and conversion analysis at the session level to understand what’s happening?

BI does a great job of showing, for example, how many users took a certain action in your product or on your website. Product Analytics, by contrast, will show how the users got there, and what they did once they got there.

Product Analytics, and the tools that facilitate it, are unique from a lot of data analysis in that counting things is not enough.

Product Managers and Product Analysts are asked to understand:

• user journey
• paths through a product
• points of friction
• areas of optimization.

This is the “happening” part that makes Product Analytics unique and so valuable to those who build the product.

Difference #2:
Data modeling not the same in BI vs. in Product Analytics

Let’s look at how an organization’s data needs to be modeled for BI vs. for Product Analytics.

Typically in a BI tool, you need the data aggregated to a certain extent – for two main reasons:

1) Performance of your dashboards (you don’t want to use Looker to crunch those numbers all the time)
2) For most BI metrics, aggregated data is good enough.

For Product Analytics – where you’re on a quest to understand what’s happening – the more granular the data, the better. So you don’t want aggregation, and timestamped data is king.

In Product Analytics, the data needs to traverse several different use cases, including “metrics over time,” “metric per user,” “metric per session,” etc. You don’t want, for example, 4-5 different aggregated datasets driving metrics;  instead, you should have one large dataset at its lowest level of granularity, allowing for all possible questions to be asked.

This level of granularity allows for pathing of user journeys and fine-tuning of conversion funnels. It unlocks areas of opportunity, moments of user friction, and surprising paths that may have gone unnoticed.

‍
Difference #3:
Product Analytics provides swift, self-served answers

Some of the questions asked of BI and Product Analytics can be similar, but Product Analytics excels at answering urgent questions quickly.
‍

Often when a stakeholder asks the Data or BI team a question, the question goes into a queue and a data model for that specific question is used or created. Then the Data Analyst or BI Analyst interprets what the stakeholder wants to know, and develops the dashboard/chart to provide the answer.

For exceptional Data/BI Analysts, this process may take hours or a day. More often, it takes several days of back-and-forth before the Analyst is ready to share insights with the stakeholder. It’s not rare to experience long delays caused by emails and, even worse, having to file a ticket. This workflow can be perfectly fine when the stakeholder isn’t in critical need of the answer… When their question is of the BI-flavored “what happened?” variety.

But what if that same Data Analyst was asked to answer a question that was only relevant for the next 48 hours? It’s here where the crunch of time and resources is felt, and where Product Analytics thrives.

Fortunately, good Product Analytics tools enable the stakeholders asking these questions to answer most (if not all) of their questions themselves. Product Analytics platforms give Product teams, and other stakeholders, self-service access to the full dataset they need –  with a straightforward point-and-click UI.

When Product teams are equipped with the right Product Analytics tool, they’re no longer stuck waiting on Data/BI Analysts to process their requests. It’s good for the Product Managers, and also for the Data/BI Analysts who are no longer inundated with fire-drill-type questions from Product.

Finally, I should mention one more – very important – benefit of the self-service nature of Product Analytics. Self-service provides more than just the speed and convenience advantages I’ve already described; it also goes a long way towards guaranteeing the accuracy of the reporting. This is because, with self-service analytics, the details of how a chart is constructed are passed along with every insight. This makes it possible to check for errors each step of the way, and empowers everyone to learn from and expand on each other’s work. This is a far cry from typical BI reports, where there’s no easy way for the requestor to check or verify whether the report was built per spec. In BI, very often a misunderstanding or mistake slips through the cracks – until it’s too late!

Difference #4:
User base of Product Analytics is bigger than that of BI 

Another big difference between BI and Product Analytics: the ideal user base of Product Analytics is larger and broader than that of BI.

Notice I said user and not consumer.

Let me explain.

A hard requirement for any Product Analytics tool is high adoption of non-technical users.

Product Analytics platforms are designed for the Product team to find essential insights and explore the data without having to bother the Data team.

This is very different from traditional BI tools, which are built for Data and BI Analysts – specialists who live and breathe data, who understand how to take a blank slate and turn it into the chart they need, and who generally are comfortable in one or more coding languages like SQL, Python, etc.

Why is it that Product Analytics platforms can be friendly to less-technical and even non-technical users? Well, ultimately, Product Analytics is based on common questions that most users need answered – so Product Analytics tools come with pre-built reports. All the user has to do is select inputs for the following:

• events to analyze
• user segments to filter by
• fields to group by.

Self-service tools like this can be used not just by the Product team, but also – as needed – by other stakeholders like Marketing and Growth.

To get a sense of the wide array of people and teams who can use Product Analytics, here are a few examples of how our customers use Kubit:

• Product teams use it to ask questions about critical user paths, feature adoption, retention, etc.
• Marketing teams use it to understand the effectiveness of its campaigns and ROAS against longer-term metrics, like engagement 7 days post-acquisition
• Growth and Content teams use it to quickly see impacts of the new premiers or experiments they manage segmented by users, and how they improve long-term retention or trial-to-paid conversion
• Data and BI teams don’t need to be hands-on in the tool every day, but when needed, can collaborate with the other teams on troubleshooting, deeper analysis, etc.

Difference #5:
In Product Analytics, getting your data infrastructure right is key

I’ve talked about building out a Product Analytics practice and how it’s different from BI, but I want to finish by honing in on what I consider the most important element of doing Product Analytics right.

I’ll explain this by first fleshing out the BI workflow a bit more. In BI, you can punish the data until it submits. This data tends to go through several steps of cleaning, aggregating, and refining before it’s ultimately shared with end users in a chart or dashboard. In short, BI data is “pretty.”

But with Product Analytics, the workflow is very different from BI. You don’t do those steps of cleaning, aggregating, and refining. Instead, everything comes down to the first step in the process: how your data is made available and governed.

In other words, in Product Analytics, getting the basics of your data infrastructure right is what really determines your readiness.

Product Analytics doesn’t have the luxury of “prettifying” its data, for a couple of reasons. First, because of the timeliness of the data – as I mentioned earlier, with Product Analytics, you generally need answers fast, answers that are relevant to what is happening now. Second, in order to do Product Analytics, you need the data in its most granular form – a form that, compared to BI data, is often quite big and ugly!

‍
What this means is you need to ensure the data stack that you’ve built, or are building, can support data availability at scale.

Simply porting over the data you’ve “made pretty” for BI into your Product Analytics tool usually won’t cut it.

For Product Analytics, you should ensure that you have the raw timestamped data, with all relevant dimensions accessible, and a Product Analytics tool that works with your setup (read more of our thoughts on an ideal data model for Product Analytics here). Legacy Product Analytics tools don’t support this capability, but the latest generation of tools, led by Kubit, do – by leveraging data directly from your warehouse.

‍

So, which do I need – BI or Product Analytics?

I hope that you now have a clearer understanding of what differentiates Product Analytics from BI.

And as you have most likely deduced on your own, for the vast majority of modern organizations, BI vs. Product Analytics is certainly not an either/or question.

You will always need BI for your traditional analytics needs. But if you want your teams to be fully equipped with the nuanced insights and reactivity needed for today’s fast-moving market, you’ll also need to build out a Product Analytics practice.

If you’re just getting started, or just thinking about getting started, fear not: there’s never been an easier time to dive into Product Analytics. Today’s warehouse-centric data architectures and workflows make it remarkably easy to implement Product Analytics derived from the same source of truth as all of your other data. At Kubit, we onboard our customers in just ten days – even enterprises with complex data infrastructures (that’s an accelerated timeline that is unheard of with legacy Product Analytics tools, which can take upwards of six months to implement).

Finally, as Kubit’s Customer Success Lead, there’s one final aspect of our platform that I would be remiss not mentioning: people who work in Kubit enjoy it. Here are just a few of the reasons why:

• They say that work that used to feel like “daily chores” becomes convenient.
• Product Managers say that their data workflows, which are becoming increasingly key to their roles, become much less of a challenge with Kubit’s easy UI that makes it easy to replicate and investigate the insights they find.
• The Product Team says that it no longer has to fear discrepancies between the data they’re using and what the Data teams and other stakeholders are using – since Product has the same transparent access to their company’s data as BI, Data, and everyone else… And all teams are working off the Single Source of Truth architecture.

Long story short: when your organization has implemented the right Product Analytics tool, all your teams will be collaborating more effectively towards their data-driven goals – which is the ultimate objective for all of us, whether you’re on the Product Analytics side or the BI side.

Rachel Herrera is Kubit’s Customer Success Lead and has more than a decade of experience helping organizations build out their analytics practices. You can write to her directly at rachel.herrera@kubit.ai. 

‍