Embedded Analytics vs Data Apps

What’s the difference anyway?

There has been a lot of talk recently about Data Apps. We at Firebolt have been talking about it as well, being big believers that data apps are one of the most important and interesting things happening in the data space right now. 

But Data Apps is still a loosely defined term, and there’s a lot of debate and confusion about what it really means, and how it differs from traditional dashboarding and embedded analytics. I’d like to share my point of view on the subject. 

I worked in the BI space for many years. At Sisense, we competed with Tableau, Looker, and other BI vendors over the years. Embedded Analytics was a use case that only kept growing over the years, and Sisense in particular placed a big focus on it. More and more companies were looking to embed analytics into their products to add value for their customers, and embedded analytics allowed that. 

The premise for embedded analytics is simple. If I can create meaningful dashboards with today’s (or yesterday’s?) powerful BI tools, why can’t I just inject them into my web applications for end-users to enjoy as well? The self-service revolution in BI empowered non-developers to become self-sufficient when it comes to analytics, and that enabled analytics to make its way into more and more products, without the need for complex engineering projects. Embedded Analytics has been a fast-growing segment within the broader BI space for years. Check out every website of every BI vendor, and you are guaranteed to find an ‘Embedded Analytics’ section. 

But as the years went by, technologies evolved, data volumes exploded, and demand for data-intensive experiences grew to exceed what can be achieved with dashboards embedded into web applications. Enter Data Apps. 

Unlike embedded analytics, which are typically designed and delivered by Product and BI teams (with a little last-mile assistance from dev), Data Apps are delivered by Software & Data Engineering teams. This goes hand in hand with the broader trend of data projects becoming engineering heavy, looking ever more similar to software engineering, and increasingly different from  traditional BI & data warehousing. 

Data over the years has grown so much in size, variety, and complexity , that the market has realized that unless we start applying software engineering practices to tame it, we will fail. Just look at the explosion of data engineering as a profession. It’s all about the need to apply engineering practices to data-intensive challenges. You can also see this in the number of Software Engineers today tasked with building data-centric products. Ten years ago, most software engineers would look down on colleagues tasked with using SQL and spending most of their time around databases and data warehouses. But today developers re-flock to data-intensive projects.

So it shouldn’t come as a surprise that the best data experiences out there are built by engineering teams. These data experiences adhere to the same standards we’ve gotten used to in consumer-grade experiences: they’re super-fast, reliable, and always up. Unlike the (sad) acceptance of dashboards taking 40 seconds to load, a Data App experience sets a higher bar. It’s not about delivering a dashboard, but about delivering the best user experience for a particular task in which data plays a significant role. Product thinking is applied here end-to-end, just like with any feature, and data plays a role that can be either visible or hidden. 

What’s right for me?

It’s important to note that embedded analytics still has and will continue to have its place. One thing is certain- demand for data-centric experiences will continue to grow. Both embedded analytics as we’ve known it for the last decade and Data Apps will continue to play a role in it. 

Here are some questions that can help you figure out which approach to take:

Do my users need a dashboard-like experience or a customized experience?

Embedded analytics started from the world of dashboards. Although most BI vendors today offer rich SDKs and deeper customization options for developers, embedded analytics experiences tend to be more dashboard-centric. If your users' needs aren’t best served with traditional charts, and a more tailored user experience is required, then consider the Data App approach in which developers can build exactly what is needed. 

How fast does the experience need to be?

Dashboards in BI tools, whether embedded or not, tend to slow down significantly as data volumes and user concurrency start to climb. With Data Apps, engineers can implement data solutions that are more scalable and performant, to deliver a fast user experience. 

How complex is my data challenge?

When data volume and complexity is not an issue, BI & Analytics teams can be quite self-sufficient in delivering great dashboards for embedded applications. However, as data volume, variety, and complexity grows, more engineering firepower is needed to deliver robust analytics. If the data experience requires tackling a new set of yet unsolved data and analytics challenges that could exceed a simple implementation, consider relying on Engineering and going for the Data App approach.

How mission-critical is the analytics experience?

Who among us hasn’t run into dashboards being down for internal BI? Nobody loves that, and even organizations with tight SLAs around BI will reluctantly agree that customer-facing applications typically get a much higher sense of urgency when it comes to downtime and SLAs. Embedded Analytics are typically built on foundations of BI tools, which historically have been designed for internal BI run by analytics teams, and not for applications run by developers with an always-up mindset. If your data experience powers an application that needs to be consistently reliable, engineering practices are required, and Data Apps are a better fit. 

How much budget do I have?

Data Apps are engineering heavy, and as such typically take longer, are more complex, and more costly from a TCO perspective. With embedded analytics, non developers can put together dashboards, and embedding them within the application is quicker and cheaper to maintain. So while you can definitely achieve faster, richer, and more customized experiences with Data Apps, they do cost more to implement and maintain. 

How core is the data experience to the value proposition? 

If the data experience is a nice-to-have or incremental value-add, it can make sense to reduce project risks and go for a lighter-weight embedded analytics approach. 

However, if the data experience plays a significant role in your product’s value proposition, then you should favor Data Apps over Embedded Analytics. When your competitive advantage and user satisfaction depend  on the data experience, it’s worth investing resources to be able to control the experience as closely as possible, and deliver it at a consumer-grade level.

Conclusion

The most important thing really is not whether to go with the embedded analytics or Data-App approach, but to spend time thinking about the role customer-facing analytics can have on your business. You can be sure that your competitors are doing it, so don’t stay behind. We as consumers have become much more demanding for increased insights on the services and products we consume, and in parallel collecting, analyzing and delivering data-rich experiences has become more approachable than ever before. 

At Firebolt we believe that we’re just at the start of the Data-App revolution. If Embedded Analytics represented the notion of internal BI being exposed externally, then Data Apps represent the next evolution through the creation of analytics-enhanced user experiences, that adhere to the same standards and follow the same processes we know from building software products. This is why at Firebolt we’re committed to building a data warehouse for developers that can easily crunch TB++ scale data at sub-seconds, without lengthy engineering projects. 

‍