Drill to Detail - Drill to Detail Ep.76 'Segment, Ecosystems and Customer Data Platforms' with Special Guest Calvin French-Owen

Episode Date: December 17, 2019

Mark Rittman is joined in the final Drill to Detail Podcast episode of the year by Calvin French-Owen, co-founder and CTO at Segment to talk about Segment's founding story, partner ecosystems and their new customer data platform service, Segment Personas.analytics.js: The hassle-free way to integrate analytics into any web application (Github.com)The Million Dollar Engineering Problem (Segment Blog)Tracking Customer Email Marketing Interactions using Segment Personas and Connections (Rittman Analytics Blog)Segment Personas product homepage

Hello and welcome to Jewel to Detail and I'm your host, Mark Rittman. So I'm very pleased to be joined today by Calvin French-Aurin, CTO and co-founder of Segment. Thanks for having me, Mark. So Calvin, tell us a little bit about, I suppose, how you came to help sort of found Segment and what was your kind of route into that? Yeah, so it's a bit of a long story, so I'll just try and keep it short. We started way back in 2011 when we were fresh out of college. So to kind of set the stage here, it was myself and three roommates from college. We just finished our junior year and we wanted to start a startup

because we thought it would be cool. We didn't really know anything about business. We didn't have a clear problem to solve yet. We just wanted to start a business because we thought it was a fun thing to do. And so originally, we've been big fans of Y Combinator and had read a bunch of work on Hacker News and a bunch of Paul Graham's essays. And the advice that the community was giving us was that you should always start with a problem that you have. And so ourselves being students, we started with actually a completely different idea than what Segment does today. But we started building this classroom product for college lectures. So we were trying to solve the problem where you're sitting in a big lecture hall. The professor says something that doesn't make any sense whatsoever.

And you just kind of look around and you see the people to your left of you are confused and the people to your right are confused. But the professor keeps on going because they don't realize that the whole class is just lost. And so we built this product, which originally was more or less a confusion meter for the professor, where students could enter on an app on their laptops or their phones saying, I'm confused or I get it. And then the professor would have just a passive iPad up at the front of the class, letting them know, hey, 60% of your class just got confused. Maybe you should go back over this point again. And so we built this prototype out over the course of a few weeks and we applied to YC with this idea. And we actually got in. And I guess YC is this incubator based in Palo Alto, Y Combinator.

Yeah, I'm sure many of your listeners are familiar. But basically, they agreed to give you a little bit of funding, and then a lot of advice. And so we went through YC, we tested early classes, Berkeley, Stanford. And then we moved back to Boston because we knew a bunch of professors at MIT from going to school there. And we started putting it in classrooms there and the whole thing just crashed and burned. Students would go to Facebook, YouTube, Gmail. Some students were going to like eBay and things. It was like all places that weren't helping the class learn. But in retrospect, the places you'd exactly expect a college student to go. So at the time we realized, okay, maybe we didn't build the right product here.

So let's try something else. Because we'd actually just raised money from investors who said, hey, we believe in the team, like find a new product. So we spent about a year building different analytics products and kind of all of them really didn't get us anywhere. We just kept building things for marketers and for big growth teams. And meanwhile, here we are, four college students who have never run a website for more than 100 people. And so finally, we get to December of 2012, and we realize that things really aren't going well. We've got about six months left of runway. And we're starting to figure out like, okay, maybe we have to go get real jobs somewhere.

Maybe the startup thing just isn't for us. Maybe we're just not good at it. And we decided to try one kind of last-ditch effort where we said, okay, we're going to just try and launch something and put it out there. And we went back to solving one of the original problems that we'd had pretty much from day one or two of building out the classroom product. And that was that we were trying to get more analytics about our users because we wanted to understand them and we wanted to build the right product for the right classrooms. And what we found was that there were these three tools on the market. There's Google Analytics, there is Kissmetrics, and there is Mixpanel. And we were looking at all three.

