All Warehouse-Native Product Analytics Platforms Are Not Created Equal

Last month, Amplitude announced their Snowflake Native app during Snowflake Summit 2023. As the CEO/Founder of the first warehouse-native Product Analytics platform, Kubit, I’d like to share some of my thoughts on this, and address some of the burning questions out there.

Warehouse-native is the future

First of all, we’re very excited to see that our vision of warehouse-native Product Analytics with No-ETL is being followed by our #1 competitor and the leader in this space.

When we launched Kubit five years ago, the market was full of solutions like Amplitude – which required customers to use SDK or ETL to copy their precious data into external data silos. All of them were trying to lock in their customers with black boxes the customers can’t control, and a ridiculous pricing model based on event volume. Kubit took the completely opposite approach: giving control back to our customers with our warehouse-native solution which breaks down those data silos.

Instead of taking customers’ data away, we directly utilize their customized data model in the cloud data warehouse, and never require them to do any ETL to force fit into what we need. Our customers not only can achieve One Single Source of Truth, they also maintain full control of their data with full transparency.

The initial journey was long and hard, but we’re now thriving. We love working with our many enterprise customers like TelevisaUnivision, Firework, Wish, and Quizlet, who truly believe in and benefit from our vision. Most of all, we’re thrilled that our prediction is coming true: the industry is now trending towards bringing Product Analytics to the data.

Let’s dig into Amplitude’s claims

Amplitude’s announcement was short and vague, with just one diagram (below) and a pre-recorded marketing video.

Warehouse-native, or just Snowflake-native?

Do you notice that they use the term “Warehouse-Native,” but actually the solution is only Snowflake-specific? Let’s take a closer look.

From what we can tell, Amplitude’s Snowflake Native app takes advantage of Snowflake’s latest “Snowpark Container Services” which allows them to deploy Amplitude into customers’ Data Cloud. This is a great move towards bringing SaaS applications closer into the data, instead of taking data away to external vendors. We are also actively collaborating with Snowflake on this. But – does this really make Amplitude warehouse-native?

Shouldn’t a warehouse-native solution work on all cloud data warehouses instead of just one? It’s not as simple as it sounds to go from one to the other. Kubit proudly supports all warehouses on the modern data stack: Snowflake, Databricks, BigQuery, Redshift, Azure SQL, Presto, ClickHouse and more – all with live product customers at scale. We provide self-service product insights from billions of events every day for each of our enterprise customers.

Amplitude still not using customers’ data models 

The core of a Warehouse-Native solution is to utilize customers’ existing data models, regardless of their schema design. That’s what “No-ETL” really means – you don’t need to transform or duplicate your data to a third-party, ever. Now, let’s look at what kind of data model Amplitude is using in their offering. I wondered what the word “Curated Data” in their diagram above means. Well, check out their own product demo video (at 00:43): do you see the column “AMPLITUDE_ID” in the screenshot below? It appears that they still need to transform customers’ data somehow, or mandate that customers use their SDK.

Can Amplitude be truly warehouse-native?

At the time of this blog, Snowflake’s Snowpark Container Services is still in private preview. Amplitude has published no technical details beside the announcement itself. Someone may be lucky to be on their waitlist to get a peek.

Based on my understanding of their business model and system architecture, I see four major challenges to their shift towards warehouse-native.

First challenge: Amplitude’s business model

If you’re familiar with Amplitude’s history, you know that they started with a focus only on user behavior analytics. Initially they partnered with many other vendors in the ecosystem to grow together (like Optimizely for experimentation, CDPs including Segment and mParticle for event collection, and Braze for customer engagement). Over time, Amplitude expanded its product offering into all of these fields (Audiences, Experiments, and CDP) – because they control the SDK and want to use it to lock in their customers.

We’ll gloss over the fact that they screwed over their partners, and the ethical implications of doing business that way. How can Amplitude still offer these services when they have to give customers the control of collecting data directly without their SDK in place?

Second challenge: architecture

Amplitude’s backend started with a built-in-house analytical database and later moved to Snowflake. In their architecture, they must have made all kinds of assumptions about the data model (schema, a.k.a. table structure) and that’s why they mandate either using their SDK, or going through a complicated ETL process to copy customers’ data into their data silos. Along the way, they also have to build lots of business logic to collect stats and generate insights through this batch/streaming process. To replace all of these with direct utilization of any other completely customized data model is like replacing a building’s foundation while keeping the business going. Of course, it is still possible – but I wonder, how long will the wait be, and how much damage will there be?

Third challenge: culture

Because of the data silo approach, getting reconcilable insights from One Single Source of Truth was never Amplitude’s goal. As a black box, the more their customers are dependent on their SDK or ETL, the more locked in the customers will become. Giving back the data control or transparency goes completely against their culture.

As a warehouse-native solution, working directly with customers’ data models from their data warehouse, transparency and trust are our top priorities. At Kubit, not only do we explain to our customers all the analytics logic to make them understand how their data model is translated into insights – we also give them the raw SQL behind every chart so they can verify that everything was done correctly, and also build many more features on top of Kubit.

Fourth challenge: pricing

Lastly, most of you likely remember that, for the longest time, Amplitude’s pricing model was based on event volume. They billed a customer based on the number of events collected – because to use Amplitude, you must send your data over to them. This is also where the surprise overage bills come in, which have forced many customers to sample or limit their data, in turn making the data quality even worse and a nightmare to manage.

With warehouse-native, customers already have all their data in the cloud data warehouse to be used directly. Charging by events in 2023 became a practice as laughable as wireless carriers billing cell phone users by minutes. Earlier this year, Amplitude announced their MTU (Monthly Tracked User) pricing, which Kubit has been using since day one.

I applaud them for what is definitely a great decision to embrace reality. But, how will this pricing model change work for legacy customers, who may have paid a lot of overages or wasted so much time on sampling? I hope that Amplitude will be able to make it right for everyone on this journey.

‍
We’ll all benefit from the warehouse-native motion‍

I’m actually very happy to see that the Product Analytics industry is moving towards more control and transparency for customers through this warehouse-native motion. It’s always wonderful to see Kubit’s vision validated by our peers and competitors. We will take this opportunity to learn from each other and improve. At the end of the day, all of our customers will benefit from having the freedom to choose. I look forward to more developments and opportunities generated with our efforts.