The Data Stack Show - Data Council Week (Ep 3): Product Analytics the Right Way With James Greenhill of PostHog

Episode Date: April 27, 2022

Highlights from this week’s conversation include:How James got started in data (2:42)What makes PostHog different (10:43)Why we need product analytics (13:40)Capturing and collecting data (15:17)Dealing with drift on a platform like PostHog (19:45)Starting from the metrics versus events (22:50)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Welcome to the Data Stack Show. Each week we explore the world of data by talking to the people shaping its future. You'll learn about new data technology and trends and how data teams and processes are run at top companies. The Data Stack Show is brought to you by Rudderstack, the CDP for developers. You can learn more at rudderstack.com. Welcome back to the Data Stack Show recording on-site at Data Council Austin. We are having a blast with the microphone set up in this side room and we're grabbing all the cool people that we can find to come in and record episodes. And

today we're talking with James Greenhill from PostHog and he is the platform team leader there. And I'm super excited to talk with James. I think one of the things that I am really interested in is what are the challenges that we don't think about when you're building a product analytics tool, right? I mean, you're a data person building a data tool for people working with data. And I think that there are probably a lot of things that we don't necessarily think about, you know, because product analytics on some level seems straightforward. You record some sort of instrumentation and then you send the data through and then you look at the data and figure out if this feature is working or not, right?

But there's probably a lot more under the hood and some decisions that have to be made that are probably pretty difficult. So that is what I want to ask James about. How about you, Kostas? Two things. One, I definitely want to have a conversation with him about like the concept of platform. So I'm like an organization.

It's like one of these things, like the platform teams and like they arise as a way of like organizing engineering that's like very interesting and I'd love like to hear about how it is implemented in PostHog. And then of course, learn more about the technology itself. And hopefully we will also have some time to talk a little bit more about product analytics in general and what it means and where the problems are and how you can, you know, do them properly because it's really, you know, like it's one of these things that like everyone wants to do and it gets messy very, very fast.

So let's see what we can learn. Let's do it. James, welcome to the Data Stack Show. We're so excited to chat with you. Glad to be here. And we are actually on site again at Data Council Austin in person. So, so fun to record. And you are head of platform at PostHog. So we want to hear about that, but tell us how you got to that point. Where did you start your career? How did you end up working in data?

Oh, yeah. So I've got a really interesting story arc for my career. Basically, I started out as a data analyst, a data scientist, really, at Grooveshark forever ago. No way. Yeah. So I've got a really interesting story arc for my career. Basically, I started out as a data analyst, a data scientist really at Grooveshark forever ago. No way. Man, I definitely remember Grooveshark. Yeah. So basically joined there. My entire initiative there was to make the data more or make the company more data driven. So I reported directly to the CTO, Josh Greenberg, and had a bunch of initiatives. I had this newsletter called the Shark Chum that I sent out every week. But very quickly, it became apparent

that we had basically no data infrastructure at all. So I was scratching an itch, started getting data engineering just to serve myself, went down that track, ended up at Discuss for four years, building out the data infrastructure there. I was actually originally hired there as a data scientist. Okay.

Did the exact same thing. What's funny about that was we started out with the VP of product. The entire suite of reporting was a Python script that hit a Postgres instance that spat out static HTML on a cron job. So basically my first thing was like, nope, that's got to go. Set up Hadoop. Did all sorts of stuff for four years, ended up converting that company. Like that was what we ended up monetizing at the end of the

day. We tried a couple of things with like ad platforms, but basically the data was the best thing that we had. I remember I actually was a Disqus user. Yeah. And I kind of remember that, like, yeah, that was, that was really interesting as a user. Yeah. Well, I mean, we were basically the largest, we were all over the internet. And they basically still are. But at the time, it was like peak to us. And we had the largest Google Analytics account that Google Analytics had. Really?

Yeah, we had 1 billion uniques with 10 billion page views a month, which was pretty great. I used to joke with people like, it was great for recruiting because I was like, hey, you could join this company and have by far the most un unique expert engineer than any other company out there for sure. But yeah, like we basically started out originally as like how to understanding how people use the product. And then it was like, OK, well, maybe we could turn this into an ad platform using this data. And then finally, I was just like, well, actually, we have a really good persona from people like we're scattered throughout the Internet. We know what people kind of want. And we can bundle that up into nice personas that we can, we can kind of help people target better with.