And remember, we weren't sophisticated at all. We were coming at this totally fresh. We couldn't really understand the difference between them. And so what we decided to do instead was we said, okay, we're going to take the lazy engineer's way out of this. And we're just going to send the same data to all three. And we'll figure out which one to use later. And that really was the birth of the product that is Segment today because we just decided to make that single idea our whole product where engineers could add tracking once and then configure different tools

that they might want to send data to on the fly. So we opened up this little library called analytics.js. It was maybe like a hundred lines of JavaScript that we put up on GitHub. We spent a bunch of time cleaning it up. And honestly, it was really divisive between my co-founders and I. Peter, the CEO said like, oh man, there's no way this is ever going to work. This can't be a real business. We'll launch it and it will fail.

And then we'll move on to other things. But that day that we launched it, December 12th, 2012, we actually got an amazing response on Hacker News and on GitHub. And we got about a thousand stars that day, 300 upvotes. And it was really the start of us towards finding this product market fit and identifying a real problem where even though it seemed like a small sort of niche wedge problem, it was one that really resonated with the market and sort of carried us towards the tens of thousands of companies that we now help today when it comes to managing their customer data. Yeah, yeah. I mean, because I mean, I suppose, I suppose the challenge there is, is you've got something that's a side project or something that's a useful utility and you know, you can release that. And like you said, it got, it got lots of upvotes. It got lots of attention on, on Hacker News, but I mean, I've been involved in companies. I think Qubit at one point had

something called OpenTag, which is, which is again, a similar thing that is sort of partly open source and, and, and it gets, it gets word about you, but also it can become a burden as well in terms of supporting it and so on. I mean, I suppose that was a, was that is sort of partly open source and and and it gets you gets word about you but also it can become a burden as well in terms of supporting it and so on i mean i suppose that was a was that a kind of consideration that this might become popular but actually it's not going to be a business uh it was definitely a consideration for us in the early days um i think what's been interesting to me watching our segment journey is that really i'd advise any founders, early stage startups, or even folks who are looking at new products, just focus on one really narrow problem. Because even if it feels like that problem can't become a business, usually once you solve that problem, customers will tell you their next six problems that they want solved yeah and usually you'll start hearing resonance from a subset who say oh we can like if you solve this for me uh then i'd be fully willing to pay you money um but even just having the the ear of the customer or the customer having your ear is sort of a competitive advantage in that way so so i mean you're the cto and um and i suppose uh

listeners to the show we've had we had uh yali sassoon on in the past talking about snowplow and and we the concept of a javascript tracker tracker i mean maybe just for people who are listening what what is analytics.js and the concept of javascript trackers and i suppose why having just one of those is a benefit to having lots of them what what was the what's the technical part of? And why would that be a problem that engineers want to try and solve? Yeah, absolutely. Maybe before I dive in there, I'll give just a little bit of background on what Segment is and what Segment does. At the core where we're at with Segment today, we have this really strong belief that every business today, every business in the world should be able to provide amazing experiences for their customers.

And in today's world where a lot of those interactions have moved online, they're no longer in person or happening over the phone or over email. They're happening where people just log on to a website or if I'm watching Netflix, let's say I just use the Netflix app. Like I don't even know anyone who is employed there. Um, as those interactions have moved online, fundamentally building those best in class product experiences and creating, um, those world-class products comes down to understanding your customer really, really well. And the only scaled way to do that is with data. And so Segment helps companies become data-driven by collecting data from all those different touch points, their mobile apps, their websites, internal tools that they have, putting it into one clear, consistent place so they can get that

single view of the customer, and then actually activating that data in all the different tools that they're using, Google Analytics or Mixpanel or Amplitude, email tools like MailChimp or SendGrid, customer support tools like Zendesk or a data warehouse. And so really there's a lot to that ecosystem, though, as you said, kind of the start of it begins with data collection. And that's really where we started as kind of the focus of the problem, too. We're looking at a bunch of these different JavaScript libraries that are out there.

