2 min read

Introducing Baxter: deep-dive event analytics on your data warehouse

đź‘‹
Baxter is now a product development and contracting company run by the same two folks behind this idea, Vikram and Gabriel.

We're no longer building an event analytics product, but we're leaving these posts up for posterity.

I recently wrote on my personal blog about how I don’t like any of the funnel or cohort analysis tools available to me.

Gabriel and I (Vikram) are working on an alternative: Baxter.

0:00
/
Baxter generates SQL for a user's funnel and executes it against a data warehouse. Users can explore further using the panel on the right.

Everyone has event data today. Maybe you’re collecting events via Snowplow, Segment, or Rudderstack. Or maybe you’re using data from your application’s database, which will  usually be more trustworthy and critical to your app than events you instrument.

Companies pay a lot of money to send event data to third parties like Heap, Amplitude, Mixpanel, and Posthog (henceforth HAMP) so they can use their purpose-built event analysis tools. Not only is this unnecessary for most event analysis tasks, analysts commonly have to supplement insights from these tools anyway because the tools fall short or the data is suspect.

HAMP has its place, especially in real-time product analytics, experimentation, and monitoring. Their tools are great at answering high-level questions about user activity. But they don’t cater to analysts who are working on extracting valuable insight. All of that work is done in SQL, Excel, notebooks, and BI tools. Not in product analytics suites.

Our aim with Baxter is to help analysts follow lines of inquiry well beyond the point existing tools fall short. And we'll do all this in your organization's data warehouse, giving you the following advantages:

  • You retain your data.
  • You don't chase inevitable discrepancies between your data and a third party's.
  • You can modify and use the queries Baxter generates in your existing workflows, giving you a gentle off-ramp when you do need to drop into SQL.

SQL is up to the task for most product analytics questions. It does the job for most data sizes that teams work with, too. But it’s challenging to write and parameterize correct, high-performing SQL queries for common event analyses.

Analysts shouldn’t need to painstakingly write SQL in order to explore and analyze event data. Their only alternative shouldn’t be to send their data to third parties and suffer tools that don't serve them or integrate with their workflows either.

Interested? We would love to speak with you. Join our waitlist or reach out to us on Twitter.

Vikram Oberoi

Vikram Oberoi