And so that was four years of my life. And then I ended up being like, okay, well, I kind of want to play with product engineering. Went over to Silicon Valley. Well, actually I went to a company that was acquired by Silicon Valley bank standard treasury, a closure shop of all things. Oh, wow. Fun.

Yeah. Did product engineering did the worked on the integration for, I don't know if you know, Stripe Atlas. Yeah. Did product engineering, worked on the integration for, I don't know if you know, Stripe Atlas. Yeah. So it's basically this product that allows you to spin up a company with like a dollar C corp and all this stuff. Oh yeah, yeah, yeah. Yeah. It's great. It's a great product, but we were one of their partners for the banking side. And so I helped build out the backend for that. Really fun, but working in a bank is really tough. Very, very slow moving. Also kind of wanted to get back into data. So ended up back over at, or actually I started, really interesting.

I ended up at Uber working on the self-driving cars. Really? Yeah, yeah, the autonomous cars. So I was at Uber ATG and basically handling the real-time telemetry coming from the trucks. So the idea there, the goal was we had these cars driving around, but they really weren't getting utilized very well. They were breaking down for various reasons. And we wanted to understand why and how we could improve the utilization of the fleet. And we did that by real-time analytics pretty much. And so I worked on building that out, which was a ton of fun, really interesting. But then we bought Jump and I'm a cyclist at heart. Like I love cycling.

One of the reasons why I live in San Francisco, it's just like perfect weather all the time for cycling. Yeah. But basically I was like, yes, I definitely want to help here. I believe in the mission, really fun. And the product's fantastic. And I would use it every day. So I went over to Jump, basically led the integration of the Jump infrastructure into

Uber's infrastructure, throwing overall pipes for getting like usage data into us and built out a team doing that as well as doing uh reporting for cities so it was kind of a quid pro quo with jump like the entire license that we got to operate in cities was in exchange for data so we would go to a city and be like hey like we would love to launch jump in your city but in exchange like you know we know that this is like you want something back from us but so what we'll do is we'll tell people like where people are riding and you can use that to develop your infrastructure super like where yeah it was super like that's a neat like public private yeah partnership yeah it was really good cities loved us for that because it was very difficult to get otherwise Strava actually did this as well later in their career but yeah it was it was really

cool to see cities like say yeah you know we would love to understand where we should be putting bike lanes based on where people are actually biking. Yes. That's really helpful. It's like the cow path theory, right? Yeah. Let people like. Yeah, yeah, exactly. Yeah, it's exactly that.

So it was very organic. It was very data driven, which is like surprising for cities, but I love it. The other thing was enabling one of the generally as part of getting the license, they would want to underserved areas as well like enabling people to move around the city you know sure and so that was a way for us to show prove that we were doing this yep which was really really great and then after that we we ended up about two and a half years ago getting like through a deal moving everything over to lime and lime's a scooter company i'm not really as big in the scooters yeah so i started looking around for companies and I found PostHog. So PostHog,

the story there is really interesting. I basically saw them. I basically saw them on GitHub and I started them. Like, basically, it showed up on Hacker News.

I'm a big fan of Hacker News. Sure, I remember this. Yeah, yeah, yeah. The launch. Yeah, totally. So basically, I saw them on Hacker News. I started them on GitHub.

Yep. And James Hawkins, the co-founder, likes to procrastinate. And one of the things he does when he procrastinates is he looks at the GitHub stars to see who's liking the repo. That's such a wonderful founder procrastination. Oh, yeah. He does the same thing. The other thing that he does when he procrastinates is checks LinkedIn and just networks. That's what he does to not do whatever know, not do whatever he's supposed to be doing at the moment, which is great.

Really great for growth, really great for networking. But anyways, he was like, hey, you know, you work at Uber. Do you mind like looking at a product and maybe doing an investor reference call or something? And I was like, yeah, I'd love to. Like I'm a huge fan of the product already. This is absolutely something I would use at Uber if I was like trying to instrument product analytics.

It's something that I've been doing forever. Like if you were to ask me like the one thing that I've done like 10 times over in my career is like you walk into a company, they're like, we don't have any data. And what do you want to do with the data? Well, we'd love to make a funnel. You know, we want to understand like where people like that's what everyone wants to understand with their app is like, how are people entering my app? How are they converting to being a paid user?