And they all come from I'd consider, different generations of JavaScript. I'm sure as you're probably familiar, JavaScript has evolved and still is constantly evolving over the past decade. And some libraries seem like they're sort of frozen in time using JavaScript from five, ten years ago, versus other ones that feel a little more modern and intuitive for developers. And kind of the core insight that we found is that, okay, each of these different JavaScript libraries that you load on your page, they not only increase that page weight, so they create a worse experience for your customers,

but also each of them are slightly different and annoying in their own little fiddly ways. And that's kind of a shame because at the core, they all just care about the same data, which is who are my customers and what are they doing? And so, yeah, we wanted to create just a single JavaScript library that would then allow you as a developer to add it once, track that information, who's my my user what are they doing um and then it can send into an api or collect directly from the client to actually collect that data in a more responsible way but why do you think that resonated as opposed to other ways of doing it really yeah

because you because you guys have you know the growth has been fantastic yeah i think the biggest one to be honest or the biggest contributing factor to that is that writing integrations is sort of, I think Paul Graham calls it a schlep. startups out there are tackling some like super mundane like kind of boring like annoying problem that everyone is just blind to because they're used to doing it um but that if you can solve it for people and you can really make it easy to use and delightful um people just love you for it pick it up um and the example he uses in that essay is stripe uh for a long time like yeah you could collect money online and payments but it was just hard and annoying. And Stripe made it easy. I think Segment kind of fundamentally did the same thing where we made our API focused around the user.

So it was very intuitive. You just track things that the user is doing or identify them when you learn more information. And then also, we took care of all of these annoying little wrinkles when it comes to understanding different APIs in slightly different ways, which in my mind, that's the real schlep, right? Like very few people have ever made the inflection point in their business happen by writing an integration, but everyone has to do it and so i think that's the real place where segment came in and provided a lot of value in a way that was easy and intuitive okay okay so so i mean the product i guess most people are aware of is what

you call segment connections now which is which is rooting we're rooting events to your martech things downstream and and so on and i suppose the question to you would be, I suppose the trick to it is not that you do this, but you do it at a scale as well. And I think to me, the thing that really brought to your attention the scale of what you do was a blog post I think was written by your engineering team a couple of years ago, which was the million dollar engineering problem. And it was all about, I suppose, keeping costs contained and I suppose the effort involved in doing this. But just give us an idea of the scale of the way you do this and how you do this for all these companies at the scale that you do and the challenges there. Yeah, this has honestly been one of the most rewarding parts of seeing Segment grow

for me because I'm sort of a big distributed systems nerd. I just like seeing systems operate. And so getting that front row seat into seeing the company scale over time has been incredible. Today, we process about 450 billion events every single month. And that translates roughly to 250,000 requests per second coming through the pipeline. In order to run all that, we basically completely containerized our infrastructure. So it's running as a bunch of these little microservices and a bunch of different Docker containers, which are kind of all consuming data, filtering it, publishing it to other Kafka topics. But in total, we're running about 16,000 of those containers in production today. And so very quickly, you can probably get a sense that as we've had to scale incredibly quickly, we want to be able to deliver all this data for customers.

We try and achieve a latency end-to to end of about 1.3 seconds from first entering the front door to making it successfully into one of those products, Mixpanel, Amplitude, Google Analytics. And then at the same time, we want to make sure that we're doing it in a cost effective way for all those customers as well. So that kind of spawned the impetus for the blog itself, because obviously at a fast growing startup, like as you just add and add and add and add more complexity, it's easy for some of those costs to balloon a little bit more than they should. And so we've tried to put a focus usually about once a year or so just on understanding where our costs are coming from and then figuring out how we can optimize our infrastructure to solve for that. Okay.

Okay. And I suppose connections as a platform is, I mean, we're talking a bit about personas and other products, but something I noticed, I think your conference was recently and you mentioned you've launched, I think, custom connectors, custom destinations and functions and so on. I mean, so what are they really? And what problem do they solve really as well? Yeah. So I'd say this is still an early product. The product you're referring to is just called Segment Functions. And essentially what you can think of them as is sort of like Lambda for segment.

