Introducing Borrowed Properties: Combine data between events on the fly
We’re excited to introduce Borrowed Properties, where you can “borrow” a property from one event to another on the fly, and you can analyze as though that property has been tracked on that event all along.
Previously, there was no way you could combine data between events. Let’s say you need to break down an event by a property that doesn’t exist on that event itself, but it does exist in prior events. For example, you want to break down “Completed Purchase” by category, but “Product Category” is a property on the event “Add to Cart.” It’s not that the data isn’t tracked, it’s simply locked away in another event.
Borrowed Properties unlocks more analysis with the data you already have, without any lift from your engineering team. No more asking your engineer to re-track the event with the desired property and waiting for data to trickle in or needing them to write crazy SQL queries to make a workaround. You can simply borrow the property directly in our UI and poof—it just works, like it was tracked all along.
Borrowed Properties aren’t a shortcut for implementations (you should still create thoughtful tracking plans). They are meant to open up a new world of analysis by merging data that was previously difficult or impossible to plan ahead of time for your engineers. Let’s take a look at the examples.
Merge data from disparate systems, like client-side and warehouse data
Data from different sources don’t track the same context about the user. Server-side events don’t have client-side properties like location, device, URL, or UTM tags (“What button did a user press right before hitting a server error?”). Warehouse events lack properties about product usage (“What feature did the customer use right before upgrading to a paid account?”).
Moreover, data from different sources shouldn’t track the same data. Tracking every property on every event would bloat your implementation and make the data much harder to read.
So what if you want to understand which types of concerts have the most confirmed purchases?
- The “Order Placed” event is triggered when a user clicks the confirm purchase button.
- Since “Order Placed” is tracked client side, it can contain a property for the type of concert ticket (country, hip hop, electronic) purchased.
- The “Transaction Processed” event triggers when the server authenticates that the payment is received. Since it’s tracked server side, it can’t contain client-side details like category.
Borrowed Properties allows you to pull the Concert Type property onto “Transaction Processed.” You can merge contexts across data sources for complete analysis, from button clicks to confirmed revenue.
Combine data between different teams
For multi-product or larger organizations, people may need to understand how another team’s work affects their own. That means they need to use data that has been tracked by other teams, which often isn’t optimized for their own use case.
For instance, your team owns onboarding and another team just shipped Dark Mode.
- You want to understand whether users who are on Dark Mode convert better through our onboarding funnel.
- The other team tracked “Toggled Dark Mode” as an event with the property “Enabled.”
- Since Dark Mode is a new feature, your “Completed Onboarding” event does not have the “Enabled” property to indicate if the user has Dark Mode on or off.
Use Borrowed Properties to leverage the tracking from that other team and analyze it in the context of your own KPIs. Do this all on the fly, without bugging engineers on anyone’s team.
Getting started
Borrowed Properties is available today for customers on our Growth and Enterprise plans (docs here). If you’re interested in leveling up your analysis without fighting for engineering bandwidth, let’s talk.