Were they having good and bad experiences? And how can I like allocate my resources to improve the experience? Yep. So we had done that. We had actually done like a code yellow at Uber with jump because the experience was kind of shoddy. And so we had some VIP users who were using the product. They'd be like, why isn't this thing working? So we did this like, you know, all hands on deck, like build out a funnel thing to understand like where people were having issues. Yep. Anyways, I was a huge fan of the product. I did a couple of investor reference checks, and then I was like, you should hire me. And the rest is basically history. So I now work there. I lead the platform team basically with the infrastructure side and the ingestion side.

So it's making sure that we collect events, that no events are lost, that they show up into the data warehouse on time, and that the entire stack is easily deployable either on cloud for us or for our customers who want to host it on-prem. And that's the TLDR. Yes. Okay. So I'm going to ask one question and Costas, I know you have a ton. So did you have to come in and build the analytics funnel for an analytics company when you came into PostHog? Surprisingly, no. No, it was the first time I did not have to do that. It was built originally, we had to rebuild it, but there was already a funnel. It was just built on Postgres. It was just a little slow. It was good for like small, small installs, but we didn't have to do it eventually. Yeah, totally. No, that's,

it's always funny. Like, and we talk about that and what we do as well, you know, it's like, sometimes you have like a cobbler shoes type situation, especially in the early stages, you know, where it's like, that's awesome. All right, Costas, I've been monopolizing. So please. Oh, it's fine. It's fine. You're doing an amazing job as always.

So let's talk a little bit about like cost building and product experience. Yeah. Like what is it and like how much is different compared to other like solutions out there? Well, the main thing is we're open source. You know, there's not really any product analytics out of the box that handles open source product analytics, like especially at scale like we do. You know, we've heavily tied or we've bet the farm, I like to say, on ClickHouse. And it's been really great for us. It's what Yandex uses for Metrica, which is like their Google Analytics.

And so it's very used to scale and it works great for us. It's relatively easy to host our stack locally. And other than that, like we have a bunch of the, I think something that is a little different from most of our competition is that we tack on a lot of extras onto it because we believe that like, it's kind of like the entire thing that we see with like the modern data stack currently, which is like, you know, you, everything lives in your warehouse and you're able to like leverage that data in the warehouse to power other tools other data tools so we have a feature flagging suite in there and experiments based on that so those are all powered by the data that you put into post hoc so if you emit a bunch of data you can say like only use this feature flag only enable

this feature flag for this product if the user is like a high frequency user or uses this specific thing or it's part of this group and you can go super deep with that like you can you can base it on properties that are on the user properties that are in events so like we've made it so that like there are all of these tangentially related products that are powered by the data that you send postdoc but are kind of separate products by themselves yeah so that's that's another like between those two i'd say that those are our two primarily primary differentiators between other products. Uh-huh. That's amazing.

And like, how, I mean, if I want to use BOSFOP, it's like, do I use, where's the data stored is the data like stored in something like it's a, let's say storage layer that's appropriate for PFA, but go by BOSFOP or is it something where I can use like, oh, that's money, all data work. How's that? Ah, why not both? Basically, basically Yeah. Or is it something where I can use like that's money all data warehouse? Ah, por que no los dos? Basically,

basically, yes, you can do both. By default, it goes in a ClickHouse with a schema that's kind of like blessed by us.

And that scheme is always changing slightly as we try to make it a little bit more performant and leverage ClickHouse features a little bit more as they come out.

But we also have a feature that allows you to kind of tee off all of your events from the flow into a data warehouse of your choice. So as the events come in, you can say like, you know, it doesn't impact the flow into ClickHouse at all. So our product keeps going. But like, let's say you want to use that to augment the data that you have in your own warehouse, whether it be on GCP, BigQuery, or Snowflake, or Redshift, or Postgres, or wherever you want it. Like we, you can basically, we, the, the, the way that we do that is via plugins and you can build these plugins yourself.

So if you're someone who uses like DB2 for whatever reason, and you want your data to be in DB2, you can do it. You just need to have that plugin and put it into a repo and point your postdoc install to it. And why, why do we even have like product analytics in general? Like what's so special about product analytics in terms of the analytics that we have? That's one question. Yeah, yeah. Why do we need specialized stores in the air for that? That's a really good question.

So the first one, how is product analytics different from analytics and specifically for ProSog? It's a little different because with analytics, like Google analytics, you're really looking at like attribution. You're looking at how are people showing up at your app? You know, it's very good for marketing. For product analytics, things like mixed panel or an amplitude or heap is really interested in like how are people using your app? Like, and are they having a good experience? And are they converting, you know, and retention? Like are people sticking around?