It's little bits of code that transform the data either coming in the segment or going out of it. And the real problem that this addresses for many of our customers is that they said, well, it's incredible that all of my data is kind of able to be put in one place in segment. But now if I want to add some custom functionality or maybe like a workflow that's unique to my business, or maybe there's just a really niche tool, like a shipping tool that I want to use that's particular to my vertical, but doesn't generalize well to segment. Now at this point, I'll have to spin up a bunch of infrastructure to handle that. So I can hook into segments, web hooks, and I can spin

something up on Heroku or AWS. But typically I'll have to manage that a lot, manage a lot of that infrastructure myself, whether it's doing provisioning, capacity management, analytics, dead letter queues, retries, like kind of the list starts going on. And so we really thought like, okay, can we simplify this? Because at Segment, we're really all about making this customer data simple, intuitive, and just easy to run at scale. Can we make this as easy as the user just writing 10, 20 lines of JavaScript that take that data either coming

in or going out of Segment and letting them do whatever they want with it. If they want to tweak an integration behavior, if they want to write an entirely new integration, if they want to hook up to an internal tool, really we should just make that as easy as possible for them because all their data already lives in Segment anyway. So we've actually seen pretty cool use cases from that. There's one customer who's hooking this up to a decades-old internal system that they have.

And so they were imagining this migration would take about six months to do. They started using Segment functions and it took them one day to write the code, get it into production and then start collecting data from it. So big strategic shifts like that to even customers who just want to light up lights in their office every time they close a deal. Yeah, it kind of runs the gamut in terms of what people are looking to do with making writing and running code really incredibly easy. Okay. Another part of Connections I've been using a lot recently

is cloud sources, object sources, and so on. So they're conceptually a little bit different, aren't they, to event and event sources. What was the, I suppose, the thinking behind that and how do they work? And again, what problems do they solve? Yeah. So cloud sources themselves were born out of just continuing to talk to customers and understand what their needs were. And so for many of the customers who we talked to kind of before the cloud sources product existed, they said, well, it's great that Segment can collect data from places where essentially my code is running. You can collect data from my website, from my mobile apps, from all of these different touch points. But there are a bunch of places where I have touch points with customers where maybe it's harder to get at.

You could think of people paying you through Stripe. The payments just get collected there and then they more or less live in Stripe. Or people emailing your help desk. Tickets get logged, they get closed. It's all happening in Zendesk. Or, at least in our case, also as a B2B business, we do a lot of our sales and account management through Salesforce, right? And so for us to get a holistic view of that customer journey, and even to just calculate our total revenue from the business, we need to pull

data from Stripe about what plan people are on, what they've been invoiced for. We need to pull data from Stripe about what plan people are on, what they've been invoiced for. We need to get deal data from Salesforce to understand how much revenue is currently closed for the quarter. And then we actually want to tie that to analyze, hey, where are our best users coming from to all that behavioral data, the data on your website, on your mobile apps. And so really, that was kind of the impetus for it, just trying to collect data from all these other places where people might want to analyze it. And a big one that we heard over and over again, as well as understanding ad spend. People feel like they're throwing millions of dollars at ads and they just don't understand how they convert all the way through the customer journey. So we said, okay, we're great and world-class at moving this data around,

at providing that one single view of the customer. We are now going to pull data in from all of these other cloud sources, things like Zendesk tickets or Stripe charges or Salesforce accounts. We'll help you get that into one place. And then you can actually analyze it in your warehouse by explicitly joining all these different fields together to get this view that, honestly, we could not run our business today without that level of insight. Okay. Okay. I mean, that actually goes quite nicely into, I suppose, the next area of kind of segment I've been working with a lot, which is, I suppose, around the idea of customer data platforms and the personas product.

