A leap forward in the product analytics data model

“Events are a restrictive, inflexible way of modeling data.”

This is a common concern from data teams about product analytics. We agree. While client-side events can be useful, they’re not enough to represent all use cases of analytics.

Today, we’re excited to unveil our next-generation data model for Product Analytics. We’ve made fundamental upgrades to the event-based model AND support non-event based tables. This new data model sets the stage for a new era of Product Analytics that’s more powerful and flexible than ever before. Let’s dive in!

The first challenge with events is that they get associated with client-side tracking, which is brittle and limited. That’s not a problem with events, just with the methodology of tracking them.

What’s less known is that events don’t need to be tracked at all. They can also be loaded from tables sitting in a data warehouse. As long as each row has a timestamp, and optionally a user ID, it can be analyzed as an event. This is powerful, but until recently, there was no interface to leverage all this power.

Enter Warehouse Connectors. Point Mixpanel at a table (or view!), tell us what the timestamp column is, and it’ll appear as an event with all its columns as properties. No more ETL jobs, pipelines, or scripts to maintain. There are many tables in your warehouse that you can now naturally analyze as events in Mixpanel: Transaction Completed, Support Ticket Filed, Opportunity Created, Subscription Upgraded, NPS Submitted, etc.

Many Enterprise customers are already using this with all major warehouses (Snowflake, BigQuery, Databricks) to enrich their existing Mixpanel implementations with trustworthy data.

"We can now take advantage of augmenting our profile and event data with information from back-end systems that our traditional tracking does not cover. Now our product managers are empowered to confidently understand product success at a truly rapid pace."

Warehouse Connectors is available now and requires no code to set up. Just point us at your warehouse and go!

A second challenge with the event-based model is ensuring that events have the right properties.

You’re left with two painful options: Make your engineers track the same properties on every event or write crazy joins/window functions in SQL.

Enter Borrowed Properties. Now in the Mixpanel UI, any event can “borrow” a property from any other event and… poof! It’ll be like you tracked it all along. It’s done at query time, so you can do it on any event, any property, at any time, and it’ll work fully retroactively. It took a lot of incredible engineering to make this simple, fast, and flexible. (Yes, we’re doing on-the-fly window functions under the hood!)

The third problem with events is that they’re immutable. This is fine for tracked events, which typically don’t change after the fact. It’s not fine for transactional events like purchases, which change all the time due to refunds, cancelations, or credit card failures. When events are immutable, you can’t model these types of modifications and they fall out of sync with your source of truth.

Enter Mirror. It’s a new mode of Warehouse Connectors that uses Change Data Capture (CDC) to keep in sync with every insert, update, delete, and schema change from your warehouse. It’s also powerful for events based on data that gets periodically remodeled (think: dbt models). Just turn it on and never worry about data falling out of sync again.

Mirror is available now, as well. Explore this interactive demo or go here to learn about getting started.

The final problem with events is that they don’t actually represent everything. You need dimensional or state-based tables to describe entities like users or accounts.

This is why Mixpanel’s data model is fundamentally a star-schema: Events are facts and Profiles are dimensions.

Profiles are used to model the state of entities like users or accounts, which is often unnatural as events. For example: Is this user free or paid? What subscription tier does this account belong to? Are they on the free trial? What is their MRR? Profiles might change state over time. Users go from free to paid, account MRR goes from $0 to $100 to $1,000. Data teams need a way to represent these changes without shoving this state onto every event, which is expensive and brittle.

Enter Profile History. Now you can point us at a table that has the history of a profile and we will let you analyze that profile over time. For all you data engineers out there: Yes, this means we can ingest Slowly Changing Dimension tables, and yes this means we’re doing an “over-time” or “asof” join between these tables and your events. This enables accurate analysis on recurring revenue and subscription states without unnaturally forcing state tables into the event-based model.

Finally, unlike other analytics tools, we don’t shove profiles into the events; we store them as separate tables. This simplifies integration: We do the joins at query time, so you don’t have to do them at ingestion time.

These data model upgrades are just the first, foundational step we’re taking toward analytics that gives you a complete, trusted picture of your product and business. We’ll share more over the coming months on major upgrades to our metrics, templates, and visualizations to truly make this vision a reality. If you’re excited to learn more and share feedback, please reach out!