So they're subtly different, but they really are different use cases and different personas are going to use both of those products. Now for the storage layer, we did originally just use Postgres, and it worked really well. We moved on to like a data warehouse like you were saying, which we think is going to be a data warehouse in the long term. So ClickHouse is like an OLAP database that, you know that you might compare it with like a Druid or a Pino, but I think the direction that it's going in

is probably going to end up more like a Snowflake in the long, long term. So you can host it, but the difference is you can host it yourself. And it's actually kind of like Starburst. It's very, very similar. So it's just our constraint. We would have chosen, well, we would have entertained those other options a little more but one of

the constraints that we had when with choosing the warehouse was making it easy to deploy on prim for a smaller company so you know putting it in a helm chart and shipping it is much easier with click house than it is with like the entire potentially hdfs stack which you know a lot of companies a lot of enterprises might have been more comfortable with, but we were really optimizing for just like turnkey efficiency with the product. Makes sense. And let's talk a little bit about the capturing and collection. I've seen many times and I'm sure like Eric also has seen that the first time that you try to instrument your work, it's always like a huge. I've never experienced that.

It's like, no, like Ted doing that 10 times, like every time. And I realize what I find amazing that like people are like, okay, let's just instrument everything. Like let's pull like every possible, like if you have a, and you don't double it with a shoe, just noise. You don't have that with a shoe. Yep. Just noise. Yep. You don't know what to do. Yep. It's glut, it's pure gluttony.

Well, it's hoarding. I call it tail hoarding. Yeah. Yeah. And to be honest, like I have reached like the opposite direction right now, where I'm like, let's start with the exercise now. Let's see if he's coming in, do something with beat and then let's add another. Yeah. Yeah. Boring.

But the reason I'm talking about that is because instrumentally, like a product is one of these things that like you need like a lot of technology to do it. We talked about that, like why we need like specialized sort of like specialized UIs like to do like the creating of all these things, but you end up in a situation where like all these might be completely wasted if you don't model and do the instrumentation right. Yeah. Like have like a process.

Yeah. Yeah. So help us like understand how we should be approaching these of like product people out there and, and how we should build this instrumentation process and maintain it. Yeah. I think, I think the real thing is you're absolutely right with people basically just kind of throwing everything against the wall and seeing what sticks in terms of instrumenting their app.

I think educating engineers on how they should instrument the app is step one. Having a good taxonomy on what the metrics should be, what the events emitted should be, is huge. That's something that we're working on currently is trying to like surface what events are being emitted so that engineers know like, oh, like, you know, you don't end up with the classic case of like checked out, sale complete, you know, sale, like all the events,

all these events being emitted that mean the same thing, but are being emitted in different locations with different terms. And so they're not getting captured right. So like the taxonomy thing is really, really a difficult thing. And I think over time, you're going to find that engineers are going to be involved in this more and more. And as engineers are also becoming more product minded, you're going to see them scratching their own itch and you'll probably see the hygiene of this go improve anyways. So, but there is a problem.

I think, you know, there's there, and there are kind of two solutions to it. One is education. And is education and and you know i've seen like linting done on the front end where like as you change a metric like something that's being emitted it's like hey like this is a new type of event you you may be emitting are you sure you want to add this like here are other things that are like maybe similar um so that that's one way of doing it the other way of doing it is uh consulting on the back end which is i feel like what most people do now. We're just like, okay, we've all made mistakes. And so I'm just going to combine these all into one metric or one event category.

I think catching it earlier is better. We're going to push people towards that because you get more value out of it. And I think you get a lot more engagement from the engineers that are implementing this. Because if you can get engineers bought in and make it easy for them to instrument the app, you're going to have better metrics in general.

Like, it's just a good thing. But yeah, it's just a problem, a problem that need requires education. I have a question on that, actually, especially related to the way that you think about PostHog as a platform. And I'm thinking about this from the standpoint of, you know, having used, like, you know,