So maybe just for anyone listening, what is segment personas and what is this concept of a customer data platform that personas is addressing? Yeah. So maybe I'll start with customer data platforms in general. I think when Segment started, it was really this new thing on the market that there's kind of nothing like it, where it served as this integration layer for SaaS apps and SaaS tooling. It made it really fast, essentially, to connect different sources of data to different places where that data should go and where that data should live. I think over time, as the business has grown and the market has grown and our understanding of the market has grown, a lot of companies are starting to realize that, hey, again, our interactions are increasingly moving online or into these different data sources or these different SaaS tools. And we need something that is stitching them all together, because otherwise we're going to get a disjoint customer experience.

And like the clearest example I can use to illustrate this is email tools. Typically, a lot of companies have multiple email tools, maybe one that they're using for marketing messages, something like, hey, we have a new fall sale. And then one that they're using for more transactional messages where they're saying, you completed this order, here's your receipt, here's the items you bought. Oftentimes, what we find with customers who are just starting to work with is they say, okay, I have these two email tools. Because they aren't connected, sometimes I will send people that marketing email the same day that I'm sending them that transaction email. And when that happens,

the customer is about 3x more likely to say, wow, I'm just getting too many emails from this brand. I'd like to unsubscribe. And that really doesn't help anyone because it doesn't help the company reach the customer again. The customer stops learning about new updates that are coming. And so really, the main problem is just connectivity. These two email tools aren't connected. And so that's really what's driving this adoption of customer data platforms. It's connecting all of these different tools and making sure that the data collection is kind of the same throughout all of them.

But then even leveling up a little bit and focusing on this idea, not just of data and data points, but really of a user. Because at the end of the day, you don't care about data, you care about your customers. And so that's really where customer data platforms come in. They have this collection

foundation, they probably have some identity resolution. And then in a lot of cases, there's ways to orchestrate or kind of build that full customer journey. And it was kind of out of that market shift and that changing problem yeah that we built personas so i mean you mentioned at the start almost like you know just in passing about um identity resolution and trying to type tie people together or sessions together from somebody across devices time and so on i mean what why is that a tricky problem to do and and how what's what segments approach you're doing that really? Yeah.

So I think say there's two things that make identity resolution tricky. I'd say one of them is just the fact that identifiers change constantly. So you could imagine someone logging in via their mobile app and then switching to web. Most of the time, unless they've actually logged into your website, there's no cohesive identifier between those two. And so a lot of companies will struggle to figure out, okay, as a person first comes onto the website, like when they sign in or they sign up, how do we trace that path all the way through? And so at Segment, we put a big focus on first party data. We don't want to be collecting or doing things like fingerprinting. We don't want to be sharing data across companies because really, ultimately, we believe that the best brands in the world, the ones who are really going to succeed in the next

20, 30 years, are the ones who are handling data responsibly in a way that the user expects. And so the way that works in Segment today is that we say, hey, if you're collecting data from your website or your mobile app, send us that ID whenever you have it. But otherwise, we'll use whatever the built-in cookie or identifier is for that particular browser or that particular device. And you can still collect data that way. But whenever that user opts in and that user says explicitly, like, hey, I am Calvin at Segment. I'm excited to use your product.

That's then when you send us the identifier. And in particular, we put a big focus on this identifier being something that is important to you and makes sense to you. So most of the time, that is an ID that comes from your database. It's not like a Stripe ID. It's not an email that might change. It's not like a fingerprint. This is like the definitive, I know this user and they are ABC123. And so that's kind of the first approach that we're respecting privacy of these users and that we're doing merges in an intelligent way. So if you see that user A coming in through mobile and you say, oh, there's also user B coming in through web, we'll actually merge those together for you. They'll also give you controls if you want to undo that merge as well. And really, we've invested a lot in trying to make sure that makes sense across the whole customer journey so that you don't have to worry about any cases where oh a user came in through these

different touch points but we're giving them completely distinct experiences and messaging so i mean you mentioned privacy there and gdpr over in the europe has been a big issue sort of a big thing to think about recently and and again, using the product, you've got Privacy Portal and so on. I mean, what, again, what is the, I suppose, what impact did GDPR have on you and the rights and so on? And how has segment sort of, I suppose, addressed that and maybe kind of gone beyond that and built that into a benefit for the product? Yeah, GDPR is an interesting one because not only do we operate in the EU,

