📊 Implementing Analytics Into Your Product
What to consider when you add analytics into your product.
One thing I’ve learned from the past five years is that analytics is an unsellable feature.
Obviously there are exceptions to every rule, and pretty much every industry has a leading analytics product outside of Google Analytics, but unactionable, unfocused analytics are a very hard thing to sell into a company.
So any time I chat with a new startup that wants to build an analytics product, I generally tell them to think long and hard, line up several LOIs, and even see if their customers will pay to have them develop the feature first.
That said, analytics are necessary for pretty much every product. The difference is that you may need analytics for the core workflow or features that you’ve built, so that your users can get a sense for how things are going.
When you realize that you need to incorporate analytics into your product, you’ll need to plan for the data, visualization, and implementation for your new visualizations.
Here’s what you need to know.
Before you start on any new project, it’s important to understand the a) the objectives, and b) how you might implement it. Analytics projects are no different.
Before you get started, you need to understand the key objectives of the project. You should also plan on sketching out the different components of your project. Charts, graphs, and tables should be fully planned out, and you should also have a good idea of the filters that you’re planning on using to slice and dice the data.
These filters will inform the data structure of the underlying tables that feed your analytics as well.
Once you’ve convinced yourself that you need to incorporate some form of analytics into your product, you’re going to need to ensure that your data infrastructure can is well-suited to what you need.
If you’re a young company or starting a new project, you can do things right from the start. Depending on the data transformations, aggregations, and lookups that you’ll need to implement, you can create an aggregate table (or multiple tables) in your database that are optimized for fast lookup.
But if you’re building analytics for an existing process or business, you might need to spend a bit more time upfront understanding the data you already have, how it’s created, stored, and updated.
Frequently, I’ve had to build new tables and data processing jobs to get data into a format that can be easily visualized by an analytics tool before even getting started with the visualization process.
A key consideration of this is to understand the dimensions that you’ll need to slice and dice to display your visualizations. Frequently, your data will be partitioned by date, allowing for easy aggregation across time, but oftentimes you’ll need to partition across other items, particularly if your visualizations will highlight unique counts.
Once you’ve got your database set up and your ETL jobs running, it will be important to monitor their performance and frequency to ensure your customers are getting the most up-to-date numbers. Jobs like this have a tendency of failing or erroring out, so you’ll need to build your own dashboards to monitor your infrastructure.
Embedded vs. custom visualizations
Once you’ve got your underlying data infrastructure in place, you’ll need to figure out how to actually implement the charts, graphs, and tables that you’ll need for your product.
In general, you’ve got two options here: integrating a third-party product or building your own. In general, it’s usually faster, cheaper, and easier to embed a third party tool.
Adding in analytics into your product can be a slipper slope. When you start, it’s hard to not stop, and it’s easy for users to ask more more and more things (most of which they’ll only use once).
As with most things, I’d recommend starting with the end in mind, figuring out the objective of having analytics in your product, and building the bare minimum to get that up and running.
Best of luck 📊