whatever, tons of different product analytics tools, right? So even if you've done taxonomy before and you start with like a pretty good taxonomy things change things grow like the app itself changes right you try new things right and so there's there's inevitably some sort of data drip like even if you're if you even if you you know work at it pretty hard right it's just the nature of the business. So what's interesting is like the like basic product analytics tools and like the visualization components are built for sort of like a really clean taxonomy, which makes sense, right? And so there's kind of this whole other feature set actually that, you know, some products do well and some do really poorly, like product analytics products around like, okay, if that happens, like if you have drift and you need to fix it, because like, guess

what? Now your visualizations have problems, right? Yeah. How do you think about that feature set? Because it's sort of this like hidden, but like really critical thing that's like pretty hard. I don't know. It's hard to think about like how you consider that feature set in a platform like PostDog.

Yeah. So one of the things that we've kind of prototyped, it may be released pretty hard. I don't know. It's hard to think about like how you consider that feature set in a platform like PostDog. Yeah. So one of the things that we've kind of prototyped, it may be released pretty soon. I'm not sure. It's kind of in like super alpha phase, is the idea of trying to consolidate these and categorize them together. So it surfaces all the different types of events that you've emitted with their context. And it tries its best to consult, like capture them together. So it's like, well, these all look like, you know, sale events. So these are all page view or impression events. And then it kind of helps an engineer analyst, like, or product person go in there and be like, oh yeah, these are,

and then immediately that becomes one consolidated thing. Got it. But yeah, it's a tough problem. And if you're like in a warehouse, I think the best thing to do would be to have some sort of like, I don't even know if there is something out there like that, but it'd be kind of like a data catalog or data management system product that surfaces the dimensions for every column. So it's like, these are the events and some sort of distribution of those events. And you could probably, I imagine in every company,

you see some long tail of garbled titles. But yeah. Yeah, I mean, a lot of companies, I think just fix that in SQL, right? Yeah. Yeah. Yeah. No, basically. Yeah. That would traditionally, that's how I would do it. Like if you were to like pick me up and put me back in time, like, well, there's another airflow job or whatever. Yeah. Yeah. That's super interesting. And do you view those decisions as sort of unchangeable, right? Like you decide, because that's another big question, right? Like you decide that there's,

like these particular events essentially need to be consolidated to represent like one thing. Should you be able to reverse that? Yeah, that's a really good question. Typically, like going back and rewriting data, I, it sounds nice. I very rarely have seen this actually work. Yeah. People do it. Like going back and just rewriting, it sounds nice. I very rarely have seen this actually work.

Yeah. People do it. Like going back and just rewriting data to fix these types of things. Usually you end up with some sort of lookup where it's like, you know, between these dates and this event name, like it equals this. Yeah. Like refine a term. So in that way, like you're not destroying any data. You're just kind of like adapting it.

Yep. I've seen that work, but it does get, you know burdensome it can be pretty pretty yeah it's like a it's like one of those things where like if your hands are on all the controls like you can kind of massage it but like from a product perspective it's you know when you're like on some level you have to make some decisions for the end user right or you have to like give them options which is like hard so yeah it's super interesting. Yeah. I really like, we don't do this, but I really like the idea of, um, having the linter and being like, like before you even get it in the production, it's like, whoa, like, you know, we think that this, this is either like, are you sure

you want to emit this new type of event? Like here are the other events that this might fall into. Like that would be perfect. It's the angel on your shoulder. Yeah, exactly. Exactly. We're in the blocker. It's like, no, no, no, this is, this is don't do this.

Last question from me. So discussing about like instrumentation and like all these amazing stuff we've gotten in doubt with, did you think that we should start from the metric and then doubt like what kind of functions we should record? Ooh, or to the authors, it starts from the events. Ooh, that's a great question. That is a really good question. That's a fundamental question. Ideally, you know, we know exactly what we want to measure all the time.

Yeah, exactly. Yeah, yeah. And we know everything. We know every hypothesis that we want to test from day one. I wish, but yeah, typically I think you're going to end up with going in and being like, well, I have this hypothesis. Let me instrument the app in this way and test it. And then you'll get a risk, like a result and you'll be like, oh, cool. Or, oh, and then you'll hopefully pull those, those events out. If you, if you don't need them anymore, maybe you keep them in to track them over