about 15% of our customers come from there, but obviously also we're processing data for a bunch of different companies who are there or a bunch of companies who have end users in the EU. So actually about nine months before the GDPR legislation rolled out, we were kind of on top of it and reading through and trying to understand the implications of it. We said, you know, as a company who firmly believes in this level of first party data and knowing your customer really well via information that they've explicitly told you,

we actually want to be really aligned with GDPR because ultimately we think it's sort of a good thing for the world and that there's going to be more and more privacy regulation that continues to roll out across different countries. And so we actually said, okay, we're going to make GDPR support a first-class product in segment. If you're a company, you can request that one of your users by that user ID is either suppressed, you don't stop collecting data for them, you can make sure they're forgotten, so you can delete all data that you currently have. And you can ensure that basically you're handling their request properly and get a receipt for it. And we said, okay, we'll offer this via API. We'll offer this in the segment web app. So you can delete either of those ways,

whether you want to do it in an automated fashion or whether you want to do it kind of one-off. And then even going above and beyond that, we'll help you delete that data in a bunch of the different tools that you're using. So if you send in a deletion request, we'll also send it to Amplitude. We'll also send it to Braze. We'll also delete that row of data in your warehouse.

We really wanted to double down and invest here just because we feel like it's the right thing to do and the thing that the market will reward kind of over the long term. And so we rolled that out now about a year and a half ago because it was right at that May 2018 time. And when I ran the numbers on our first anniversary of GDPR, and frankly, I was blown away by how much customers were using it. We saw about 7 million deletions of various user IDs in that first year, which when you think about it, it's kind of crazy, right? There's 550 million people in the EU today.

So that's almost one, a little more than one out of every hundred of them. I mean, granted, some of these people maybe were not in the EU, but it's a much bigger number than I'd anticipated. And even more than that, we started seeing customers actually changing the way their business is done to respect user privacy because we made it easy for them. So yeah, yeah. So instead of a company, when you delete your account, them just marking a flag in the database and not actually deleting the row, but just sort of saying, okay, don't show this anymore. Don't allow the user to log in. We were actually seeing companies not only take that step in their own infrastructure,

but they're actually now, anytime a user deleted their account, they're issuing calls to Segment to say, hey, I no longer want to control this data. Can you please purge it from my analytics and various data infrastructure? And so honestly, we thought it was really cool as a new, more respectful way for users who

explicitly said hey i want my information to be dropped uh for companies to actually respect that and be good stewards of that data okay so another another new product you launched a while ago was protocols and and i mean that's i suppose to take as to my perspective on that is is a good a good line of business is is helping is is helping customers implement tools like Segment actually add some kind of governance to their setup. Because beyond a certain point, that can detract from the benefit they get from it. I mean, just tell us a little bit about what the problem is that protocols addresses and I suppose the challenge around data governance with event systems in the first place? Yes. Protocols first started from watching some of our bigger customers as we started growing the product. Many of our early customers were small startups, right? And they kind of came in

and they used it and they'd figured out, uh, what we call a tracking plan, just what events they want to collect and how they want to collect them. Um, yeah, yeah, exactly. Exactly. Uh, but for small startups, it's, it's pretty easy for everyone to just get in a room and say, okay, here's what we want to collect. Uh, here's how we'll use this data.

And they can kind of go from there and more or less be in sync. Today, however, we're onboarding some of the world's largest enterprises where they literally have one of our customers has about 950 people who log into Segment on a monthly basis. Another customer is tracking well over 3,000 different types of events. And for many times or many points in time, especially as your organization grows, you'll start with that one room of people, but pretty soon you'll have 10 different business units spread across six different time zones

and all this communication overhead to understand how your data should be gathered and what format it should take. And obviously, we looked at this and we said, wow, we think there's actually a big product opportunity here because most organizations don't do anything and their data just sort of slowly becomes this rat's nest that's really hard to keep track of. But the more advanced ones start putting this data into a spreadsheet where basically there's one owner for the tracking plan and they're kind of figuring out what to track. Now, the problem, though, with the spreadsheet is that typically teams have to QA that like, yes, the data that we're collecting actually matches what's in the spreadsheet. And oftentimes it's really easy to

