Behavioral Data Platforms (BDPs) for product analytics - a guide for product managers
In the recent years we have witnessed a rapid increase in analytics data and the solutions for monetising it.
There’s a different tool for every conceivable use case – Data Warehouses, Data Lakes, Customer Data Platforms, BI Tools, Product Analytics Platforms, Experimentation Platforms, ETL software, and the list goes on.
The problem is choosing the right tool for your business goals with an ever-expanding and overlapping ecosystem.
The difficulty of choosing product analytics tools
Many of these tools are trying to move into adjacent use cases, blurring the line between the different verticals.
For example, you have Product Analytics Platforms also offering an Experimentation Platform or Customer Data Platforms also offering Product Analytics tools on top.
From a strategic perspective this makes sense, the more of a “multi product” a company becomes the better the retention and monetisation of the customer (think of Atlasian as a textbook example).
However, from a buyer perspective it can become very difficult to make sure you are making the most with your budget when every product seems to have 50+ integrations and partially overlapping functionality with other verticals - aka., the Enterprise Package Pitch.
At the same time, Product Managers (PMs) tend to find themselves in an environment where either there is not enough data to self-serve beyond very basic metrics and charts or an environment where it looks like user activity is captured in several platforms and cannot be properly reconciled; navigating this is not an option for mere mortals.
The reason both of these environments are suboptimal, is because PMs need to rely on analytics team to derive basic insights, either because:
- there is not enough data surfaced, or
- because there is enough data surfaced but it comes with a lot of noise, caveats and requires tribal knowledge to avoid the traps.
These limitations defeat the purpose of the self-serve philosophy.
How can Product teams get the right data to fully answer their questions
The answer is really simple:
1) Use the right tool for the right job (based on your strategic goals);
2) Surface decent levels of data to product teams;
3) Make sure that data is rich in its attributes and structured well for navigation.
Easier said than done, but we will explore how Behavioral Data Platforms (BDP) like Snowplow can help with this.
How can Behavioral Data Platforms (BDPs) deliver better product analytics?
A Behavioral Data Platform is a warehouse-first way of approaching product analytics. Data is collected from websites, apps, IoT, and so on, validated and enriched with 3rd-party data, and then sent to a data warehouse or lake to be modelled and productionised.
A BDP helps Product teams in two major areas.
Firstly, it collects rich behavioral data about your users – taking away the need to deploy more tracking every time you need to answer a slightly different question.
Secondly, it provides a way to structure the data that is being collected in a scalable way.
So how does Snowplow enable rich, scalable data?
- Out-of-the-box and custom event tracking
Snowplow comes with all the basic tools needed to quickly deploy out-of-the-box tracking like Page/Screen Views, Transactions and Link Clicks in your product. It also allows the creation of custom Behavioral Events so that one can monitor more nuanced activity.
- Advanced validation and enrichment
Events enrichment is definitively a unique strength.
Remember that time you asked your Engineering team to add twenty new properties to your tracking events so you could dissect customer behavior in your Product Analytics tool (e.g. by plan, contract length, etc…) ?
So it probably turned out that many of those properties couldn’t be easily attached to events while emitting them, as it required changes to the application API to source the attributes from the database.
This is weeks of extra engineering time…
With an enrichment service baked in, Snowplow allows you to easily source those attributes without this lost time and effort.
You just have to provide a database connection and some SQL logic and the new properties will magically pop up in your Product Analytics tool, in a matter of days, not weeks or months.
Most “general purpose” tools out there do not provide this capability meaning one needs to build an inhouse service for this.
- Rich data structures
The highly structured nature of Snowplow data removes the need to scope boilerplate tracking every time there is a feature release.
This can be easily achieved by baking minimal Snowplow tracking logic into Engineering code templates.
- Data Governance
With defined event schemas, one can prevent inconsistent fields, bugs and errors in behavioral tracking by pre-validating data before it hits your warehouse or lake.
Also, the ability to group your event properties into entities and then attach those to your events as and when required, will deflate that Google Sheet workbook where you document your events and properties from fifteen tabs to about three.
This makes the whole thing more understandable for mere mortals.
- Flexibility
A great thing about Snowplow and BDPs in general is the fact that they are solution agnostic and after the capture phase, data can be piped downstream into a variety of systems.
This gives more modularity to your Analytics tools downstream (e.g. Data Warehouse, CDP, Product Analytics Platform, Experimentation Platform, etc…), and if needed you can easily swap them out later on. This modularity is what allows you to build multi-tool platforms, like a composable CDP.
The also removes duplicated work where you might have to emit similar events in different contexts across multiple Analytics tools.
A Product Analytics use case – putting Snowplow’s features into context
The above might make sense conceptually, but it’s hard to visualise exactly how your product team would benefit from using a BDP over a fully integrated analytics platform.
Here, I’ll try to distil these concepts into an actual use case from a subscription-based company I previously worked at - let’s call them Company X.
How the product worked at Company X
We ran an experimentation programme, whereby the nature of the experiments varied from simple sign-up offers all the way through to more complex experiments involving our Recommendation Engine.
We had thousands of products customers could choose from and every week we would make 50 of them available and change up the selection with another 50 the following week.
The product analytics problem we ran into
When your business model is based on repetition of services/purchases – like our subscription model – the thing you care about most is lifetime value and repeat orders.
The problem is that most experiment platforms, like the one we were using, only give you a snapshot of the results for the duration of the experiment. They don’t allow you to look at the lifetime value of the customers in the experiment.
How we improved our product analytics with Snowplow
Enter Snowplow.
Even though we had basic data on the existing experiment platform, we tracked each experiment using Snowplow.
This allowed us to send experiment events into our data warehouse for deeper analysis on purchase behavior, lifetime value and perform more advanced statistical analysis on the outcome of the experiments.
We could analyse the real time impact on conversion and analyse repeat purchase patterns.
Furthermore, we were able to send that experiment data downstream into our product analytics platform and perform analyses on user behavior.
The ability to enrich events meant that we could also send customer segment data into our product analytics platform by sending the events via the data warehouse for enrichment. It also elevated our analyses, in that we discovered much deeper insights about our customers than the analytics platform alone would have allowed us to do.
Is a BDP the right choice for your Product team?
Will a BDP make sure you have enough data available?
Will you as a PM need help or have data that is hard to comprehend?
While a BDP like Snowplow is not a silver bullet for all of the data issues an organisation might face, it is definitively a major helper when it comes to collecting data in a way that is suitable for self-serve analytics later on.
A BDP does have an upfront strategic and time-investment costs associated with it. You need to ensure that you have the skills in house to deliver the strategy for implementation.
This means identifying the metrics and KPIs you want to measure and then building customer journey maps to identify the key interaction levers to track.
The time investment to implement this might not be possible for some product teams out there who have constraints on engineering resources.
Despite this, a transition to or an implementation of a BDP like Snowplow is an investment in the future of your data, your analytics programme and ultimately the quality of insights you’re able to draw. The long term benefits of carefully orchestrating your own data as well as the ownership associated with doing so far outweigh the upfront costs of setting it up.
About the authors
Bhavik Patel and Nicolae Chelea are the founders of CAUSL, a Product Measurement Consultancy that helps product organisations connect the dots between their product initiatives and company goals. Bhav has previously held "Director and Head of Product Analytics'' roles at companies like Gousto, MOO, PhotoBox, and most recently, Hopin. Nico has deep expertise in inferential and predictive analytics and worked with a wide range of companies, starting from Fortune 500 organisations and ending with early stage startups.