time, but yeah, I think typically, you know, there's going to be some, some level of being proactive in your, in your metrics where it's like, yeah, obviously you want to do sales, impressions, stuff like that. Person clicks on the pricing page, and then you're going to have very reactive stuff, which is like, you know, instrumenting the app, especially for performance or for like degraded, like experience issues. You're going to go and do deep dives and bits of your app and be like, okay, well, I'm going to really heavily instrument it in this section because we know like maybe through your other product analytics, you know that that section is where people are dropping off and having bad experiences. You know, all of our client libraries for all these companies that do this type of thing, we'll start to be able to capture that context automatically, you know, kind of like a sentry type of thing. We kind of do this on the front end where it's like if there's a sentry exception thrown, we can send an event to post dog and says, Hey, this person has an exception.

We do session recording. And so you can see like the entire front start to finish for that session, like recorded from the DOM. If you haven't enabled and it'll be like the person had this issue here and we're prototyping sending the console logs as well from the front end. So like the front end is kind of like in terms of like web, I think you'll probably see that happening more where events are just automatically like the reactive events are automatically captured because there's just so much context that's available. The backend it's going to take a little longer, but I do think like, you know, there will always probably be some amount of reactive event instrumentation happening. Makes sense.

I think it's also like a model of how mature like the process and the common in the product is like, I mean, the earlier you are like in the life cycle of the product, you're going to be experimenting with it more every day, like you don't have the luxury of sitting down and be like, okay, let's think of what I'm doing. David Pérez- Totally. You're too busy building a product. Yeah.

Yeah. And to be things, I mean, too busy building the product and not to be like also honest, like we don't know what we're doing. Yeah. Yeah. Yeah. No, no. It's you're right.

We're just trying to figure out what we can do. I mean, doesn't make that much sense. Like to start with like strongest options and then trying to test them and like all these like nice things when you have found your product market fit and you're evaluating them this week to make it even stronger, to what's some other, I think, important point for everyone to keep in mind. Yeah. I think we're at time actually.

I think you actually have to go, unfortunately. James, this has been such a great conversation. I wish we could keep going and going because it's so interesting, but thank you for sharing. I learned a ton and what a journey you've had. So congrats on being a post-hog and you've done some really cool stuff that's benefited a lot of people riding bikes around cities. Yeah, no, I love it. I love it. I actually rode a jump bike in or now a line bike in today here. So it's like visiting an old friend. Yes. I love it. All right. Well, thanks for joining us. Awesome. Thank you like visiting an old friend. Yes. I love it. All right. Well, thanks for joining us. Awesome.

Thank you for having me. My takeaway, Costas, is that James brought back, he worked at two companies that sort of took me back, which is great. So one is Grooveshark, you know, which is sort of like one of the like sort of post nap, the first big like post Napster ways to listen to music online for free um which is super interesting and then discuss which was a commenting tool and it's interesting now because i remember implementing discuss using discuss like whatever you know on corporate websites but also like my own blog even and it it's so interesting because, you know, with it sort of came about at a time when blog comments were still like a very dominant form of social media and

social conversation. And it's interesting. So you had this huge spike and it was amazing that they had the biggest Google analytics account in the world for a time, you know, and I think Disqus actually has shrunk a bunch, you know, because so much stuff, social conversations moved, you know, so that was just super interesting. Like, I think that experience was actually has shrunk a bunch because so much social conversations moved. So that was just super interesting. I think that experience was really fascinating. And I appreciate that he took me back to think about those sorts of things. But I also thought it was interesting just the way that he described some of the ways that they have to make decisions around trade-offs, right?

Like even questions like, should a user be able to change data? Should it be mutable or immutable? I mean, those are monumental decisions for an analytics tool, and they're not easy questions to answer. I just appreciated his articulate thought on subjects like that. So how about you? Yeah, I mean, I really enjoyed the conversation that we had about like product analytics and like the whole process and like the advice that he had to give of how to go and implement like tracking and don't create a mess out there so it's always good to see like have like these discussions where you understand that like no matter what the product does there's always limitations and people also need to think and figure out the best way to proceed and implement their tools.

That's one. And the other is ClickHouse again. I mean, we had... It's all over. Yeah, it's all over. We had another discussion about ClickHouse. And again, it's so, so interesting to see tools out there that are open source and they fuel so many different products and that's that's that's amazing so yeah that's the two

main things that i keep from there and his love for biking so he loves biking yes he loves biking he loves biking all right okay Several more great shows for you from Data Council. Stay tuned and we'll catch you on the next one. eric at datastackshow.com. That's E-R-I-C at datastackshow.com. The show is brought to you by Rudderstack, the CDP for developers. Learn how to build a CDP on your data warehouse at rudderstack.com.