get wrong. Like as an example, I use all the time, imagine you have an iOS and an Android app. You're this online e-commerce company. You implement all of your tracking correctly, everything from page views through signups, through users adding items to their cart, to viewing certain products. And then the last step in your funnel is measuring that order completed event. Now on iOS, you do the entire tracking plan. Everything works perfectly. On Android, you get all the events right, except that last one where uh the developer maybe it's just before they had their coffee uh instead of adding order completed they do completed order

and suddenly that starts messing up your entire uh messaging and customer experience and funnel because let's say you want to send people a coupon if they got through every step but that last one suddenly you're emailing users who did complete that event anyway, but you just didn't realize it. So that's where protocols comes in. It's designed to automate and automatically enforce not only that tracking plan so you can understand what data you're collecting, but also let you filter it, transform it, enforce that certain data is being collected, alert you on anomalies, let you know if some data isn't being collected critically, and really control that data quality. We've actually seen this be a very popular product

amongst our customers because for them, every time that they have bad data or they have to do this qa step it basically just costs them a crazy amount of time to go back and figure out what happened and so the software just makes that explicit and automatic so so we say i mean so segment you took one of the i suppose one of the differences between segment and say i don't know mix panel and heap and whatever is that you do have to explicitly go in and track every every event you want to track and and whereas i think some obviously some other event collecting systems they track everything i mean presumably there's a deliberate choice on your part to go with selectively tracking versus tracking everything i mean why was that what was you thinking on that yeah so i think this idea of selectively tracking comes a little bit from our origins,

but maybe more just our philosophy kind of on data collection in general. Really, we think that the companies who are using data in the best ways are ones who put a little bit of thought into it and are just explicit about what it is that they want to measure and what they want to do and how they want to collect that data. And so we kind of always put the emphasis there saying like, okay, you maybe need a developer, like a web engineer or growth marketer to help implement parts of this at the beginning. But because you are thinking critically and you're tracking with intent, the results that you get on the other side are going to be much, much better. And you're going to always know what the events mean. You're not going to see these sort of like cryptic auto-detected things.

It's like, you're just going to get the data that you want in the right way. That said, we do know that we want to make this easier to work with. So we've been exploring various plugins and extensions and just new product onboardings for letting the user maybe visually tag their events or set them up in a way where they don't require a developer, but they're still applying that same level of intent and thoughtful measured practicality

when it comes to the data they're collecting. Yeah, I've actually seen the visual tagger and it sounds interesting in that respect. Yeah, interesting. I mean, I suppose the last thing I want to talk to you about is actually a great lead on from that really, which is as a CTO and as a founder, how do you decide in a way what to add and what not to add? I mean, if you look at the competition, you've got the competition out there. So you've got Emparticle, you've got other companies out there that do Snowplow, for example. How do you position yourself in the market? How do you choose what features to add and what not to add and what to compete on and what not to compete on?

What's your thoughts on that? Yeah, it's a great question because I feel like every company out there must be struggling with this at some level. I think for us, one of our advisors who worked at Twilio had this great advice. He said, you know, at Twilio, we built our business for many, many years. And what we saw as our competitive advantage was just the fact that the customers had our ear, basically. Like, as long as we could continue helping customers solve their problems, they'd keep telling us more. And that would tell us the direction to go in. And I think that's really what has driven our product direction to date.

I mean, when you think about us starting as this hundred line JavaScript library that we host for you, which can send data to six different places, it's dramatically smaller than the number of problems we're able to solve for people today, right? Whether it's getting consistent customer data in one place, whether it's moving more quickly

when it comes to building integrations, whether it's personalizing or providing a really custom world-class experience. I think the number one thing that we've done when it comes to understanding new features is just ask the customer. We talk to folks who are not yet customers. We talk to folks who are customers about how we can serve them better. And we really try and apply this focus

