Reflect: Embedded meta analytics, built for developers

Cloud-based analytics for on premise data, an API-first approach for embedded product analytics, and impact-based pricing. Meet Reflect.
Written by George Anadiotis, Contributor

Video: How big data powers digital transformation

Analytics and data visualization are commoditized. There is a wide selection of solutions, ranging from traditional BI tools to self-service and cloud-based solutions, and from full stack suites to bare bones libraries.

This is either a nightmare to navigate or a consumer's delight, depending on how you look at it. From the vendor point of view, this landscape is so crowded it's hard to differentiate. One way to do this is to address a niche.

Reflect focuses on embedded analytics for software products. Today new features including a visual tool for product owners and data-driven pricing are out, and ZDNet discussed Reflect's approach with Jeff Hardison, VP of marketing and sales.

The problem with product analytics

Hardison says Reflect's first objective as a company was to make building visualizations into software/websites easier than what was on the market by catering to the needs of software developers.

What software developers? The ones working on products for which they need to have analytics. Why software developers? In an attempt to address the build versus buy dilemma.

Arguably, if you are a developer working on a software product, building the analytics for this product is not really your job. So it will take time and effort to build what will probably be suboptimal analytics.

Hardison says that's why most developers eventually turn to an embedded analytics solution. He adds however this does not solve the issue, as most BI tools were designed for internal use cases involving analysts and executives.

In the beginning, there was the API

Reflect set out to address this. The first product Reflect launched was a REST API and a JavaScript library.

The idea is that developers connect their data sources to Reflect, then use the API to define data models and visualizations, and then embed the visualizations wherever they needed to be embedded.

This sounds strange in a world where visualization is key, but may make sense in the context it was built for. If you need to embed your visualizations, having a clear-cut API and a purpose-built Javascript library for this is something developers would appreciate.


Embedding a visualization in Tableau. Image: Tableau

Of course, what constitutes a good API is somewhat subjective. But most developers would agree that using a purpose-built JavaScript library is more convenient than messing with HTML tags.

Hardison stretches how this allows to natively embed visualizations, as opposed to popping up unattractive iframes. A moot point? Not if you have to write the code for this, or use the end product.

Yes, developers could do all of that on their own, but the point is they should not have to. But others vendors could get their APIs right too, should they decide to prioritize this. Where would that leave Reflect then?

Hardison's reply emphasizes culture and business model. He says that Reflect's people have experience building data visualization for software products, while other BI vendors don't really understand or care much about this use case.


Embedding a visualization in Reflect. Image: Reflect

Reflect Studio and Meta Analytics

That's all great for developers, but what about the rest of the world? Today Reflect is launching its Reflect Studio Version 2, aimed at empowering product managers and software developers to design data-driven products.

Reflect Studio is a way to make what was previously possible only via programmatic work also available for people without developer skills, and is utilizing Reflect API under the hood.

Users can create data visualization applications using drag-and-drop, enabling product managers to connect a data source, design a set of visualizations around the data, iterate with stakeholders, launch, and analyze performance.

The announcement emphasizes that the SaaS pricing for Studio is based on return-on-investment as opposed to upfront licenses based on seats and servers. Hardison says they want to surface visualizations to very large audiences, potentially 100s of thousands, in public/external-facing products.


Reflect Studio with Stats. Stats is a way to measure the impact visualizations created with Reflect are having, and pricing is based on this. Image: Reflect

"We align our pricing with the success of our customers -- the more people use them the more they pay," says Hardison. "Talk to anyone who's built an analytics product before and they'll tell you that the initial launch is just the beginning.

Getting feedback from users, measuring, and iterating is where most product teams struggle. Stats, affectionately dubbed 'meta analytics,' allows Reflect users to measure how well their analytics are performing with end-users.

Our understanding is we're the first embedded-analytics vendor to offer 'analytics on analytics.' Right now, it's part of our enterprise plan. But we can imagine how interesting this could get."

Secret Agent

This is a very interesting feature. We imagine it should be quite hard to accurately capture how well analytics are performing with end-users. But if successful, this could pave the way for a new approach in pricing models.

But there something else unusual about Reflect's approach, something that Hardison admits Reflect does not make entirely clear: the Reflect Agent, and how this allows data to remain on premise.

When connecting data sources to Reflect, they are inspected to extract metadata to help define data models for those sources, but the data itself does stays where it is.

So when a page with an embedded visualization is loaded, a call is sent to Reflect through the Agent. The best way to execute a query is determined, and a request is sent to the database. This includes parameters for authentication and filtering, and returns formatted visualizations.

The Agent can be hosted by Reflect, or it can run on premise. When a user selects a visualization in a data product, the Agent makes a call to the dashboard's database, which then sends the information via the Agent to the Reflect API.


The Agent is Reflect's architecture for serving data that stays on premise. Image: Reflect

Reflect says this improves performance, and the use of agents is common in other areas of the software engineering. More security-conscious customers can host the Agent behind their firewall on their infrastructure, for example on AWS.

There is some caching involved, but we should note a couple of things here. While avoiding the hassle of offloading data to and keeping in sync with Reflect, there may be a penalty associated with moving data on demand.

Plus, for applications that store data in the cloud, the Agent approach may not necessarily be an advantage. It depends on the type of data Reflect will be managing.

Reflect does not support a very wide array of data sources at this time: Amazon Redshift, PostgreSQL, MySQL, Microsoft SQL Server, and CSV files. And there are certain limitations in its strictly relational data model.

Despite this however, its opinionated technical approach and innovative pricing make it interesting. If these prove successful, they may spill over beyond the niche of product-oriented analytics.

Editorial standards