to make sure that we're constantly building things that will make our customers' lives easier or give them more power to do things. So I think that's the overarching goal that we take. In terms of how that plays out, definitely for us, the business has now spanned many different areas all the way from solo developers who like our APIs, our documentation, and just the responsiveness that you get when you start spinning up segment, you see the events streaming into the debugger in real time, you see where they're going in real time. It's like you start this magical experience. All the way to global CIOs and CTOs

at some of these biggest brands in the world, places like Levi's, Intuit, Gap, et cetera, IBM. And at those places, I think what they're most excited about is the fact that they finally feel like they have this modern data foundation that has really invested a crazy amount in just working and being the infrastructure-first solution that they've been trying to build or purchase internally for maybe years at this point. But it's one that they just put a lot of trust in Segment to be that single view of the customer.

Okay. I think the other thing that's striking about you guys is you're at the center of an ecosystem. I don't know if you saw the tweet that was out a couple of days ago when one of the original founders of rj metrics was was talking about how um in their view that although although they did well when they sold to magenta you know they looking at the acquisition of looker by by uh google it really showed the value of an ecosystem and i suppose for you guys it's also almost i suppose what markets you choose not to compete

in and actually to support the ecosystem is important. Is that something that's part of your philosophy as well? Yeah, I'd say ecosystem is definitely a big part of our focus. I mean, obviously, segment would be nothing without the tools where we send data. You could choose to do a lot more, couldn't you? You could choose to kind of, I suppose, to build out transformation stuff. You could choose to do a lot of, couldn't you? You could choose to kind of, I suppose, to build out transformation stuff. You could choose to do a lot of things, but you choose not to. In our case anyway, like we really view our partners as true partners.

In most cases, well, if you think about even the very first version of Segment, it wouldn't have existed if there was only one place to send your data or if there was only one cloud tool or if there was only one analytics tool. Really, Segment's entire existence is prompted by the fact that there are many tools on the market and many places where you want to send your data and many different uses that different customers will have. Whether you're a B2B SaaS business or an e-commerce business or you're a mobile game or something, you're probably using different tools. And so at Segment, we really want to see that entire ecosystem bloom.

And I think where we kind of draw the line is whether we think that the new product or the new feature makes more sense in the hub and being the connected tissue across those tools or whether it doesn't. And so you look at like an analytics or a messaging tool or like a tool like Customer.io for sending emails, for example. Customer.io is going to be 100 or 1,000 times better at like the editing experience for emails,

actually trying to send those emails, putting a big focus on creating like the best emails in terms of marketing copy, display, imaging, layout, all those things that would just be hard for us to do well as this data layer. So instead for us, we put more of our focus on things like data transformations, filtering, privacy controls, audience creation. Because in some ways, all of those just feel very fundamental and they're kind of compounding. Like if you do them in segment once, suddenly it makes all of your tools better. And so really that's sort of the guiding velocity between the products that we tackle. It's where customers see a need and whether it

makes more sense to be just in one single place. Okay. Okay. So just to round off then, how would a developer or a customer get to find out more about Segment and maybe try it out, have a play around and understand how it works? So you can go online to the website today. You just go to segment.com. You can sign up for free. There is a pretty generous plan for individual developers or people who are just trying to kick the tires on the product. All you have to do is add just a few lines of code to your site, and then you'll start seeing events streaming in real time. I'll also add that, especially for early stage startups, we offer a discounted startup program, which gives you, I think it's something like a million dollars overall in terms of free tooling, whether that's Segment or one of our partners. And we also then give you

a few more resources as well when it comes to getting on board whether that's analytics academy which can teach you how to think about analytics for the first time working with some of our partners or just understanding more of the ecosystem through our documentation fantastic excellent well i mean i've loved using the product it's really good and it's been great speaking to yourself calvin as well and uh yeah thank you thank you very much and uh it's been great and uh yeah have a good rest of the day and thank you very much great thanks for your time Thank you.