Good afternoon, everybody. My name is Yuka Broderick, and I lead Investor Relations here at Datadog. I want to welcome you to our 2024 Investor Day. Before we dive in, let me read off a couple of legal disclaimers. During this presentation, we will make forward-looking statements, including statements related to our strategy, potential benefits of our products, our investments in R&D and go-to-market, our ability to capitalize on our market opportunity, and our financial goals. These statements reflect our views only as of today and are subject to a variety of risks that could cause actual results to differ materially from expectations. We will also discuss non-GAAP financial measures, which are reconciled to their most directly comparable GAAP financial measures, in the appendix to this presentation, which will be available at investors.datadoghq.com. For discussion of the material risks, please refer to our Form 10-Q for the quarter ended September 30, 2023, and other filings that we may make with the SEC. Our filings are also available on the Investor Relations section of our website, and we will make a replay of this presentation available there after we conclude this event. Okay, let me briefly run through an agenda for today. In the first half, we are going to focus on our strategy, our platform, and our product innovation. You'll hear from our co-founders, CEO Olivier Pomel and CTO Alexis Lê-Quôc, as well as our product leaders Yrieix Garnier, Michael Whetten, and Prashant Prahlad. We'll follow with a Q&A with that group. And in the second half, we will discuss our go-to-market and how we engage with our customers to deliver value. Our presenters will be CRO Sean Walters, SVP Customer Success Angie Holt, President Amit Agarwal, and CFO David Obstler. We'll do another Q&A session joined by Olivier. All right, with that, let me turn it over to Olivier to kick things off. Thank you, Yuka. Hi everyone. I'm Olivier Pomel, I'm the co-founder and CEO here at Datadog. So first of all, welcome. It's the first time I think we do an Investor Day in person. Today you're going to hear from several leaders on our team. I know they're all quite excited and a bit anxious to present, so we'll see that. As we discuss what we're doing here at Datadog, our goal is to show you that even after 14 years of building Datadog, we believe that we're still only just getting started, and we're barely scratching the surface of our opportunity. So I'll kick us off today with a quick recap of the problem we solve. I will explain how we think more broadly about new expansions, and also I'll give you a sense of some of the directions we're taking for the longer term. All right, so let's start with this beautiful cloud migration and digital transformation chart, which is the Gartner data we all know and love. As you can see there, we've seen sustained rate of migration over the past few years, and we expect that migration to continue for the foreseeable future. It is worth noting that Gartner expects spend on public cloud to exceed $1 trillion by 2027. And even then, it will only be 18% of global tech spend. So why is it happening? Well, it's happening because as a company, you have to. You have to interact with your customers online, you have to differentiate from the competition through innovation, and you have to run in the cloud to get agility, to get short time-to-value, and operational efficiency. To be honest, you also have to lean into tech to hire the best and brightest engineers and not be left behind. In the end, this modernization leads to better business outcomes. All this was true over the past decade, and we expect it to be even more pronounced in the age of AI, where being digital and in the cloud are true prerequisites to adoption. So now this is a slide I've been using for more than 10 years now. I think you can find it in early pitch decks for Datadog. And it's still true today. What it shows is that when you lean into tech innovation, you are faced with an explosion of complexity. You see there the explosion in terms of the number of technologies that are in use, the number of compute units, the frequency of changes in software. We went from shipping software once a year to, in the case of Datadog, dozens or hundreds of times every day. You also have an explosion of the number of people involved to ship and run software. The way to combine those charts is to multiply them. So what you end up with is really an exponential explosion of complexity. This is the problem we solve. To put it simply, Datadog exists to solve this enormous problem of complexity for our customers. We connect to all of their software components. We scale with all the infrastructure compute units they deploy. We also scale with the services they create and deliver, and we understand the way infrastructure and applications are changing. We also connect separate teams to each other across functions. So how do we build product? Well, obviously, there are many ingredients to building a successful product such as Datadog. But if I were to reduce it to the two most important ideas, it would be, first, that we build Datadog from day one as an open-ended, unified platform. All of our products are tightly and deeply integrated at the architectural, at the data, and at the user interface layer. The same platform serves end-to-end use cases from one dataset to another, from one product to another, and across team boundaries. The second key ingredient would be our relentless focus on delivering a product that can be easily adopted. We call it simple but not simplistic. Simply because our products should be deployable in minutes, by mere mortals, without extensive trainings and service engagements, and they should show value extremely quickly. One way to put it is that Datadog should be as approachable and as easy to adopt as a spreadsheet. By not simplistic, we mean that after getting started with Datadog, our users can endlessly customize it and build on it by adding on use cases, datasets, analytics, or automation. The result is a platform that is deployed everywhere and used by everyone. Deployed everywhere because it touches every infrastructure and application component at every layer, and used by everyone across application developers, operation engineers, and security engineers, but also business users, support teams, FinOps teams, and all the way up to C-level executives who can see their business operate in real time through the prism of their applications. And this, in turn, allows us to break down silos by bringing everyone into the same place. So 14 years in—sorry, I'm getting a little bit too far ahead. Have we been able to fulfill some of these ideas? Well, maybe we're not deployed everywhere and used by everyone just yet, but we're making progress. Every month, about 600,000 active users log into Datadog to analyze, coordinate, and take action on their company's issues across development, operations, and security. And by the way, this is only our paying customers and exclusive for users. Now, when we look at it across 27,000 customers, this means that, on average, a couple dozen users per customer are using the platform. Remember that the majority of our customers are quite small, and the bottom half of our customers is about 1%-2% of our revenue. What it looks like for large customers is that hundreds of users, on average, use our platform every month. This number is growing. Despite the last couple of years being years of contraction for headcounts at larger companies, we keep expanding as we spread across more use cases and more teams. We've also made progress in delivering a unified platform. As I discussed in a recent earnings call, we now have over $1 billion of ARR in infrastructure monitoring, and over half $1 billion of ARR in both APM suite and Log Management. The fact that we have real balance across the three pillars of observability shows that Datadog is unique within the industry in establishing true value in terms of platform for customers. Over the years, we've moved beyond the three pillars into new product areas. Because we're deployed everywhere and used by everyone, we have a very broad surface of contact with our customers, which in turn allows us to solve a bigger and bigger problem within that surface of contact for them, while benefiting from our shared unified platform, which allows us to build faster into these new areas. I also believe that we have proven our ability to execute by consistently expanding and successfully entering new product categories. Now, switching gears a little bit and looking at the way we think about our expansions into new categories. What we see here on the slide is one way you can model on the customer side the continuum of problem areas that takes customers from tech innovation all the way to realizing business value. So you have writing code all the way on the left, and you have understanding what the value is and running the business all the way on the right. So we started right in the middle in observability. And of course, we didn't have all the functionality here from day one. We added a lot of it over time as we kept going deeper and kept covering all the new technologies our customers were adopting. From there, we noticed that our customers were falling behind on cloud security. And because of the data we gathered and the time they spent in our platform already, they started building their own security solutions on top of Datadog. So this made it clear to us that they saw us as a natural part of the solution for it. We also stepped back and looked at the broader categories in security. What we saw was that there were many, many disparate subcategories within security, and that these many, many point solutions were used by many, many teams that were living in silos, and that there was an extremely high friction to instrumenting and deploying tools in these categories. Altogether, this created a gigantic mess, and the problem was running away from customers. It was clear to us that we had a real opportunity. From observability and DevOps, we have moved in recent years into DevSecOps to help our customers not only understand but also secure their cloud footprint. We'll have Prashant on stage to tell us a bit more about it in a bit. Now, looking left on the development and test side, the same dynamics applied. We found a huge mess of disparate categories. We saw teams in silos. We saw high friction to getting tools adopted and delivering value. We saw our customers build their own solutions on top of Datadog. This is why we started working on software delivery. Looking on the right side of the spectrum now, we saw the same exact story and have expanded into user and product analytics. What we found when getting all of this into the hands of customers is that by broadening our scope and removing painful integration points, we see the value of our platform go up dramatically. In the end, this makes the whole worth a lot more than the sum of its parts. The most recent area we've been expanding into is a space we're calling Cloud Service Management. What this involves is going beyond helping our customers understand and secure their systems and into helping them coordinate people and teams to manage, communicate, organize, take action, and more and more automate responses. We're still very early in this effort, but we know there's a large need. Michael will tell you a bit more about it in a few minutes. This dovetails into what I see as our longer-term opportunity and our mission as a company. This isn't really a new category, but rather going further in every single one of them. We call it closing the loop. It's about doing more than just watching, observing, and alerting, and instead going all the way to taking action. This is about making our customers an order of magnitude better, faster, and more efficient. It's about extending our customers' reach so they can build faster, iterate faster, and get better business outcomes. It's about bringing the right information to the right people before they even know they need it. It's about preventing issues instead of responding to them. And it's about automating as much of the grunt work as possible. If you remember the slides I showed earlier about complexity, well, ultimately, the goal here is winning this race against complexity. So you may ask, why us and why now? Why do we think we can do this? Well, I think we were built for this. First, we built pure SaaS from day one. We know exactly what works and what doesn't work for our customers. We can also allow our customers to use their rich data to customize models to their specific needs and improve their operations. We can ship and iterate quickly as we go deeper and broader into the problems we solve. Second, we're a mission-critical part of our customer workflows. We're used by teams to keep the lights on, to ship changes, and fix what breaks, whether that is on the application, the operations, or the security side, which puts us right where the rubber meets the road. This is where work happens. And that's the ideal insertion point for process improvement and automation. Third, we have an incredible dataset. And because it is used for very critical things such as waking people up at night and fixing issues, there are lots of eyes on the data, and it is kept extremely clean. So that was why us. As to why now, well, so much is happening in AI and machine learning today that it opens many, many new doors to combine the usage data and the insertion points we have with our customers. So I'll leave you with this. We think we have a unique opportunity to be this end-to-end platform and to make our customers one order of magnitude more productive. Of course, we won't do that for every single aspect of their business. They have other platforms already tying sales or finance together. But for every step going from code to business, we want to be the force multiplier. We think it's a big mountain to climb, and we'll keep making incremental progress towards this goal quarter after quarter. But we are very excited as this is a huge opportunity to deliver value for our customers if we can get this right. Now, if we zoom out a little bit and look at what will drive growth for us, as David will cover a little bit later, our market just in observability is very large and is growing very quickly. Our market share is still only in the single digits. We think that observability alone, on its own, holds the next 5x or 10x scale-up for us. But if we can be successful at some of the other things I brought up today, I believe that the sky is the limit. This is why we still feel, and I still feel, that even 14 years after founding Datadog, we are still just getting started. Now, I will turn it over to Alexis, who will talk to you about our data-driven advantages and how we can apply that to generative AI. Thanks, Olivier. Hi, everyone. My name is Alexis Lê-Quôc. I'm CTO and one of the founders of Datadog. Olivier gave you a clear picture of the dizzying complexity that our customers operate at. He presented the opportunity also in a clear fashion. What's ahead of us, especially given the platform we've been building over the years? Now, you may ask yourselves, OK, but what's the impact of AI on our customers and on our business? And that's what I'd like to talk about. Here's a familiar slide. So you saw the left part of it a couple of minutes ago. What I've done here is I've added to the right-hand side two charts. The top right one is the number of new large language models that have been developed over the past five or six years. And you can see it's increasing really fast. The second one at the bottom is a proxy to the amount of inference power available in the world, including what's in our pocket. So why does AI compound complexity? Well, in short, because of the enormous amount of data and processing needed to achieve differentiating results with AI models. Now, we can all experience that neural networks, transformers, large language models in general work really, really well, surprisingly well. But to this day, no one knows why they work so well. All we're left with is to observe that the more data they get for training, for fine-tuning, for inference, the better they are at producing predictive results. So for everyone investing in AI, us included, we think the lasting differentiating advantage is not in the amount of GPUs you have or how sophisticated the models you use. Sure, they matter, but it's not enough. We think the lasting advantage is ultimately in the data available for training, for fine-tuning, for inference, and the ability to manage the data at scale. So what does that mean for our customers? So AI models require a lot more data upstream of training, during training, fine-tuning, inference, and so on. And that drives a lot more processing for all that data and ultimately more complex software because this is a whole new universe to deal with. So this is how we think AI compounds the complexity of the whole software infrastructure. What does it mean for us? Well, if we want to build the best AI, meaning if we want to close the loop for our customers in the most optimal way, we're going to need the most data and the best data. What do I mean by that? Well, we made some foundational choices at the start that are even more critical today as we enter the age of AI. The first part is how to get the most data. That's all about data collection. This is where starting Datadog as a SaaS platform from day one was critical because SaaS gives us a volume of data that's just not available to on-prem solutions. With the SaaS platform, the amount of data increases with time, with products and use cases, and with the number of customers. And what does it mean to have the best data? So best data for us means you have clean, accurate, and rich data. And as Olivier mentioned, because we're part of our customers' critical workflows, they constantly send us data that's arguably among the richest, cleanest, and most accurate from their whole tech stack. This is the very same data that they use to wake people up at night, troubleshoot issues, and resolve them. And finally, there's making sure we can process the data we get. So as we collect exponentially more of it, it gets harder and harder. With petabytes or exabytes of data, there are very few tools that can operate at that scale. There are also very few teams who have the experience to operate at that scale. And this is the part where we innovate on all the time. And tying it back to my first point, this is something that only SaaS allows. If we were on-premise, we would never have reached that scale, and we would never have learned what we now know. Now, there's, of course, always things to work on to improve. But I think we've had some success at getting those foundational elements right. Today, customers continue to send us an ever-increasing amount of data. One dimension, it means getting data from more VMs, more Lambdas, more containers, more services, more APIs, and so on. The second dimension is that we do it for more products, more use cases, more people. The third dimension is that even with existing products that are 5, 10 years old, we keep adding we keep collecting new data with every passing release. Today, we have many products. Our customers are sending us clean, rich, clean, and accurate data. For instance, we've been receiving infrastructure data from our infrastructure monitoring product in the past 12 years, more or less, traces from APM in the past 7, logs in the past 6, and so on and so forth. So with that wealth of data, we are really excited with what our investments in AI can do for our customers. That is to say, helping them stay ahead of the complexity of their environments. Now, let me give you a quick example. This is Bits AI. So for those of you who are not familiar with Bits AI, we introduced it at DASH, our user conference last August. What it does, it incorporates large language models to act as an incident management tool, Copilot, if you will. Here's Kai. She's interacting with Bits AI. And so she's asking, who am I? And Bits AI actually knows who she is. It knows she's a product manager. She focuses on Bits AI and case management and other things. LLMs are also really good at understanding in-context and generating relevant content. That means that Bits AI can send information that Kai needs at the time she needs it. In this example, Bits AI uses context to understand what she means. So she's asking, what's going on with a service called metrics aggregation? Now, one thing to note, and so it starts to answer with a bunch of stuff. But one thing to note is, in a complex software infrastructure, there's always something that's broken. So if you ask in a sort of simple way what's going on, you expect to get pages and pages of things that are not quite right. Doesn't impact the service, but there's always at the edges things that are slightly off. But here, Bits AI focuses on what matters. And this is the power of LLMs coupled with the data we have that allows us to do it. Bits AI can also help Kai get up to speed really quickly. So here, in this example, she joins an incident midway. Maybe she got paged, and somebody needs her help. But Bits AI can do and effectively, this is LLMs, again, coupled with the data we have. It can get her up to speed really quickly. What the issue is, what the impact on customers is, root cause, contributing factors, remediation, and so on and so forth. And lastly, as an example, I wanted to show you also that Bits AI can help resolve incidents. It can generate content with a full understanding of the structure of the teams, of the software, of the architecture, and suggest a solution either by listing commands that Kai, in this case, could run or even suggesting a workflow to be ready to be scheduled in order to fix the issue. Now, the quality of the results that we're seeing is pretty outstanding. This is, I think, the latest advances in AI play a big role in it. I think coupled with the wealth of data we have, it makes you very optimistic about what we can accomplish. I've been talking a lot about getting clean, accurate, and rich data. I want to dive in a little bit deeper here. Because of where we sit in observing our customers' critical workflows, we actually receive many types of different types of data, not just metrics, events, traces, and logs. But also, as we expand our platform, as Olivier spoke to, we started to get a lot more data so we can begin to close the loop. Behind the simple example, here's what we have in mind. Obviously, we get this is the core of our observability and security offerings. We measure services, cloud infrastructure, and so on and so forth. That data is obviously produced and processed second by second. On top of that, we get what actions are taken on that infrastructure. This is through processed data, what incidents are currently ongoing, what workflows are executed to resolve issues. We also know how our customers name things. This is surprisingly important. So when a customer says Hogwarts, for instance, in a chat with Bits AI, Bits AI knows that it's not about Harry Potter, but it's about a web service that fronts their building system, for instance. The key insight here is that you cannot derive this kind of insight from public data. It just doesn't exist. It's not in a publicly available training data set. But because of where we sit with our customers, we can understand what they mean when they say Hogwarts. We also know which teams people are on, which services they care about or they're responsible for. That's very important during incident response. We also get a lot of context from our customers' stacks, from their documentation, from their source code, group chat, and so on and so forth. Again, none of that stuff is publicly available. Because of where we sit, we have access. We really want to have the most data and the best data because we want to build the best AI to help our customers. Our rapid pace of innovation means that we can continue to develop more products, capture more data, solve more use cases, more problems for our customers. In short, we have a lot of work ahead of us. Lastly, this slide just to show you that we put our money where our math is. As you can see, we've been investing pretty aggressively in R&D over the past years. We plan to continue to do so going forward. With that, I'd like to turn it to Yrieix. Thanks, Alexis. Hey, everyone. My name is Yrieix Garnier. I've been with Datadog for about 2.5 years. At Datadog, I manage two things. First, the Datadog platform. I'm also managing the Datadog Infrastructure Monitoring business. As Alexis explained, we are investing aggressively to deliver more innovation. The chart you see here actually shows a small subset of the tens of products and, I would say, the thousands of features that were actually delivered on already launched. What I want to do now is actually walk you through how we do that, how the actual Datadog platform and the Datadog product actually bring everything together. First, let me talk about the platform. When we say platform, I'm going to try to define it for you fairly easily. A platform is basically a data store where you store your data, layers when you actually collect that data, and then a visualization layer like dashboard or just being able to expose that data, all of that be able to serve a specific use case or a product. Out of this, there's really nothing specific. It's actually, I would even say, every solution in the market will provide the same kind of capabilities. But the difference at Datadog is that we actually decided to build the platform first, as you heard from Oli. And actually, at the beginning, that was actually seen as a wrong choice. It even made it pretty hard to get the company funded in the first days. At that time, when people were thinking about where to focus, they were thinking about a very thin, vertical slice of a product category as opposed to a broad platform approach. Even though at Datadog, we decided to build that broad approach and then start to build use cases on top of it, like Infrastructure Monitoring. That actually, if we think about it, is actually what I believe laid the groundwork for the success we have in the market. After this, we're starting to build more on top of the platform. We're actually starting to build APM. But to do that, we didn't need to rebuild everything. We actually were able to reuse all the different components that we had already built. We were able to actually just take our platform, our agent, and extend it to be able to support the APM use cases, which actually was a fairly small amount of work. So building on the same platform is a means to an end. It actually helps us to actually build very fast and, I would say, better products. But most importantly, actually, the value we provide to our customer, the fact that we actually build everything on the same unified data platform, allows our customers to seamlessly really navigate between the different products. They're actually able to go from one product to another, in this case, from infra to APM and vice versa, to really solve some of their key issues. This is really how we broke down, I would say, our first silo here. So now, what I'd like to do is actually take you a bit kind of underneath the cover, show you how and what is actually that Datadog platform I've been talking about and how powerful it is. We've been at this for 14 years, as Oli said, not 40, but 14 years. We actually have about half of our engineering team that Alexis just talked about, which actually focused on that platform. We actually move really, really fast. The foundation blocks of the platform are the data and the services. This is really what allows us to share data and connect all the different products together. To put things in perspective, if you think about monitoring one of your servers, we call that a host at Datadog. If you want to monitor that server, that same server will actually show up in APM and in infra because it's coming from the same data foundations. But also, it will also allow you to go and see the logs and the traces for that server disregarding which products you're actually looking at at that moment. We're just putting everything, I would say, a click away from the customer. The second layer is focused on the collections and ingesting the trillions of data points that we get from our customer on an hourly basis. We're calling this our integration and ecosystem layer. And we have about 700 of them. If I take one of them, the unified agent, this is really an ability to deploy once an agent and to be able to collect all the data that are required for all the different products. So from a customer perspective, they just, again, deploy once. And then it supports all their different use cases, which is really powerful for them. So to finish, on top of this chart from the platform perspective are actually the capabilities that customers interact with. I'm talking about features like dashboards, service catalog, or mobile applications, different alerts they wake them up at night. And this is where, I would say, the line blurs between platform and product. At Datadog, we call them and we put them part of our platform because this is really where we want to make sure that we serve all the different products together and provide a very consistent experience from all the different capabilities. But from a customer perspective, they would tell us they are actually product, and I would say very important product for them because that's the product they actually interact on a daily basis. So taking a step back, I would say, from capabilities here and all those building blocks you see here, one of the other key values of that unified platform is the fact that at any time when we actually have our engineers touching or developing one of those components, it actually right away benefits all the different products which are built on top of the platform. And this is really what allows us to move very fast. And it's just not about velocity moving fast. But it's also about improvement and innovation. I'm going to take one example, our event platform. We actually built the next generation of it called Husky. This new event platform is actually running and being way more performant and running more lean on the back end. What it actually allows us to do is provide a game-changing solution to our customer that we call Flex Logs. We actually now be able to decouple our logs compute and our log storage and give that at a cheaper price for our customers. This is thanks to the innovations that were brought by the platform when we built that next-gen event store. I've been talking about platform. Now, I want to talk about the product because Datadog is actually a product-first company. I said half of our engineers work on the platform. The other half work on all those various products. And thanks to the platform, those products are actually those product teams are actually very lean. If I'm taking the example of the Log Management team, this is a $500 million business. It actually only has about 30 engineers working on it. Another example, Cloud Cost Management, CCM. It's solutions for the FinOps personas. If I look at other companies out there, they have, I would say, hundreds of engineers to build that kind of solutions just to build Cloud Cost Management solutions. At Datadog, we were able to do it really quickly with only 10 engineers, again, because we are leveraging all the power of the platform underneath. So I told you earlier about infra, APM, how they are just kind of one click away and how we're breaking silos. Actually, at Datadog, all the products are actually tightly interconnected. And that's, again, thanks to the unified data platform. What we do, we actually pivot the data that we're actually getting. It allows us to build and to solve new problems. Some of them, we didn't even think too much about them when we actually started building observability. But think about that. If you take that data and then start to actually extend it, to enrich, to process it in a different way, build a different UI, a different UX for our customers, this is what allows us to bring a new product. That's exactly what we did with our cloud security solutions that Prashant is going to talk about later, but also what allows us to do when we start to analyze your software delivery. We bring those new products to the market. We've done this for over 25 of them. In addition to bringing everything together, what that also gives us is that ability for all those products, are they actually requiring new use cases and new capabilities to inject all of those back into the platform and being able to serve, again, the rest of the Datadog product? That's really, I would say, the flywheel effect we have between platform and product. I've been talking about that interactions. And this is actually, I would say, a very cultural decision that we made at Datadog. Building that platform first is actually more investment. But that investment allows us to move faster and build better products. But again, more importantly, this is the value we can actually provide to our customer. And if I take an example of that, what I want to do is actually look at that customer here, which is a telco telecom company. That story, I actually heard it from many other customers. It's the story of when they have an incident, what they actually used to do is actually bring all the different teams together, get all the people in the room, start to look at who's responsible for that incident, try to look at, hey, how am I going to go and troubleshoot it? How am I going to go now and fix it? It actually took a lot of time and resources to do it. That customers actually deployed Datadog. They actually saw multiple benefits out of that. The first one was actually to reduce the number of incidents. But even though when they had incidents, now they can actually bring the right team directly into the conversations, being able to troubleshoot and fix that issue way faster. So it actually helped them save thousands of engineering hours and really refocus those engineering hours to what's more valuable for them, really focus on their business. OK. Now, I do have to talk about this, which is the last thing here. It's about AI. Alexis already talked about AI, what we're doing, and how it's really transforming and changing everything that we do. The fact that Datadog is built as a platform is actually what specifically positions us for success in AI. I'm sure you're wondering why. But all of the data that we have in one place is what allows us to actually train those different models, being able, when you actually do inference, to actually have multiple data sources and being able to bring those two together to really have deeper and differentiated value for our customer. Also, we actually inject AI into our platform. Alexis talked about Bits AI earlier. We also had Watchdog AI, which we've been providing for years. And that really once it's into the platform allows us to have every single product to benefit out of this, just like any of the other components of the platform. The last thing I want to talk about around AI is really the experience and the expertise we actually gather while building our own AI solutions. With that experience, what we decided to do is actually package it and productize it into solutions to bring to our customers that we call the LLM Observability. You can see at the top here of the chart. This LLM Observability is really our experience about how observing an AI model and then re-giving that back to our customers for them to actually now observe their own models. If I want to summarize AI, for me, AI actually enables the platform. And the platform enables AI. So now, in closing, as you heard from Oli earlier, this is really how our unified platform and products, I would say, our simple but not simplistic products play into the customer environment and actually deliver value. Our ultimate goal is to collect the data from numerous sources and to provide a single source of truth to break down silos across all users, deployed everywhere, used by everyone. And with that, let me hand it to Michael. All right. Thank you, Yrieix. My name is Michael Whetten, VP of Product over a number of products that we have here, Log Management, Application Performance Monitoring, as well as Digital Experience Monitoring, some other. I've been with Datadog a little over seven years. And it's been an exciting journey because one of the things before I joined Datadog, I had my own company for a little while, a startup. And before that, 15 years or so as a full-stack developer. And so having used the technology and been a consumer and then an engineer at Datadog and then moving into product to try to help figure out what to build next, it's been exciting to see the evolution of the space and how we react to the problems that the market brings. Just to peel back the curtain a little bit, when we were putting this presentation together, there wasn't a ton of coordination about what we wanted to talk about. Instead, everybody went away and kind of came up with their own talk tracks. When we came back together, they were very similar thematically. I think it really speaks to a group that's empathetic to customer problems and curious about the space and where it's all going and transitioning into solved problems for customers. As a product leader at Datadog, we don't say that we're building products. We say we're solving problems for customers. That might translate into products so that we can build a business. But when I was asked to talk about product today, something I wanted to touch on was how do we decide? Since I'm talking to a bunch of investors, how do we decide what to invest in from the product perspective and the problem perspective, what's going to help our customers the most with this rapidly changing environment of technology? And so looking at the graph that Yrieix had just shown, I want to walk us through some of the history of why did we if we built the platform first, which was get all the data in, the metrics and the events, and then figure out what customers need us to build off of that, knowing that no matter what we build, they're going to need a place to store the data. They're going to need a way to query that data, dashboards, and alerting so when they know when things are going wrong with the data and come in and investigate. All of those are the platform that we built first. So why did we start with Infrastructure Monitoring? And then how do we decide the ways that we're going to expand this graph in the future? All right. So let's dig into Infrastructure Monitoring. After we get the platform going, a lot of us started as engineers or developers. So we had some sense of what was the most important place to start. But talking with customers, especially with the advent of the cloud and all the complexity that that brings with the innovation that's happening in applications and digital experience is becoming more and more critical to our lives in every aspect of our lives, whether it be health care or entertainment or communication, more and more we're reliant on technology in our lives. And so where do you start with solving these problems? Because there's lots of them. And what became apparent is that you start with the operations team because as this complexity began to spiral out of control, it was these people who were in the most pain. Even if they're not the people, they're not the designers, they're not the product managers, they're not the developers who are creating what the user experience is going to be, ironically, they're the closest to your user experience in real time. So if you are watching the Super Bowl on your phone or looking at a trading app or making a telephone call on your cell phone, it's these people who are connected to you on the other side because they're the ones who are bringing you and operating that experience in real time. And if you're having a bad experience or it's not working, it's these people who are being woken up. So it was the obvious place to start. And so when you're having those bad experiences, you can say a little prayer for these people because you know on the other side of it, they're the ones who are getting woken up and trying to fix it for you. Now, what did they care about the most was diagnostic information. So rather than going all in on event-based, we started with metrics and time series, heartbeats, blood pressure in the medical field, but in the operational space, it's CPU and it's disk space and things like that, throughput. And these are the diagnostic information that we really need to solve at scale. And so the first part is that they're the closest to the actual real-time customer experience. And that's why we started there. The other part is they're the ones who were experiencing that explosion in complexity the fastest. So when we started with Datadog, and this only goes back five years, but in the very beginning when we had the advent of the cloud, the adoption of the cloud meant that innovation was rapidly changing what people could think about, what they could imagine bringing to us as a consumer experience. But that also meant an amazing amount of scale and innovation in information technology and how operations teams needed to provide this experience to you. So we could think about orchestration with Kubernetes into containerized environments or extremely elastic and ephemeral serverless functions, on-demand experiences. And so this need of this job that these people do of operating the infrastructure and the scaling complexity made it a bit of a no-brainer. I hope. I wasn't there. It was just Ollie and Alexis. But I assume that this is what was driving a lot of this decision-making in the beginning. Now, it's only part of the story. Each of those nodes on that graph I showed a little bit earlier really is somebody's job at a company. And the edges that connect those nodes, you can think of as workflows and conversations that have to happen across a company. When these people get paged and woken up, the first thing that they ask is, well, what's running on these servers? What's running on these containers? What went wrong? Who's responsible? Because even that's the irony. Even though these people are closest to you and your user experience, they're sometimes furthest away from the business context and the changes that are happening to the applications that we're consuming. What they needed was the application insight. What they actually needed was to know who to bring into the conversation next to fix the problems. We're starting to build a loop here. They're observing that something's going wrong. Now they need to orient themselves into what the impact is and who can help them fix it. So application developers get pulled in and say, hey, CPU is escalating on this service, on the hosts that are hosting this service. Who's responsible? Was this an intentional code fix that you pushed? Was it an accident? Are we under attack? Who can we get into the conversation to fix this as soon as possible? And this branching out from job to conversation to job, person to person across a company, it continues to pull us into how the organization is trying to run their digital business. So SREs pulled developers into the conversation and then pulled us into that conversation too. And then both of them said, well, to continue to do our jobs together, we need to collaborate around logs. So we pulled logs in and built a Log Management solution. So this isn't like us strategizing if this is where the money is, this is what's going to happen next. It's us trying to solve problems for customers. As mundane or cliché as that sounds, it's the truth. But the beauty of it is, as we solve complexities, each of these gets more sophisticated, solves more problems. It continues to bring interest from the rest of the company. So as soon as we built logs, who do you think came in and said, well, we use logs a ton. And it's really hard for us right now. We're very siloed. It was the security teams. And Prashant will talk about that in a little bit. But the beauty of building the platform first meant that we could pivot quickly and experiment with customers on the problems that they were having with new technologies, with new use cases very rapidly. The proof is in the pudding a little bit. Building out Log Management, just everybody starts congregating around these logs and saying, well, actually, we have logs that we were never querying before. But now that they're here, we can just bring them in and see it next to the infrastructure, see it next to the Application Performance Monitoring, and start collaborating in real time on solutions. So I want to walk you through how this continues to actually pull us into places that we didn't even foresee. That would be user behavior, user experience, business impact, support crews. More and more, we're getting pulled into the broader parts of the organization because this digital transformation is driving organizational transformation in which more and more of the company does care about that mobile app experience because it becomes more load-bearing for the entire business. Here we're looking at a mobile application. It's a web store, e-commerce site. There's a checkout and errors escalating on the checkout at this top middle view here. Now, this might not impact user experience at all. It might be normal operating procedure. For whatever reason, in traditional tools, you don't know because everything's siloed off. Engineers would only have their context. What would happen next is they have to go and find who to talk to in a company to say, hey, I'm seeing some errors on the mobile application. Is that impacting user experience? How serious is this? Within Datadog, we can jump right into how is this impacting end users and see an aggregate drop-off at the checkout. Now, again, is this the normal drop-off at checkout? Do we normally lose 55% of people? We don't have enough information yet. But with Datadog, we can see that this is an anomalous behavior and that as the errors start to spike, we see these two time series up here. We have a view loading time for the checkout page is directly correlated to drop-offs. So now we can see user impact actually is the user experience actually is impacted. And it's impacting the business as well. So an engineer can start to have that conversation and start to make judgment calls about how serious this is. Hey, this is a serious incident. We need to open up and get more people into this versus, oh, I'll just fix this when I get back from lunch. Now, from here, we could actually jump into and broaden the conversation and broaden the amount of people we're bringing into the conversation to look at actual recordings of a single user's experience who's having this problem. So we can come in and say, oh, OK, in aggregate, we see people dropping off. But is it a weird thing that they're doing? Did somebody introduce a new design element that's driving them down a new path? Or is it buggy code? Let's actually watch what users are doing in real time and see what they're doing so that we can figure out how to fix it more quickly. And this works in reverse too. You could get somebody tweeting out, hey, this website's broken. And then we react to it and go in and say, is it broken just for them? Or is it broken for a lot of people? Again, figuring out how to invest our internal resources in this critical time. Do we call an incident? Do we bring in the whole company to try to fix this? Or is this an isolated event? We just need to schedule work. This kind of interconnectedness of the products is very popular with our customer base. They want to work together. They want to cut down on the unnecessary conversations, on the unnecessary context hopping, and work as a single unit to coordinate work and to solve problems. I think here we see that the trends, as we introduce new products that the customers ask us for to continue connecting the rest of the business, you see that they continue to grow in adoption. Every new product we add, there's a lot of excitement as long as it continues to reflect how the business works and they're connected together. That's the power of the platform first. Just by nature of building on the platform, all of those capabilities tend to be connected. And we were just looking at an APM and Digital Experience Monitoring. But this is the philosophy as we build out in all of these spaces. How do we connect things together? How do we break down communication silos? How do we break down technical silos across the company? So I'm going to end here with an example of what's happening now. As I talked through a lot of these incident triaging, decision-making, coordinating work use cases, this is a food and beverage company, 150-year-old company, global company, tens of thousands of employees who've been with us for about five years. They landed with 3 products, maybe 4. If I squint, I can't really tell. But probably Infrastructure Monitoring at APM. As they've grown with us and as they've started to move into the cloud and undergo their cloud transformation and their digital transformation, they've adopted a lot more products. In fact, the CTO of this company, when I was sitting with him about 2 months ago, he told me that 18 years ago, he started with this company. And the technical footprint of the company was in the basement. And it was corporate IT. And that's what he was over. He'd never met the CEO, never been to a board meeting, anything like that. Now he's the CTO of the company, fast forward, with a charter from the board to grow the company through technology. And so we see how digital transformation is forcing organizational transformation. And they're adopting Datadog. But for a company this size, he wants it to be more reflective of their cloud migration, which is about this size. They're still very early in their migration and in their digital transformation. And one of the things that he told me is the reason that they're stuck is because of the organization, the people, and the policies that have grown up over many, many decades. And so right now, Datadog does a really good job for him, he says, on the technology observability. He said, but coordinating work, organizational observability, organizational governance, and getting everybody working in the same way, in a safe way to move this business into the cloud and into the modern era is incredibly difficult with the tools they have right now. And of course, they already have service management tooling like ticketing and service desks and all these things. But they're not built for the innovations they're trying to make now. They're not built for the cloud and the modern things that they're trying to do. So this is what he's been asking us to work with them on, is how to audit, enforce, alert, and remediate as they move from their existing solutions into a more modern stack. So we've been talking about closing the loop. And this is the loop that I hinted at. And this is what we're talking about, is you have these technical systems, these technology systems. How do you observe their state? And if something becomes symptomatic or problematic, how do you orient your teams to make decisions, to take action, to try to get it back into a healthy state? Then how do you make sure that the actions you took and the decisions you made were correct and you didn't make things worse? Because that happens. This is closing the loop. This is taking action closest to the place where you're observing the outcomes of your action as possible. This is a big investment for us both last year and this year: moving into Cloud Service Management. Cloud Service Manageme nt, as Olivier had hinted, is about bringing your people and your processes, your organizational context, into Datadog so that you can use Datadog to run the technical part of your business. Here, I'm going to talk through four parts here of what it means. You see, we have over 700 integrations, adding more all the time. We're collecting all of that rich, clean data that everybody's been talking about up till now. Bringing in all of that data, change events, telemetry, along with the organizational awareness that was spoken of, like teams and service names that only your organization has, bringing all of that together gives Datadog a great opportunity here to add intelligence and take all of this signal and output human-consumable stories so that if I get paged, I can try to figure out what to do and who to bring in over here on the right. So this is what we call event management AI Ops. And what this is, is saying, all right, all of this stuff is happening in real time and historically. How can I understand that at 3:00 P.M., so-and-so, Billy made a code change? At 8:00 P.M., Sally made a configuration change. At 12:00 A.M., somebody in the East Coast ended up sending an email blast that wasn't communicated to anybody else that linked to these systems. And then it became very popular, went viral. And all of a sudden, we're also seeing an elevation in throughput. We're seeing systems start to crash. This is a story that none of these individual data points can tell, but that we need to aggregate into a story so that when I do get paged, I have a story in front of me. And I say, OK, this is what's happening with everything related to my services. I know who to bring in. I know who to talk to so that we can figure out what actions to take. Do I need to call an incident, bring everybody into a room, open a CoScreen, work through the problems together to bring the state of the organization back into a healthy state? Or do I schedule? Is this not so severe? I just need to schedule a follow-up. Hey, why did you do this? Or hey, this needs to be upscaled. Or is it something that we can actually automate already? So we do have customers right now who have workflows automations that if they get paged, they open up the Datadog app while still in bed, scroll through, see the context, say, oh, I've already got a workflow automation for this. Click it. It goes and upscales or does whatever they need, a rollback of a code change. Straight from that same app that they triggered that workflow from, they can observe that the system went back into a healthy state, go back to bed. We're not too far away from a lot of these known knowns being something that doesn't even have to wake you up. You can show up the next day and just see a report. Hey, at 3:00 A.M., the system went into a degraded state. We recognized already what you wanted to do because you had runbooks and workflows already set up. We went ahead and engaged them. We monitored that it was fine. Everything went back to green. We didn't page you. Here's your report. That's not too far away from what we're already doing. This is closing the loop, being able to observe, bring in the right people to make the decisions, take action, and make sure your changes were the right ones to get your company back into a healthy state. With that, I want to turn the time over to Prashant, who's going to talk a little bit more about how we're getting pulled into more and more security conversations and solving problems for those teams and how they relate to the products we've already built. Thank you. Thanks, Michael. And hi, everyone. My name is Prashant. I lead product management for parts of our cloud security portfolio. I've been at Datadog for about two years now. I want to start by recapping what you heard from our product leaders earlier. Yrieix talked a little bit about how our platform powers our products and how new products, in turn, make our platform better, spinning that sort of virtuous flywheel. And Michael just talked to you about innovations like Cloud Cost Management that allow customers to close the loop and take action, all within Datadog, for operational issues. Now, they just articulated why we are in the security business. It turns out you need a platform to correlate security signals coming from different sources and to root cause what happened. And much like operational issues, you need to take action on them. Datadog's cloud security solutions enable you, developers, operators, and security teams to collaborate and take action against a threat or vulnerability as quickly as possible, all within Datadog. All of this just keeps getting better as our platforms keep improving. We have new innovations in service management, like closing the loop. I want to maybe mention an anecdote that stuck with me for a while. A CISO of a 3,000-person high-tech company told me that the first thing they did during a security incident was page in the Datadog user because this person had information that would help the security team actually triage the threat they were trying to face. Now, this happened enough times that this CISO said they had to codify it in their runbooks. So their runbooks, the first step, was to actually page in the Datadog user. He said to me, they didn't want to be in a battle without the right weapons. And this is not an isolated anecdote. So this is why we are actually in the cloud security business. Now, what does it really mean to secure cloud-native applications? Let's break down what we're doing into two sections. The first part is the application. And the second is people who we want to enable to secure them, which, as you've heard, is often the harder part than building world-class products. So cloud-native applications, as you can see here, are made up of application code, infrastructure code, these are all code in the cloud. And they both generate logs and metrics. These applications are sometimes called microservices. You hear that a lot with the cloud. And microservices talk to each other. Now, a product or a service that was once a monolith now consists of several, sometimes hundreds, of microservices. Think of it as an order fulfillment app that talks to a shopping cart app to get information about the number of orders, who they need to ship it to, and then gives that information to an order fulfillment associate. Now, this is all programs talking to each other. So securing these things means providing high-performance communication across these different microservices that continue to talk to each other, yet recognizing malicious actors. This could be people. It could be programs. It could be bots. And you have to stop this malicious activity. And obviously, these can be really, really hard to detect at scale when you have a lot of these services talking to each other. So that's one problem. Layer in the second problem, people. Developers deploy their code multiple times a day. There's a huge amount of code that goes into the application, sometimes code that developers didn't even write because they're using large language models to generate code, open-source libraries, continuous integration tools. All of these get packaged up together and get deployed as part of the application. Security products need to make sure that developers are not unintentionally deploying code that leaves some backdoor open and makes them vulnerable to attacks. Now, operators are ops teams. They triage and resolve ops issues in their tech stack in real time. Now, security products need to enable these operators to help root cause security incidents the same way they do ops incidents, using the example I mentioned earlier. Now, security teams, they're often the smallest teams. There are very few of them relative to the large population of dev and ops teams, if they exist. They're chartered to prevent and resolve these security issues. Now, they need the same level of visibility that the dev teams have and the ops teams have to root cause issues. Any security product they use has to, by definition, amplify what those teams do. In order to secure an application native to the cloud, you need a unified platform that becomes that single pane of glass that brings application, infrastructure, logs, and all of these components together. You need to enable developers, operators, and security teams to collaborate towards a DevSecOps model. That's not really how it works. In the real world, dev, ops, and security teams are siloed. They have data and point products that give them information about their own world. They have shared use cases they want to collaborate on. The shared use cases are identifying a security issue, prioritizing what needs to be fixed, and then actually fixing that issue. Now, depending on the company you work at, this could be the job of the security team. In some cases, this is a shared responsibility between security and ops teams. Sometimes, developers do all three of them together. A lot of this is cultural and often manual, based on the tools that they use. This is the problem we wanted to fix. We'll come back to this slide later. Keep this in mind. How is Datadog able to address the problem of securing the cloud-native application stack? Now, first, with the application layer, which, again, if you're paying attention, it was the code written by developers. Now, these are packaged with libraries and so on. So our Application Security Management products, or set of products, helps identify active attacks from malicious code and malicious actors and discovers vulnerabilities in this code. So we enable something called threat detection on these products, which means that we know when someone's trying to attack it through the front door. We also have the ability to do Software Composition Analysis, which we launched a few days ago, that helps developers detect vulnerabilities in their code before they get deployed in production. And they can pinpoint exactly which part of their code is getting deployed in production. We're also working on things like API security and code security in this area. The thing to remember about this is, like you heard earlier, we are all building this based on our existing products and existing platforms. These are built on top of APM, our CI Visibility product, and some of our platform capabilities. This information is actually available to all developers using Datadog. This is not exclusive to a specific group. We're trying to enable every part of the organization to start using this. Moving on to the infrastructure layer, we're securing the infrastructure layer with our Cloud Security Management product. Now, with this product, we're able to identify misconfigurations in production through what the Cloud Security Posture Management, or CSPM, is in this slide. We help determine vulnerabilities within your code through the Vulnerability Management for containers and hosts. We also help customers find overly permissioned users, people who have administrative privileges when they don't use it, through our Identity Risk Management product. Now, these are products that help you identify risks, or someone leaving, for example, the backdoor open or the window open in your house. But if bad actors get in, we have something called the workload protection product that will help you identify that bad actor through malicious file activity, process activity, or network activity. And that's part of our CWPP product. And we are also working on things like securing customers' data within their accounts through data security and also scanning infrastructure as code in the cloud. Again, you should expect all of these products are built on existing Datadog capabilities between our products and our platforms, again, the thesis being these keep getting better as Urix and team improve their products and their platforms. And of course, the teams that are building these products also constantly improve. Also, as you should expect, all of these products are available not just to the security teams, but to the developers and the ops teams that use Datadog. Now, as you know, applications, infrastructure, and other constellations generate logs, metrics, notifications. With our Cloud SIEM product, customers can connect logs and other data with detections and threat patterns that our security research team has identified. So they get alerted about this. Now, with something called content packs, which is part of our Cloud SIEM product, you're able to decide which third-party vendor, supposing you're a customer who uses Okta for identity or uses Microsoft 365, you can decide which part of that content you want to be able to send to Datadog. Then our security team takes that content and writes detection rules that allow it to mix it with the data that they already have and detect threats. We allow teams to detect malicious users, user behavior that perhaps associates it with a risk score. We're working on that through what is called User and Entity Behavior Analytics, or UEBA. One thing you'll notice is security people love acronyms. So we're trying to catch everyone up. As you should expect, this product is also built on our existing Log Management capability and other platform improvements, like workflow automation that Michael talked about, that help us actually take action on those detections. Again, this is available to the entire team. Zooming out a little bit, our cloud security products cover the entire cloud-native application stack. We will continue to build that coverage over time. But we also leverage Datadog's platform. These products can be enabled with just a few clicks from best-of-breed observability products. That's what our customers do. For a customer, it's really simple to go from dev and ops to DevSecOps through this. But we're making it even simpler. Recently, we announced that the new DevSecOps SKUs, based on what customers are telling us, we integrated the Infrastructure Monitoring product or the Infrastructure Monitoring SKUs along with our Cloud Security Management SKUs to create the Infrastructure DevSecOps SKUs. Similarly, we integrated the APM SKUs along with the Application Security Management SKUs to create the APM DevSecOps SKUs. Now, these are more than just SKUs that go-to-market teams can sell. Let me explain what it is a little bit further. There is a pattern of emerging needs. You've probably picked up on that based on the examples I just described across our customer base, where they're telling us, hey, I need security information because that's popping up in my day-to-day. To Michael's point, we are here to solve problems. This is a problem our customers had. This is new to the DevOps persona. Customers wanted us to go down this path. But they needed somewhere to start. These SKUs help with that. Second, it has reduced deal complexity for our go-to-market teams. There's one transaction for those customers interested in implementing this, rather than a two-step process with a time lag. Lastly, our Datadog champions, the users of Datadog, have actually introduced us to security teams. Security leaders appreciate the benefits of a unified platform and the rapid time to security outcomes, not just detections, where security becomes everybody's responsibility, not just that small, siloed team. With DevSecOps, we allow our leaders to consolidate their platform, get immediate adoption for their product, and help from those who actually fix the security issues while reducing our own internal go-to-market complexity. If you remember this slide I showed you earlier, now that you're well-informed about how to secure cloud-native applications, you can see that the three products we talked about that are part of our portfolio help dev, ops, and security users actually secure the entire stack end-to-end. These products also remove silos between these teams because of our shared platform. We're not stopping there. The first thing we're doing in addition to that is going from being a product, like any other security product, that gives you high-quality outcomes for those customers, so closing the loop through service management. As an example, with our SCA product and many others coming, we're actually helping developers fix and prevent these issues from becoming security issues in the first place. You're able to detect what's going to happen before you check that bad code in. That's also part of what we're doing with the DevSecOps approach. The truth is in the numbers. We have 6,000+ customers actually using one or more of our security products today. Why do they choose us? The first one is we have the people. Now, our DevOps users are in the Datadog platform every day. That's their principal way in which they understand the systems they operate. They help work to identify security issues. No other security product can claim to get instant adoption from such a large population with no friction, especially those who actually fix these issues. Second, you've heard about this. We have the platform, which means our products provide deep context, higher efficacy, and low time to value with zero performance costs and no additional cost overhead to transfer data over. And this actually is a big friction point between teams when they try to install agents for different teams between the different organizations involved. Finally, we operationalize security. I cannot tell you how many security products exist that are very expensive, that just become shelfware. We're trying to show customers that you can go from detections to outcomes for security through operationalizing it with service management that you heard about. Now, even with those number of customers, we are very, very early in our journey. This slide shows you we have a healthy penetration of our security products within our observability pillars. But we have much, much farther to go, as you can see. That's all I had to share today. So now, let me hand it back to Yuka for Q&A. Thank you. All right. Thank you very much, Prashant. OK, we're going to start a Q&A session now. Joining me on stage are all the presenters you just saw. Their names are up on the screen there. We're going to be taking questions from the in-person audience. So I'm going to ask you to raise your hands to ask a question. I have two of my colleagues, Megan on the left side, stage left, David on the right. And just please wait for them to get to you before you ask your question, so we can all hear it. All right, let's start on Megan's side. Patrick Colville from Scotiabank, thank you so much for doing this. This is terrific. I want to ask, I guess, the most topical question, which is Gen AI. You guys all touched on it. So thank you for that. I guess the question is, when does it hit the financial model? And how will we see that? And then the second part of the question is the Bits AI kind of copilot. Is that a paid product? Or does that come as part of the platform for customers? Thank you. Thank you. So maybe I'll take this one. So look, AI is already hitting the revenue line. So we said on the call about 3% of ARR comes from companies we identified as being specifically AI native. And that's only a small fraction of what we think is related to AI revenue today. The rest might be a little bit more difficult to identify, because we don't always know when we see a workflow, whether it's related to an AI pipeline or not. We think this is just a look into what the future is going to bring to us, because we know from our own experience and from working with all of our customers that, by and large, AI applications are not in production yet. Mostly, they're still being tested. They're still being provided as early betas to customers. So we know that the vast majority of the usage hasn't happened yet. That's on the consumption side, on the customers building on AI and our own customers being AI providers. We expect to see a lot of growth there. I mentioned earlier in my presentation also, but we do expect AI to be a further driver of cloud migration and digital transformation for all of the obvious reasons. You can't pump your data into an AI model if it's not digital to start with. And I don't know how you would even start about adopting AI in an on-prem data center today. I think there's too many choices and too many hypotheticals. You absolutely have to be in the cloud for doing that. In terms of our own products, we haven't decided yet how we're going to package all of our functionality. Some of our products are more directly tied to AI. So everything that has to do with Cloud Service Management, for example, has a notion of automation, a notion in some cases of acting as an agent on behalf of the user. So that will have a packaging that will be more tied to this AI functionality. Some of the other pieces of functionality we provide today, such as Bits AI, right now, they are part of the platform. But that might change over time as we provide more value and as we and I would say the rest of the world coalesces on the right model. If you look at what's happening in the industry today, there are some areas where it's pretty clear that there is a clear productization, for example, code writing copilots. There are some other areas where the jury is still out when it comes to, for example, business productivity and things like that. I think the jury is still out on whether or not the way to package those agents or copilots is what we see today is what we're going to see in the future. OK, great. David? Hi, Adam Tindle, Raymond James. Olivier, obviously, the long-term vision on closing the loop has been a key part of your presentation today and taking action. I want to ask you about that taking action function. As we think about that, we can't help but think about security players, like on the endpoint taking action, CrowdStrike, for example, or on the network taking action, like a Palo Alto. So how do you evaluate if it's the observability player or security player being the one to take action? Where do you draw the lines? And then what do you need to maybe enhance your value proposition for that, the puts and takes to considering a larger acquisition to accelerate that vision, for example? Yeah, so we kind of always wanted to get there. When we started the company, the goal was not just to present information to people, but really to help them resolve faster and, if possible, resolve issues for them. The dream is really, instead of Datadog waking you up at 3:00 A.M. and having you fix your system, you wake up at a normal time in the morning, and you get a message from Datadog saying that it fixed the issue for you. That's a much better future. When we started the company, though, it was pretty clear that trying to take action from a SaaS application was one bridge too far for customers. We were still at a stage where we had to get customers to trust sending their data out to a SaaS system and then observing through that window. I think we're way past that today. I think today, customers are embracing automation. They are embracing cloud. They are embracing SaaS in the way that they were not 10 years ago. We also have a footprint with our customers, really, that gives us all of the necessary data to drive some of that automation. Now, thinking between security and observability, interestingly enough, this step towards automation is even easier to cross for security teams than it is for observability teams. Of course, observability, the pain is huge. If you get woken up, as I said earlier, nobody likes that. If you incur downtime because it takes you 20-30 minutes to figure out what's going on and to fix it, that's obviously business pain. But there's still fear that if the machine tries to automate and automates the wrong thing, it might make things worse. And so the cost-benefit equation is still a little bit less clear on that side. On the security side, though, the risk of letting a bad actor into a system is so much higher than the risk of maybe disrupting operations a little bit to prevent that from happening, that the teams are much more willing to move with automation much faster. And so in everything we do today, you see more automation faster on the security side than you see in observability. But it's very clear to us that it's going to come to the observability as well. OK, great. Thank you. Megan, next question. Hey, Matt Martino from Goldman Sachs. Thank you guys for taking the time today. You guys spent a good amount of time today discussing the advantages of Datadog's platform-first approach, which I think it came across abundantly clear. So I would just love to hear from the panel your perspective on how you think about the trade-offs between Datadog's platform orientation versus best-of-breed point solutions that may be a bit more narrow in scope and focus as you kind of expand out. Thank you. Yeah, I mean, maybe I'll take that. Yeah. So I think, as Yrieix presented, early on, it was a clear disadvantage for us, because we moved slower. We had a blunter approach to solving problems. But as we started to add products, that's where, I think, the value was realized, because the reality is our customers, they don't have an APM problem or a logs problem or a RUM problem. They have a problem, which happens to be, sometimes can be solved through different lenses, through different tools. But to us, at least, we see, and to them, that's what they tell us, is that building all the products on top of a platform means that we're not attached. We're not really attached to, well, there's only one way to solve it. It is through what we do. And we see that as a huge problem. If you get too caught up in being effectively falling in love with your solution, you're not necessarily providing the best tool. You're just providing what you have. And so it's been, for us, I think, a strong advantage to have really a wide spectrum of tools that can solve the problems that customers have. Internally, also, the way we structure, we don't really care. It's not like, oh, we have to—these gentlemen may disagree with me. But fundamentally, what matters is the success of Datadog, not the success of Datadog's or Infrastructure Monitoring or security and so on. So that's, I think, how we've been able to turn a disadvantage early on into a real advantage. You've seen that in some of the chats we shared today. When you look at the evolution of consumption from customers over time, you see that there's some ebb and flow between the various products and the mix changes over time. That's because some problems customers can solve with a variety of different products. We don't really care if they solve such a problem with our infrastructure product or APM product or log product or a combination of all of the above. That's really powerful. I will say, in general, very thin slices of products or point solutions or best-of-breed, it's a shortcut. It goes faster in the beginning. You can land customers very quickly this way. You can have great focus. The end state is not nearly as good as having a unified platform with broad coverage. Our customers understand that. So it might mean, in some situation, we might go a little bit slower initially. So, for example, when we were building up a very broad suite on the security side, in every single one of the categories we're going after, you probably can find an independent company that's growing faster in that very specific little bit of things they're doing. We do think that the combined platform, though, ends up being an unstoppable juggernaut when everything comes together. And that's what we're building out. Maybe it speaks to the way we've been educated. But the shortcut is not good. We have to do the hard work and develop everything the right way. And it will pay out later. Great. David? I had two questions. I'll start with probably the simpler one first. In sort of the Cloud Service Management vision, does the capabilities presume allowing humans to enter tickets? Are you assuming a digital, virtual infrastructure sort of end-to-end in terms of your broader cloud security vision? Maybe I'll start with that first, and then I had a follow-up. OK, yeah, I can take this one. That's OK. So, of course, human interaction is critical to all the things we build, because we're building things primarily for people to use. And so a ticketing solution where you couldn't add a ticket would be wild, right? But there's a lot of cases already where our system can automatically generate tickets for you and correlate a lot of the work and give you a lot of context and summary in that ticket when it's generated, as well as augmenting human-created tickets. So you might create a ticket and put in some context about services and things like that. And we can actually find more information and augment certain tickets and correlate alerts or ongoing incidents. Maybe four incidents got opened at the same time. Aggregate those into a single ticket. I think the answer to that is that there's room for both in work management. Understood. And then I guess the broader question is, I think when I think of Datadog, I think of Datadog as a company that was the play on DevOps. I mean, you brought those developers and operations teams together on the same set of data. As we think about bringing the security team on the same set of data, I understand the complexity argument. But what about just some of the how do you what's going to be the catalyst to break through the organizational change, a more sophisticated buyer? These security buyers have dealt with vendors for, in some cases, decades. Other players are building sort of single-agent architectures that get data from endpoints and stuff to do that threat detection and cross-correlation analysis. So if it just maybe addressed some of the obstacles that are ahead of the company to enable to execute against that security analytics vision. I can start. So I think the simplest answer to this is based on real need. I mean, despite having traditional buyers and buying processes for security, you're still seeing a bunch of breaches from the same companies where they're using point solutions for specific products. And what CISOs have realized is their strength in numbers, having more people look at the same data and react to security solutions. Rhetorical question is, if you have a security issue that you're confident about, would you rather have a small team of five security engineers know about it, or would you rather have the developers and operators who are close to that action know about it? The answer should be both. And that's really where that's been driving a lot of the customers that we're talking to. It depends on the maturity of the organization. But it's certainly heading in that direction. At the end of the day, whoever the buyer is, the buyer is rational. They're driving for a certain outcome. Our whole plan is what we're building across observability and security with the platform approach and the very broad approach we've talked about today is that a few years down the road, it should be irrational not to use what we have. That's what's going to solve the problems for us in the end. That's been our approach all along. By the way, you said our product is definitely built for humans. One of us on stage is not a human you have. Can you tell which one? All right, great. Brent? Thanks for having us. It's Brent Thill, Jefferies. You mentioned Husky a few times. We've been all reading about it but probably don't know enough about it. What does it mean? Is it transformative? What does this mean for AI? Can you just further expand on Husky and how important this is? Yeah, I'll take that one. I mean, Husky is the platform that supports all incoming events into Datadog. And so that covers logs, real user sessions, security events. It's a data store we built because we, I would say, 3, 4 years ago, maybe more, we ran to the limit of what we had built before or what we had used before. And so for us, we decided to rebuild, to reconceive, if you will, the solution and say, well, we need really what's a security event, what's a log in a Log Management, maybe what's a trace in an APM. At the end of the day, we can distill it into a simpler structure and build a system that will scale really cheaply to handle all kinds of different data and can do correlation between all kinds of different data. So that's really what Husky is. It's, for us, a way to be able to scale the amount of data we receive at a cost that's quite interesting. And also just to add to that, because also some flexibility on use cases we can address, because when you decouple storage from your compute layer, it means that you have more flexibility on both to be innovative or creative, depending on what your customers bring you for use cases, so more point solutions in some cases for some tracks of products versus others. Great. David? Hi, it's Keith Bachman from Bank of Montreal. Thank you. I wanted to go back to Cloud Service Management, if I could, and hear a little bit about more. Where are you winning the workloads, and why are you winning? And I guess, if I think longer term, what do you see as the source of your sustainable competitive advantage? And if I back into that, obviously, ServiceNow was coming at it from the workflow perspective as an example and then sort of toe in the water on the observability, not fully there yet. But how do you see these dynamics changing or creating the opportunity for Datadog? Thank you. Yeah, you know what drives success there? I mean, first of all, we're not looking at it specifically from a competitive situation, or we're not looking at, OK, maybe let's disrupt that specific part of the market. We're looking at it from a customer need perspective, which is they have all this continuum of problems. And that's what they tell us. And so how can we solve that for them? And it might look very different five years from now than what the categories that were created five or 10 years ago look like today. Why we think we can play a big role there is that when we look at what our customers do on their production applications in cloud environments, is that they usually start dealing with the issues in Datadog. Then they spend most of their time investigating in Datadog. Then they capture what they're doing to address them in Datadog. So basically, their whole life is spent inside of our product from end to end. So we think that if we provide the missing glue as part of that to drive process, to implement process, to maybe automate process, it's very natural for that to live inside of our product. And so that's what we're expanding there. Obviously, we're still very early. I mean, these are products that are barely out the door for the most part. And there's so much more we want to build there. But we really see that there's a very large opportunity in front of us there. I don't know if you want to add anything more. I mean, something that you were saying yesterday is that it doesn't have to be this or that, right? We have integrations with ServiceNow. We have integrations with Jira. We have integrations with other types of workflow automations and work management tooling. Because the key here is that customers are still migrating to the cloud. And so we have to exist in the ecosystems where they exist, right? And so it's all part of that same solution. How can we bring all those signals in and still help them do their jobs for the new technology that they're innovating in? And that's a very good point. We're not trying to replace everything our customers use to collaborate. That's one thing we've learned, is that collaboration happens where it happens. Our role is to seamlessly plug into all of that. So maybe a lot of it's going to be on Slack or on Microsoft Teams. And that's fine. We're absolutely not going to replace that. But we need to be plugged everywhere in there. Same thing for scheduling work. Maybe it happens in Jira. Maybe it happens in ServiceNow. Maybe it happens somewhere else. And we also need our case management to integrate and then service management to integrate very tightly with that. The last part on that is somebody had asked, who do we see adopting some of these things? Well, it's very much DevOps and DevSecOps. They have different names for everything, both developers and security people. But when you break it down, it's a lot of synonyms. They tend to still want to use the same tooling. All right. Megan? Good afternoon. Thanks for hosting us. Joel Amino here on behalf of Fatima Boolani from Citi. Just a question on engineering efficiency. It was really great to hear some of the examples you gave on the engineers and product development. More curious in what this might look like going forward. From a technological perspective, how much opportunity do you see in terms of driving efficiency in this platform, maybe even having fewer engineers to build those new products? Maybe AI is part of this. You can certainly talk about that. Then also, is there a multiplier effect where, as you're adding products to this platform, you're driving even further efficiency? Yeah, thank you. OK, and by that, you mean internal efficiency? Yes, yes, internal. OK, I mean, I think we obviously, I think recently we've been budgeting and figuring out what the next year is and how we think about growing headcount and stuff like that. I hope that what's been obvious through the presentation is the magnitude of the opportunity. That translates directly with the amount of work we have to do. So I think we're not seeing engineering as sort of a zero-sum game, like, well, we're going to try to optimize. We're not at that stage at all. We're at the stage like, can we do more? So there's a clear question. There's a number of, I think, efficiencies, Copilots, and so on, where you think about, can an engineer produce, for instance, more code? Can we accelerate the go-to-market in terms of the time it takes to time to market for features? But we're not at all in that mindset, mostly because there is so much to do that it's really if we can save some time on a particular task or in a particular area, well, there'll be probably 15 waiting to be done. And so that's at least the mindset we operate in. And I'll go further. This is our advantage. We built to this day a very efficient business where we can generate some attractive margins, as you've seen in the last earnings, while reinvesting, say, about 30% of our revenue in R&D. And we see that as the way we're pulling away from everybody in the competition. There's such a great space of opportunity in front of us that our ability to keep investing that much and be as efficient as we can be with that engineering spend is what helps us pull away from the pack. So we'll keep doing that, at least for the foreseeable future. And maybe just to add a perspective: being here just 2.5 years, what I've seen at Datadog is actually there's no real technical depth. This is really where we invest into all the different areas. We invest as much in the platform that we invest on the product. There is no one tracking the other. So that's actually very interesting to see that dynamic and how both really feed each other. And for us, I think the job for us on the product side is really to make those right priorities, making sure that, hey, sometimes we need to prioritize, I would say, shorter term than longer term. But we really do balance both, I think, pretty efficiently. Yeah, and as a closing, it's usually a surprise when we hire new leaders, especially on the engineering side, when they see that we spend about half of our engineering investment on the platform. Everybody's a little bit surprised. But again, as we've talked quite a bit about that today, I think this is how we derive long-term advantage. And we're very happy we're doing that this way. David? Thank you to the whole entire Datadog management team for hosting us. This is Yi Fu Lee with Cantor Fitzgerald. So my question revolves around event management and AI Ops. I really like the vision that you want to fix a client issue while they are sleeping at night. But I was wondering, does Datadog eventually have the capability to fully fix the issues? Or do you need to integrate with other security partners, like vulnerability management? Or do you partner up internally with Prashant's division, Cloud Security, to do the work on that? Well, I mean, historically, we've always integrated with everything else our customers were using. We'll keep doing that. We certainly won't do absolutely everything from end to end for everyone. That's why we have 700 integrations. These are all things we don't do. Otherwise, we wouldn't integrate with them. I think our job, though, is to make sure that we get customers towards solving the end-to-end problem. As long as they get the outcome, we don't care whether we have to do 100% of it ourselves, 95% of it ourselves, 80% of it ourselves, as long as we solve it. Great. All right, Megan? Hi, this is Arti from JP Morgan on behalf of Mark Murphy. I want to ask about your Cloud Cost Management solution. You guys introduced that a little bit more than a year ago. Obviously, cost management continues to be a big topic for customers still. So I'd love to hear your thoughts on how the product is performing and whether there have been any surprises from your perspective. In our conversation with industry contacts, it seems that customers, even after they finish the extraordinary optimizations, we'll call it, they kind of treat their software spend with a little more care than they used to. Thank you. So this product, as you said, is about a year old. So we're starting to see, actually, pretty good adoption for the product. And what you're saying, the trend of slowing down on the cost optimizations, I don't think that's really kind of at play here. The idea of cloud cost management is actually to change the culture of cost, being able to not talk about cost at the end of the months when you're actually going to look at your bill that you're getting from your cloud providers, but look at it all the times, being able to make sure, again, your developers, people actually making decisions which will impact your cost, make the right ones at the time when they're going to look at what they're going to be deploying, when they see some performance issue, and so on. They will actually be able to take cost decisions. So we bring cost data with observability together to get them the ability to really make those decisions very early. And what we're seeing here, this is actually a very differentiated use case for all our customers. They're seeing this, finally, I can bring this together. And they have way more people using Datadog than, I would say, looking at the financial report at the end of the month. Still, what we're doing is we're going to go and expand to bring more and more of those FinOps personas into it, again, breaking one more silo by bringing finance into the same environment, but really how they would be able to interact better with their developers, with the operations people, actually, again, making the actual cost impact at the end. You know when you think of what that product has been doing well so far and what we're still working on, it's working really well in terms of its depth. It actually makes a drastic impact when it's implemented. What it's still lacking a little bit of is breadth. It still needs to integrate with more of the sources of cost that our customers see. That's the main feedback we hear from them, that, oh, I'd like to see my cost from this other product and that other cloud and that other thing in there. And I don't see it yet. In terms of the successes, I'm aware of at least two very big successes. One is one of the customers we actually mentioned on the last earnings call, a larger restaurant chain, that saw tens of millions of dollars of savings just attributed to the use of our product. The other is Datadog itself. We have been heavily using the product along with our Continuous Profiler. It had a drastic impact on the internal culture of managing cost. You've seen directly the outcome of that in terms of our improving gross margins. And so it's also a story that we'll want to try and package a little bit so we can tell it to the outside world. Let's take two more questions. David? So Ray McDonough from Guggenheim. Thank you, guys, for taking the question. So Ali, as you think about bringing together security and DevOps in particular, does this become more of a top-down sales motion over time versus a bottoms-up sales motion to the developer? And if so, how does your go-to-market strategy need to change to help drive the value proposition of the entire platform throughout an organization, especially when we start thinking about larger organizations? Yeah, so when you think of the way we sell to larger organizations and by the way, we'll have our CRO on stage soon. So you can grill him with all these questions as well. But the way we sell is, in large enterprises, there's always some top-down involved. But it's always sitting on a healthy dose of bottom-up. So the product is adopted. You get to see some usage and some outcomes. And then you need to sell top-down to make sure that the big expansion and the long-term deal and everything else actually goes through. And we get buy-in from all sides. And I think security is no different. I think we still want to show value bottom-up. The way we solve problems is by getting adoption. And that's going to work the same in security. There's a little bit of nuance between some of our security products. I think the ones for which we shipped shared SKUs, so our unified SKUs around infrastructure and application security, those tend to be both more on the DevOps side and work very well with the bottom-up model. The Cloud SIEM one tends to be both more on the security side, still rests on our Log Management solution being deployed. But there's a bit more of a gap to cross there, maybe, but nothing drastic. Great. Megan's side, last question. Thanks. This is Matt Hedberg from RBC. Thank you for this. This is great. Maybe as a follow-up to that last question, your cross-sell statistics are obviously impressive. And I imagine a lot of customers land with one of your big three infrastructure, APM, logging. But can you talk to the extent that customers are coming in with maybe a different product and then expanding into the core products? Maybe it's cyber. And then on the security side, where are those dollars coming from? Are you displacing vendors? Is it net new dollars funding some of these security initiatives? That would be helpful. Thank you. Yeah, you know, so for where the dollars are coming from, usually when the products are newish, we usually start alongside of a product. So it tends to be net new. And customers still spend on something else. And as the products get more maturity, we tend to replace other things. I think that's how it shifts. I forgot what the first part of the question was. The first one was more like. Landing. Can we land with other products? Oh, land with our products, yes. I think especially for very large, older organizations that are going through a digital transformation now, sometimes they're just very early in their cloud migration. But they all have mobile apps already out there, right? They all need synthetic testing. And so there are opportunities sometimes. Yeah, we do get some, for example, again, I'll come back to. I don't know why I mentioned them so many times today. But that large restaurant chain that we mentioned in the last earnings call, they actually didn't start with any of our core products. They started with some smaller products, including Cost Management. And then they expanded into the rest. So that's one example. Those are still a bit of a minority. And the reason for that is that the way we run our marketing teams, the way we run our sales teams, is still predicated on landing with the core products because it works, because it's easier to train everyone and measure all of our different channels the same way. And there's no need to complicate things. But we keep toying every now and then with the idea of pushing harder on some products that can be very low friction and can get us broader adoption outside of the core products. So not happening today, but something we might do in the future. All right. OK, well, that's it for this Q&A session. Thank you, everyone. We're going to take a short break. How about we start up again at 3:30 P.M.? So maybe you guys can meander back to your seats around 3:25 P.M. Now, before you go, let me just explain a little bit because we've still got stuff for you during the break. For those of you on the live stream and for those of you hanging out here in the theater, we are going to show you some customer testimonial videos. So you can hear firsthand from our customers how we solve their critical problems. But I do want to encourage our in-person audience to go out to the foyer. If you didn't get a chance before the session started, we have four of our great senior product leaders out there. It's a real big opportunity for us. We don't usually get those kinds of folks at the demo stations Jimmy on infrastructure, Omri on APM, Pranay on logs, and Rishi on security. So I encourage you to go check out our platform for yourselves. All right, thank you very much. See you around 3:25 P.M. I'm Stephen Fry. I work for the London Stock Exchange Group. We are a leading provider of financial markets infrastructure and data services. The London Stock Exchange Group is historically around 300 years old. It's had to continually transform and innovate. Datadog helps us innovate by giving us insight. It's as simple as that. You take all of the data that you can possibly get from an application. You learn as much about it as possible. You consume and bring that data together in a way that's meaningful so that you can create a better customer experience and a better service. The biggest risk for us, being a financially regulated firm, we're systemic. Because we're systemic, the challenges that we face today are that if the infrastructure goes down or is faulty, the impact is immediate to the market. We've had experiences where an announcement comes out into the marketplace completely unexpected. Suddenly the website hits just go through the roof, instant impact on, obviously, the performance of the website. Datadog monitoring enables us to see that before the customer sees it and to take action and do something with it. If we see problems with the website, we can then act on that using AI operations. We have trigger events that go off and fix problems. Or they might scale up the website because of the usage increase. Before we used Datadog, we had sparse information about the workflows and the processes that were going on around our trading applications. With the introduction of Datadog, we've now got masses of data points that give us insight about the application. That enables us to take it back into the development cycle and improve the service so that our customer experience is much, much better. Toyota's mission is to build a future where everyone has the freedom to move. With AI, ML, and new technologies, we want to take it to the next level where humans have more choices to select and more freedoms to move from point A to point B. Our team is a team of seven engineers. We define success by the tools that we provide our customers and end users. Right now, one of our main focuses is observability and preventing downtime. With Datadog, we are managing our entire observability platform with thousands of nodes in on-prem, hybrid, and cloud environment. With the Datadog and with precision monitoring capabilities and AI/ML, that is a game changer for us to solve problems using Datadog. The first bit of value we saw when we implemented Datadog was the amount of time it took to deploy. Instead of having to have somebody go in and do the deployment over thousands of machines, which could take weeks, we were able to push out the Datadog Agent in a matter of minutes by utilizing the Datadog pre-provided Ansible roles. By doing so, we saved hundreds of hours in full-time employee time and allowed them to focus on other things. Since implementing Datadog, the main value that we've seen is reduction in mean time to repair by 80%. Datadog is a game changer. We have automated guided vehicles, AGVs, in our plant floors. The AGV started malfunctioning and disconnecting from the network. It's disrupting our plant operations. With Datadog, we are able to pinpoint the issue is not related to network. Rather, it's a core issue in AGVs. With Datadog, we are able to solve problems not only weeks, within hours and minutes. This single incident potentially saved us somewhere thousands of dollars. One of the best features we use in Datadog is the Watchdog feature, which uses artificial intelligence and ML in the back end in order to help us forecast and prevent our future outages from happening. Before that, we were very reactive. But now, with this new feature, we're more in a proactive state. Less questions are asked to the team. For example, why did something break on ABC 123 day? Now, the user can go into the system and actually look that up themselves and educate themselves on how to actually prevent that in the future. Whenever I talk to my team, my team says, let's unleash the power of data with Datadog. The mission of Uber Freight is to simplify the moment of fright that helps communities thrive. The strategy is to build an end-to-end observability into our system and maintain a 99.999 SLA. Before Datadog, there was a problem with incidents that's been reported widely by users, not by systems. We also had monitoring coverage problems where we couldn't fully expand our monitoring capabilities across the system end to end. Another issue we had is to democratize the monitoring tool for all of engineers, product, and business. When Datadog comes in, we were able to open up access to all users, more specifically engineers and non-engineering users. Most of them are invested in looking into the system's health, some KPIs and APIs. They want to understand what's happening in the system. It's open. Everybody can look into it and contribute back. They can have their own specific dashboards that serve their purposes. We do have certain dashboards that serve the business. So they can look into it and see what's happening across my system. Datadog helped me solve two key problems: one, end-to-end observability, infrastructure APM profiling, and database monitoring. We capture everything, put together in one place. And we built meaningful dashboards out of it. And the other piece is more system-reported than user-reported. We understand the system with an existing metrics. And we understand our pain points. And we work with our internal stakeholders, improve our system, and track it again with Datadog. Why did you need a Cloud SIEM platform? 1Password helps individuals and businesses protect their passwords, credit cards, API keys, most sensitive data. My role at 1Password is I lead the security detection response team. Our mission is to monitor our environment, detect, and respond to threats. Why did you choose Datadog Cloud SIEM? Datadog Cloud SIEM helps me do that because it aggregates logs from various sources. I can see what's happening in my environment across the board with Datadog using Cloud SIEM. I've used several SIEMs in my career. I prefer Datadog primarily because of the UI. That's the first thing that stands out to me. The rules are intuitive, easy to understand. It's easy for me to onboard new team members. I'm Stephen Erickson. I'm an engineering manager for The Washington Post. We have a very dynamic traffic cycle. So from one moment to the next, we may have breaking news that comes about. And when that breaking news does happen, we can get traffic spikes. On January 6, on the Capitol riots, all of a sudden I saw in one of our Slack channels a Datadog monitor that we had set up come in. And it flagged that there was a huge spike in traffic. If it hadn't been for the Datadog monitor that fired, that alerted us to the event, we would not have been able to sustain the load. And so because of that alert, we were able to basically go and scale our systems and handle it appropriately. Datadog has really provided a tremendous amount of visibility into our overall platform architecture, all of the back-end, front-end services that we have. Particularly for the DevOps culture, before Datadog, there was not a great understanding or visibility into our overall system. Datadog brought that all together in one cohesive scene. When an event does happen because they're going to happen, I go to Datadog first. I can get an overall view of the world where I can look at all the systems in one unified location. I can see what my problem areas are, how Datadog has impacted my life. I'd say that it's made my life dramatically simpler. Why did you need a Real User Monitoring solution? Wawa is a large convenience store and gas station chain that's primarily focused on the East Coast but continuing to grow into further west. It's increasingly important for us to understand customer engagement, understand rewards, and different ways of enticing our customers to enjoy their experience better. Why did you choose Datadog Real User Monitoring? Datadog offers an integrated solution. We can look at the problem holistically as to why we might be having issues. The Real User Monitoring solution helps us better understand what our customers are doing in our stores when they go through the ordering process to buy a sandwich or a drink or anything like that. Real User Monitoring gives us those insights that we need to design our software better. Mercado Libre hosts the largest online commerce and payments ecosystems in Latin America. We operate in 18 countries. Our mission is to democratize commerce and financial services to transform the lives of millions. Our e-commerce business unit has over 73 million buyers and 90 million sellers, 365 visits, and 36 purchases per second. Our financial services units average 173 transactions per second, with over $10 million granted in loans. Our applications primarily run on AWS and GCP. Currently, we have over 100,000 cloud instances running, more than 900 million requests per minute, 24,000 microservices, and more than 10,000 daily deployments. As our company grows fast, Mercado Libre infrastructure becomes more complex. We have transitioned to microservices, which makes app building easier but more difficult to monitor since there are so many different components. We needed a tool that would centralize the data across our tech stack so we could make decisions and troubleshooting faster. We selected Datadog as our infrastructure monitoring solution due to its extensive range of integrations and strong reputation in the market. We valued Datadog's comprehensive AWS and GCP monitoring capabilities, making it the ideal choice for our needs. Thousands of dollars can be lost if some of our critical applications stop working for even one minute. Datadog helps us to act fast. An alert is triggered once a problem is detected. The right team is about to fix it. The alerts often include troubleshooting information, which accelerates resolution. We recently had an issue with a service due to a problem with a database, thanks to thresholds that we have created in Datadog. We are alerted before the issue becomes critical. We were able to act quickly and make the necessary changes. Having our metrics in Datadog not only helps us to react quickly to problems but also powerfully aligns with strategic and proactive decision-making. For example, we relied on these metrics to tell us if our usage of a cloud service was increasing too much or that we were not reaching our goal of using some type of reserved Spot Instance in the targeted region. Mercado Libre is continuously looking to improve our application costs, uptime, and performance. Datadog is a big help with this initiative. We are researching with Datadog to find more opportunities to be more efficient and available. Why does T-Conecta need Application Security Management? Well, because we manage financial resources from our clients. It's important to us to secure this resource in our platform. Why did T-Conecta choose Datadog ASM? We use ASM from Datadog to reduce critical issues in order to prepare the company for the annual pen test exercise. I'm an engineering manager of a few different teams. We aim to provide a platform for all of our users inside of the Autodesk Construction Solutions division. Generally, we look to make sure that that platform gives them all the observability that they need to be able to own their own infrastructure wherever possible. So we chose to use this Database Monitoring product in addition to the other Datadog tools we were using. From my perspective as an infrastructure engineer, it allows me to offer more insights to our users with less access directly to the databases, with less expertise required since the query plans explain is turned on by default. I'm really enjoying the explain and query visualization. It's helpful to have that stand out so that you can just quickly pinpoint where you might want to investigate more. Then it's super helpful to have not only that visual representation but also some of the suggestions on how you might solve some of these performance issues that it's bubbling up to you in that view. A variety of people in my team use DBM. Generally, they kind of fit into two different personas. We have product engineers that are actually building the tools. So they go in and look specifically at their own databases to help do performance or query tuning. Then folks on my team or folks that have a responsibility that crosses many different products, they will use it more as a fleet management tool and understand, oh, these specific queries are kind of the top offenders of being slow or underperforming. We'll go in and use that to proactively reach out to those product teams to help them understand how better to improve performance. Datadog allows us to do that by continually developing products that make it easier to maintain the systems that we instrument with them. But it allows my teams to take something we find very important, which is observability, and have it be a default offering of the platform that we make. Why did you need a solution for Cloud SIEM? My team is, as you can imagine, a scrappy startup involved in just about everything. But we are responsible for running our security operations center. We are involved in DevSecOps. We are running the compliance program as well as being involved in operations, supporting the developers throughout the software development lifecycle, and pretty much any other odds and ends that need to get done. So we have a very small team. And having a small team, we need to maximize what everyone can do. Why did you choose Datadog Cloud SIEM? When we started looking at platforms that would enable us to pretty much get all of our information, logging, and alerting in one spot, we kind of looked at the build versus buy, the speed to get results. Datadog was by far the easiest and most integrated platform that we found to be able to get all of our disparate types of data into one spot, have out-of-the-box detection rules applied, as well as have a workflow that captures our incident response process within defined workflows in Datadog. It reduces the mean time to respond from hours down to minutes. Our mission, just to simplify it, is to simplify healthcare, to make it easy, to make it transparent. TriZetto's applications are critical because it allows us the transparency to see what we're paying for care, what the services cost. Some of the challenges that we had before using Datadog is we had no visibility into issues. Clients would call us and say, "Hey, such and such is slow. Such and such is down." After we implemented Datadog, it was like the world of data was our oyster. We had real-time data and telemetry at our fingertips. We could look across the environment and know what was going on for various systems where prior we had to swivel between different web pages and monitors. It just improved our mean time to resolve issues. We are able to more closely partner with our clients. We are currently actively working on operational dashboards for our clients where they can see the environment real-time. They can see how their systems are performing in real-time. They can look at the response times of our systems. They can look at the uptime of our systems, the availability. I have budget responsibilities. And one of the first things that Datadog enabled me to do was to reduce my costs. I was able to consolidate down from four different tools for monitoring to one. I always joke with my account rep that before Datadog, I was blind, but now I can see. There is some truth in me joking around in that I didn't know what I didn't know. And now that I know, I can address and I can fix issues proactively. If you're looking for a way to get better, save money, consolidate tools, especially around observability, monitoring, and get a full feature set, Datadog, I would definitely recommend. All right. Well, welcome back, everyone. I'm excited to kick off the second half of our Investor Day, and I'm pleased to introduce our Chief Revenue Officer, Sean Walters, to the stage. All right. Good afternoon, everyone. My name is Sean Walters, as Yuka said, and I'm the head of sales here at Datadog. I've been here for about six years now. I'd like to spend some time with you today to talk about how our go-to-market motion works, what we focus on, how we're organized, and how our go-to-market teams go about solving customer problems and delivering value for them. The primary focus of our go-to-market team is landing new customers, new business units, and new products. Every new customer we land is a new flywheel, which will expand with additional business units and additional products. We spend a significant amount of time optimizing for this growth. We look at the market, the personas, the success patterns, and the spend data to determine an individual account's propensity to buy. With that information, we then prioritize accounts, creating and aligning territories and regions for optimal pursuit. So we structure our go-to-market teams based on where we can best meet our customers' needs. Even in our largest customers, we often see adoption occur in a bottoms-up fashion with a very lean sales motion. But they tend to have more complex purchasing processes and often require a detailed analysis of the business value they'll be able to realize. Some choose to issue RFPs, running a multiple-vendor competitive process, or they might choose to run an extended proof of concept. These, executed in conjunction with a business case, provide customers with both the technical and business proof they need to move forward on a contract that can span multiple business units and multiple products. We engage those customers with our enterprise sales team. This team coordinates many areas of Datadog expertise to provide customer access to the right resources and information they need to be successful in evaluating Datadog. So that's one set of customers, the large ones. But there's another set of customers, the many startup, younger or smaller, more nimble customers. As smaller organizations, they can move faster, and they often already know the tool that they want for monitoring. They just want to get access to it quickly and go. For those companies, speed and agility are paramount. They make decisions quickly and frequently rely on best-of-breed products or previous experience with certain products. In those cases, we sell through our commercial sales team. This team makes it as easy as possible to buy from Datadog. The customers are often on such a growth trajectory that they don't know how big they'll be or when that'll happen. So this type of customer needs flexibility. To support them, we provide on-demand and month-to-month subscriptions at as low a commitment as they'd like. They can transact with us as quickly as they want without jumping through many of the traditional hoops that our enterprise larger customers might need to. Now, with both sets of customers, we're helping them realize the value that they're seeking. With our work across more than 27,000 customers, we've found that these are the most common value drivers. First, they're full-on with digital transformation. If you're not a digital native, you're likely being disrupted by one. Every organization in every industry is in some state of transformation to leverage web, mobile, and cloud to compete. And the pandemic accelerated this for many organizations as well. At the same time, these organizations are trying to be cost-effective and scalable. And they want to ensure that everything they do is secure and compliant. And if that wasn't hard enough to do all of those things at the same time, they're also trying to improve the customer experience. Datadog can help with all of these. And that's why our go-to-market teams spend time with customers to learn what value drivers are most critical for them and why. With that, we can help them achieve their goals through our industry-leading observability and security solutions. We've structured our go-to-market sales organization around these two distinct types of customers as the selling motion is very different. Our largest customers, those with 5,000 employees or more, are serviced by our enterprise sales team. As mentioned on our earnings call, we have about 42% of the Fortune 500 as customers. That's good progress, but there are still many that are not Datadog customers yet. We're putting an increased focus on these accounts going forward. When we land them, they have the potential to be our next $10 million+ ARR customer. Our salespeople are focused on making sure that we educate them, deliver value, and make that possibility a reality. As we land enterprise customers, the salesperson stays with the account through the lifecycle of the relationship. It takes a lot of focus to understand the customer's need, find additional challenges that we can help them with, and then educate them on those additional solutions. Here's an example of an enterprise customer's journey with Datadog. This is a leading American insurance company, and they've grown with us over the years to not only be a large Datadog customer, but they also engage with us with over 2,000 monthly active users across 20 of their business units. With 11 products currently in use, there's plenty of opportunity, which is a significant footprint. There's still plenty of opportunity for us to grow as they advance their business. You might notice a pretty significant increase in ARR that kicked in about 2021. This is when so many organizations accelerate their digital transformations. It also happens to be a time where Datadog's innovation engine had delivered more new products than the single one we had when they first became a customer of ours back in 2017. This is the magic formula: the movement to cloud and our broad product portfolio. Over the years, we've grown our enterprise sales capability. At the same time, enterprise companies are increasingly moving to the cloud. When we look at our penetration by vertical, we're being used by many of the top companies in these industries. Many of those accounts are in the early stages of moving to cloud, early in DevOps, and also early in their digital transformations. There will be many more opportunities for us to expand these businesses in the future. Okay. That's our enterprise sales team. For our customers with 5,000 employees or fewer, we have our commercial sales team. These teams operate with an inside sales motion focused on those who we identify as having the size and technical skill to be moving to cloud and having the potential to be a Datadog customer. An important source of the commercial pipeline is marketing leads that come through community events, webinars, and other marketing events that we hold. The commercial sales team is a pure new customer model. Several months after landing a new customer and new account, the customer relationship is then transferred to our customer success team. The commercial rep goes right back to finding that new customer. We're always making sure that we're working to have incentives aligned to those goals. Here's an example of a commercial customer. Like many of our commercial sales customers, this company is a younger company. They're a digitally native customer and didn't have any legacy technology or tooling in place. As a streaming TV service, it's imperative that they have an observability platform that lets them deliver performance and a great user experience for their customers. This is a technically savvy customer. We'll service this type of customer and support them on their journey with our customer success team. The final leg of our go-to-market strategy is the self-service market. A lot of other software vendors focus mostly on enterprise use cases. So for them, there's only a finite number of accounts that they can go after. Whereas for us, even though we have over 27,000 customers today, we believe that there are a lot more new customers for us to go get. We serve these customers from the smallest startups to students and engineers just checking us out. Our sales teams don't spend time here as these customers are self-serve. They can get a free trial on our website. At the end of that, they put in their credit card information and start using Datadog with no commitment. We just bill them month to month. Though these customers are often not spending much with Datadog, they are very important to us. Some of them will become much larger companies over time, and some will use Datadog, see value, and later adopt Datadog as they move to new roles in other companies. Finally, our smallest companies help keep us honest, that we can be deployed everywhere and used by everyone. If we don't make our platform easy to use with strong documentation, this group will quickly let us know. So before I go, I just want to speak about a few of the many opportunities that we have to grow our business. While we're now over $2 billion in run rate sales and have over 27,000 customers, we are still a very young company. The cloud market is early, and there are many areas in our go-to-market where we have opportunities for continued growth. The first one of those is international markets. We're more mature in North America, but we have yet to fully penetrate the APJ and EMEA markets. There's not only a great new customer opportunity in those territories, but there's a great opportunity with our existing customer base to expand those customers as well. Another growth area for us is vertical markets. There are some that are still too early for Datadog, and/or their industry is still slowly moving to the cloud. Public sector is a great example of one of those, and we are in our early days. We're just getting started with FedRAMP Moderate. Late last year, we announced our intention to move towards FedRAMP High, which will unlock significant business for us. The opportunity is massive if we do it right. While we primarily sell directly to our customers, we are increasingly seeing some larger, more complex customers working closely with system integrators in their big moves to the cloud. Working with them and others in the partner ecosystem represents a growth opportunity for Datadog in covering geographies that we aren't in. This will help us enter accounts we have yet to penetrate and help our customers manage the transformation projects seamlessly integrating Datadog for them. And last but not least, there's our expanding platform. As you heard earlier, our R&D team is not slowing down, and we have more products to sell every year. The security opportunity is a massive opportunity for us. Our products are maturing, and the portfolio is slowly building up. That's an enormous market opportunity all on its own. Besides security, there are additional products in observability, as well as what we're doing in software delivery, Cloud Service Management, and closing the loop. As you can see, we've got a lot to do. Let me hand it off to Angie now, who will speak with how we support our customers and grow with them. Thanks, Sean. Hi, everyone. My name is Angie Holt, and I lead the global customer success organization here at Datadog. So first, let me just start by sharing our vision, our mission, in the customer success organization. It's rather simple. It is just to ensure that all of our customers are getting the most value out of the Datadog platform. And we do that by partnering closely with our customers to understand their business and their business goals. And then we work together with our customers to execute against those business goals with the products that they're currently using, as well as suggesting new products and other products in our platform that could assist them. And when our customers realize value, they often grow with us. You've heard us say many times at Datadog that we want to meet our customer where they're at. For many of our customers, they want to start small with us. They want to start either with a single product or with a single team to test it out, experiment. As they continue to experience the product, they continue to buy more. We also want them to be able to purchase the way they want to purchase. You've heard us talk about how we have different pricing models. We have on-demand. We have month-to-month, as well as annual and multi-year commitments. So again, we want them to do what's best for them. When they have the product in their hand and they experience how easy it is to use and how quickly they can realize value, we often see that they start growing with us, partially due to their own organic growth and their expanding on the cloud business, but also because they're bringing in more users and more business units onto the platform. They also adopt more products as they start using more of the product. As our relationship with the customer grows, we can better understand their business problems and their business goals and suggest other ways we can help them. Our unified platform is a big way in which we do that. It's designed to be a single pane of glass where customers can correlate a lot of different kinds of data across a lot of different products all in one central place. There's a ton of value in this. First of all, this unified platform dramatically increases their productivity. Customers now can solve a bunch of different variety of problems right there in one product. They don't have to switch products. They don't have to switch contexts either. So this helps them reduce the average mean time to resolution, which ultimately helps them deliver a better customer experience to their customers. There's also some cost savings with this. It's a lot cheaper to use one platform than a bunch of multiple point solutions as well. Because it is a unified platform with all our products in there, customers can easily check out other products or capabilities that they're currently not using right there in that platform, as you can see here. Customers can easily turn these on. It's very self-serve. Our products are designed to be very easy to use and intuitive. Plus, there's a ton of educational documentation right there in the platform to help them. But this product-led motion is also assisted by the customer success organization, the CSMs, because of the relationship that they have with their customers. Because they're partnering very closely with the customers, they understand their business problems that they're trying to solve so they can suggest best practices for trying to resolve those problems. They can also suggest different types of products that we have that they might not be able using that can help them support them with their problems and business goals as well. Or as I mentioned in the previous slide, if a customer turned on a new product or capability in a self-served manner, the CSM can assist them to making sure that they're really fluent in that product. That could be anything from training to optimization. But ultimately, the CSM really wants to ensure that they're getting the most value out of all the products that they are using. They engage with the customer holistically to really help them meet their goals. Now, you've heard us talk about commercial and enterprise. Not all customers are created equally. So we've tailored the way we service our customers based on their needs. We have found that commercial customers are often best served by having a single point of contact, the CSM. Commercial customers can become very large, can grow and become very large Datadog customers, but their needs are often different than that of an enterprise customer. They tend to have a single centralized team that manages their observability tools so there are less stakeholders. They tend to have a more streamlined procurement process. In addition, oftentimes, they are cloud native and very technically savvy. All of this is to say that they often don't want to work with a bunch of different people but rather prefer having one point person. And so that CSM is that point of contact for them and owns that relationship with the customer. Then there's our enterprise customer. Oftentimes, a large enterprise customer could feel like a large number of commercial customers rolled into one, with each business unit acting like its own company. There are a lot of stakeholders, a lot of processes. They're often earlier in their cloud journey, and they have a large on-prem footprint. They often want to work with post-sales resources to help them align all the different groups that they have using Datadog to ensure that they are getting the most out of the platform and using it to realize the full value. We serve these customers with a variety of larger go-to-market team, which includes a lot more specialized roles. You can see here, our enterprise go-to-market team consists of our account executive and CSM, but it can also consist of a lot more specialized support roles, if that's something the customer wants. For example, if a customer wants to have more hands-on, tailored trainings for the different business units, we have technical enablement managers for that. We also have Premier Support, which is a higher level, a white-glove service and support that more of our enterprise customers are buying every quarter. Over 100 of our largest customers and more every quarter have technical account managers, or TAMs. A TAM is a Datadog expert that's embedded in the customer's team. They're there to help focus on helping guide the customer on how to best configure, optimize, and industry best practices, but tailors it for the customer's specific needs, business needs. These multiple teams come together to best service our enterprise teams. We believe that these different models for serving our different types of customers are working really well, and it enables us to deliver the most value to both our commercial and enterprise customers over time. You can see that here with these graphs. As our relationship matures, we find that the partnerships often also grow alongside that. That's demonstrated by the healthy expansion in the average revenue per customer, as well as the average product adoption per customer for both commercial and enterprise customers. So let me bring all of this to life a little bit more with two customer examples. The first customer example is of a commercial customer in the online betting space. So this customer is cloud native, very tech-savvy. Their entire business is predicated on reaching their customers in the cloud, so their online experience has to be great. They started using Datadog back in 2014, pretty basic usage, just Infrastructure Monitoring of their backend. In 2019, they started adding other products. They added APM, and in 2020, continued adding Logs and Synthetics. In 2020, COVID hit. Their business growth was impacted as well, as sports came to a pause. So there was not as much online betting going on at that time. But soon after, as their business came back, they started adopting more and more of our Datadog platforms. Following a merger they had, they found that they had multiple teams, multiple siloed teams in the organization using multiple different products, which made it very difficult for them to control the customer experience and deliver a great customer experience. So they decided to consolidate onto the Datadog platform and expand their relationship with us by replacing a lot of the multiple point solutions there. As you can see, this customer has adopted a ton of products on the Datadog platform. They have about 1,000 monthly average users logging in every month to use the platform. We really helped support this customer while they were growing, but also when they were facing challenges as well. Their most recent renewal with us was a multi-year deal that just really reinforces the long-term partnership that we have with our customers and that they have with us. My second example is of a Fortune 500 enterprise customer that's in the healthcare space. And so as you can imagine, when delivering critical healthcare services, you need to get it right. It's not one that you want to go down or have any issues with. So this customer started small way back in 2007, early 2017, with us, and over time added a number of different products. As their relationship with Datadog kept evolving and growing, they decided to bring on both a TAM and a TEM to ensure that they were using Datadog well, that all of the different groups were using the product correctly. The TAM started by first delivering hands-on, tailored training to a few of their different business units that were all new to Datadog. The TAM helped them remove blockers, helped them with specific trainings, very specific working sessions, and specific cases that they were doing, all tailored for the customer. As more users and business units came on the platform, the TAM came in to then help align and unify all those different groups, but then also share best practices, provide technical guidance, as well as facilitate connections with our product managers based on the customer's advanced needs. This customer is now using 17 products and continues growing with us. They see us as the only observability platform that can really tie together a single transaction from the front to the backend seamlessly across their dynamic and distributed systems. Datadog is providing them a single pane of glass for all the different product teams that they have and stakeholders they have across their different business units to easily track and understand their performance data. Our go-to-market team came together to really help them maximize their ROI through productivity savings, improved customer experience, reduced downtime, and a bunch of other things as well. So we have seen that these models are working really well, and we're proud of the growth that we've seen with these. But we continue to evolve and to deliver more customer success and customer value. So with that, I'm going to turn it over to Amit now, who's going to speak to some of the other ways we deliver customer value. Thank you, Angie. Hi everyone. Good afternoon. My name is Amit Agarwal. I run product, customer success, marketing, and corporate data at Datadog. To summarize what Angie and Sean said, we serve a diverse set of customers, from the smallest startups to the largest companies in the world, from people who monitor one server to tens of thousands of servers and petabytes of logs and user sessions. Now, we meet our customers' sophisticated needs where they are. So with the smallest customers or with their startups, sometimes they are cutting-edge technology companies that need automation as well as documentation to get started on their own, and we provide them that. Then we have 100-year-old companies that are complex and sophisticated in their own ways, where we provide them training, support for hybrid environments to help them on their digital transformation journey quickly. Most importantly, we laser-focus on delivering value to the customers. I hope you got a sense of that from all the leaders that you saw from Datadog speak today. Everything we do, from go-to-market to our ongoing relationship with customers, to how we enable customers for success, delivering tangible value across our platform and proving our value relative to the alternatives. Now, this term value sounds very buzzwordy. So I'm going to take you through a few examples to specifically talk about that. So first example, this is a healthcare company, four years with us. And when they started their journey, they had four or five open-source technologies and a commercial solution. And when we first delivered a quote to them, we gave them an order form. And they were like, "Whoa, this thing costs more money than our open-source and the commercial technology put together." Of course it did because our product was a commercial product, and they were using open-source technology, which they thought was free. But then we went through a business value assessment with them to truly understand the cost of what they were doing. And as you can see on this slide, the biggest amount of time that they were spending was juggling between all these different open-source products with their engineering teams, which dramatically increased their engineering time as well as incident management time, which they were not really counting into their total cost of what the solution provided. So yes, our product was more expensive than the commercially available plus open-source solution they were using. But the moment they looked at it from a point of view of the total cost of ownership, it was a third of what they were spending before. So. Okay. Next customer. This one is one of my favorites. Big e-commerce company processes millions of orders throughout the year, worth $ billions. They've been with us for six years and adopted our products broadly. They're using our products everywhere now. Again, we did a project with the customer where the customer wanted to make sure that they were getting true value out of Datadog. And we were very quickly able to show that just on product licensing costs, they were able to save about 50% compared to what they would have spent on all the other tools that they were using when you include all the licensing costs, productivity with the engineers, and so on and so forth. But then there was another point that we hadn't even discussed with them that as we went through this process that we discovered, which was this is an e-commerce company. When they go down, when their website is down, even for a minute, they lose money. And e-commerce companies, as we know, they have taken it down to a science to figure out how much money they lose for every minute that they're down. So they were very quickly able to show us that using Datadog, they were able to save $32 million a year in revenue that they would have lost because their website would go down a lot more before they used us and for a lot longer. And $32 million is not GMV. This is real revenue for the customer. So again, for this customer, the business decision was if you don't put everything in the single pane of glass, it takes longer to solve problems, which means revenue loss. And you don't want to risk that. Next one. A lot of the value we deliver comes from increased productivity for the DevOps teams. As Olivier said, our solution helps break down silos between teams, helping them communicate, helping them collaborate, solve problems faster, which is a way of improving productivity. So here's another example of that. So this is a midsize health and beauty company, relatively new Datadog customer, I think been with us for less than two years. Just to highlight some of the things on this slide, there's a lot of numbers on it, but they've already gone down 50% on the number of incidents that they have on their website by 50% since they started using Datadog. And it's a dramatic reduction, almost to an order of magnitude, on the total number of hours spent per year on incidents by developers. This is a big thing. This is a big thing because, as the customer told us, the key takeaway for them in this was the opportunity cost of having the engineers work on incidents as well as observability, where they could be developing new features that would generate more revenue for the business. So hard to quantify these costs in many cases, but in this case, it was obvious that they wanted to do this to have their engineers spend time on core business as opposed to observability. Next one. This is another really cool example. So this customer has almost 1 million employees. They're a large professional services organization, been a customer of Datadog for about 6 years. So this customer was using open-source tools to do real user monitoring, real user monitoring for their environment. And we went in and we were, again, doing a cost-benefit analysis with them to understand whether our product is the right thing for them to do. So as we went down the list of things, we typically look at developer productivity. We look at the cost of operating open-source tools and so on. The one thing, even before we started looking at that, was the cost they had of running all of their open-source tools on their own infrastructure. They had to buy the servers, the machines on which all of these open-source products worked. And they found that it was cheaper to buy Datadog and use Datadog than even just their infrastructure, even without considering all the other costs that they were incurring. And again, the point here is our platform is highly optimized for large-scale data volumes. The price performance for the platform is specifically engineered to manage large volumes of Datadog, to manage large volumes at very, very low costs, which means we can pass on these savings along to the customers. And that's what you're seeing here. Okay. Now, you've already seen the value we bring to the customers through adoption of multiple products on one platform. You've also seen the DevOps productivity improvements. The other thing that happens in most scenarios as customers deploy observability is that they start to monitor a lot more things. As they transform digitally, they start to collect a lot more data as well. Sometimes a challenge is that the data volumes far outpace their own revenue growth. Then they have to decide how much money to spend on observability. That becomes a challenge for some customers. If the data volumes are growing exponentially, if your costs also grow exponentially, the revenue growth is not exponential. It becomes problematic. We've been working hard on improving the unit economics that data volumes go up for the customers. Let's talk about that a little bit. So our products over the last few years have been engineered to allow for customers to send us massive volumes of data at very, very, very low costs. So they don't need to think about the volume of data growth upfront. And as we give the customers the ability to, in real time, either discard this data or store it in long-term storage or put it in Datadog for troubleshooting, analysis, dashboarding, alerting, etc., which gives you a quick way to not worry about losing data when you need it for regulatory compliance, forensic analysis, investigations, and so on, but also have the data that you need to troubleshoot an immediate problem in real time. This is the operating philosophy for most of our products. Now, here's an example of a Datadog customer that specifically worked on this. So this is a very large data analytics company. They grew their logs 22x, 22 times between 2021 and 2023. Now, what's happening in this case, as you can see on the slide, is the volume of logs grows exponentially, but the unit prices that they spend on logs have gone down exponentially almost at the same rate. This is a combination of two things. One, obviously, at higher volumes, you get higher discounts. That reduces the price a little bit per unit. The even bigger factor here is the ability for the customer to process all the logs and just use a small fraction of them for real-time analytics and pay for only those. In addition to that, we continually strive to make our products less expensive by pursuing innovative technologies, building out new things that help customers ultimately save money with Datadog. So we've taken the next step in this direction by building technology that allows users to operate on data that's even larger volume in long-term storage so they can use it while they're storing it in long-term storage. Flex Logs are a great example of this. We put a lot of engineering effort. We heard about Husky earlier this morning. With this new technology, we're able to manage the costs in a way where the storage costs are much, much, much lower for the customers. In fact, it's almost at the same scale as what they pay cloud providers for storage, while providing them the ability to operate on these logs, and then providing them a second-tier storage that allows customers to take a subset of these logs and, in real time, do alerting, dashboarding, and things like that. The takeaway on this, we spend a lot of money on R&D. A lot of it has to do with customer benefit, reducing the operating costs for the customers, finding ways for customers to manage ever-increasing scale and volume of data, and bending their cost curve. Here's an example of a very large payment processing customer where we put some of this innovation to work. This is a large fintech company paying us $tens of millions a year. They started with us in 2017 with one product. As they grew their environment, they added more products to it. They had many other tools in their environment as well. We consolidated most of these tools except one, which was logs. In this specific scenario, the problem that they had was every vendor that would go to them, they would say, "Well, we are at this very large scale. Can you make it more efficient for us to buy it from you rather than build it ourselves?" And the answer would almost always be no because they were at the scale where, at least in their minds, they could do it cheaper at their scale than buying it from someone else. So we worked with them. We worked with them. And with all the technological innovation that we've done over the last two, three years, we went back to them. And we analyzed all the data that they were using. We looked at what they were spending money on. We were able to very, very quickly show them that we could give them the same solution not the same solution, a much better solution than them with higher resiliency, much better user experience at relatively the same costs that they were incurring themselves in terms of engineering and infrastructure, which was a good bid for them because they could use our products, which have been developed with so many different users, with thousands of engineers that work on usability and so on, to provide a solution that they didn't have to worry about anymore. With this, I'll end and hand it off to the closer, the star of the show, David. Good job. Thank you, Amit. As Amit said, I'm David Obstler. I am in my sixth year as Datadog CFO. Welcome to everyone. Glad to see you. I wanted to start off by summarizing what you've heard today from my colleagues. First of all, we believe we have large, long-term and growing opportunities. Second, we've been investing against those opportunities in R&D and product in both significantly, and I would add smartly, in order to expand our platform, observability platform, as well as beyond to address additional use cases. Thirdly, and I think you've heard this from everybody, we're laser-focused on solving client problems. A lot of our product decisions come from our interaction with our customers and helping them solve a broader list of products. That's resulted in significant platform innovation and growth. We have a very effective go-to-market strategy of land and expand. You've heard many case studies how clients have started with us in parts of our platform and have expanded beyond that. I want to wrap up by echoing what everyone said, which is we meet customers where they are, and we try to solve their pain points and deliver value. Now, I want to give you my CFO version of closing the loop. I'm using it. How do we turn all this opportunity into revenue growth, attractive margins, and growing cash flow? To start off, I want to peek a little bit at our history. We've been successful in delivering against our financial metrics. Over the last five years, most of which is a public company, we've grown our revenues over 50%. We're now over $2 billion. And with that investment that you've heard about today, we've still been able to expand our EBIT. Margins have expanded from approximately break-even to, in the last year, delivering 23%. At the same time, we've delivered substantial growth in cash flow. So how do we do this? What are the drivers of all of this? I think one of the most fundamental ones and this goes back to a quantification of what you've heard about a lot of customer examples today. These are our cohorts. By year, they landed on Datadog. You can see from this that we've had very strong growth in using different parts of the platform, buying new products, and using more of parts of the platform they already use, both in terms of the growth of this and the long-term nature of this. This gives us a lot of confidence that we can continue to invest and create even more value for our clients. In our land and expand model, we've had a very strong contribution of both getting new customers and I'll talk about that. That is here in the green as well as adding to our customers. Both of them have, and we anticipate, to be very important growth drivers for us. Now, I want to dive a little bit into the way we have grown our customer accounts that you heard from Sean. You heard from Ollie. You heard from Angie, etc. This has been a very strong combination over the years of our customers expanding their digital footprint, putting more applications, and us going into different business units and clients, which is the expansion of existing products in orange, as well as, as we've expanded the platform, having our clients buy more of the products. In terms of the expansion of existing clients and, therefore, our net retention, that's been somewhere in the range of 70%-75% coming from expansion of products that they own and 25% or 30% from new products. That's been persistent and healthy and further evidence of the expansion of our relationship with our clients. Now, you know this has not been a straight line, particularly over the last couple of years. We've had a lot of things that have happened in the environment. As we talked about on our earnings call, we've gone through a period of optimization. What we said to repeat was we started to see signs in Q3, which continued in Q4, that the areas of the market that have most substantially optimized have stabilized, and they began to grow. We've seen our customers get back to work in launching more digital applications. The evidence of that here, as we said on the earnings call, is in Q4, we began to see our trailing 12 months of ARR add, what we added in business over the previous 12 months, inflect up for the first time in a year or so, meaning that we're adding more ARR in the latest 12 months than we did in the previous period. Repeat what we said on the call, which is that this is very good signs of stabilization. There's still risk factors out there. We're starting to see a firmed-up market. And they're exciting to enter this year on more firm footing. Now, sort of underneath of all that, what's enabled us to have this type of performance despite the headwinds? It goes back to the retention of customers. Our customers, once they adopt Datadog, they stay with us. This is gross revenue retention. This is a measure of customers sticking with us. I think, as we said, that number has been very strong in the mid-90s percent for a long time and was rock solid throughout the period we went through. In fact, our enterprise gross retention is 98%-99%. Once a client of sophistication adopts Datadog, they stick with us. The mid-market has been in the upper 90s percent. Even in SMB, it's been in the mid-90s percent. That is a very strong signal to how important Datadog is to our customers and how effective we are in solving problems for them. Now, looking forward, as many have talked about, we're confident that we're just getting going. There are many revenue opportunities for us to realize. So I want to sort of churn through some of those, to talk about some of those. Sean talked a little about that. The first of those is new customer acquisition or new logo growth. Now, going back to history, we've done very well. We've more than doubled our customer count over the last 5 years. We have 4 times-plus expanded our $100,000 customers. And we've also grown our million-dollar customers substantially. As we've talked about, 85%-86% of our ARR comes from customers who have scaled with us and are spending $100,000 or more. And we also have the longer tail we talked about. But we think we're just scratching the surface. We think our penetration of accounts that are using the cloud to deliver products to customers, it's about 5%. Now, the hyperscalers have millions of customers. So we know there's very big demand. But what we did here was we looked at cloud spend. And we looked at who is using the hyperscalers. And now, we've got that down to around 500,000 customers. So I think, as it's been discussed by Ollie and others, we believe we're very early in this cloud migration, digital application. And there are many more customers to get. Next opportunity, talked a little bit about the cross-sell. But to give you a little more flavor of that, this is a slide you've seen. But we are expanding in a number of ways, both in terms of the platform itself, but and I think you've heard that. That is enabling us to expand the personas and who's using it. As Olivier said, we are and want to be ubiquitous, meaning everybody uses us. That's one of the cores. And if we expand the product and expand the use cases, we feel we can do that. And to give you a little more flavor of that and this is what we report every quarter. You know this. But we've been to emphasize it and put it on a graph, we have been expanding the multi-product adoption in the company for some time. And this quarter, we added a new metric, eight products. And I think you saw some examples of that. We added that because we have a meaningful number of our customers that are using us more broadly. And so we've seen that kind of growth from one or two products all the way out to eight. Now, that's goodness. But there's a number of factors here that we see. First of all, we have a lot of customers, as you can see here, that are not using 8 products, that are not using 3 or 4 products. So there's a lot of opportunity. And what we find is there's a very strong correlation, of course, between what they spend with us and how many products. This is not a trade-out of 1 for 1. It is 1 + 1 equals a lot more than that. So the orange bar charts show what happens, as you've seen, as we expand the product set. Now, to give you a little more flavor, 60% of our customers today do not use all 3 pillars. So there is a tremendous opportunity to continue to cross-sell and have our customers adopt more of the platform, even when you go to the core 3 pillars. And why that's so exciting? Customers who adopt all three pillars spend, on average, 10 times more with us than customers that don't. So we feel there's a lot of opportunity, as you've heard, in continuing to work on product adoption. OK, that is one part of it. There's another part of it. And they're related. And we've talked about this over the last couple of earnings calls. We think there's a very strong opportunity to consolidate in the cloud monitoring. And to give you a little flavor for why we think that, we've looked now, over time, at the deals, whether they be new logos or existing customers that are over $1 million. And about 50% of those deals involve consolidation. So there's something else there. It's either open source. It's another vendor. It's a cloud. Another goodness is that those consolidation deals have an average booking four times the amount of the non-consolidation deals, further evidence that we are winning in the market and consolidating the spend. The evidence of this is, when we went public, we were not the largest company in observability. But over the last five years, you can see our growth. You can see that by customer acquisition, by cross-sell, and by consolidation. We are the largest. Our growth rate has been quite a bit more than our competitors, all driven by that platform expansion, that R&D, that go-to-market, that frictionless. This is evidence of it. Now, another thing that we're working on is investment in areas where we don't quite have the penetration that we might have in native cloud from where we started. There are a number of opportunities, first of all, to look at from an industrial point of view and understand that we're penetrating more traditional industries. As it's been said, everyone's going to be a cloud company. And so, therefore, some of our fastest-growing industries that we service are in airlines, energy, financial services, health care. You saw examples of that. So we've seen that as a trend, which means that the penetration of digital applications and the need for monitoring is spreading throughout the world. One of those that I want to highlight that Sean also mentioned was the public sector. And we're very early on in that. In fact, Gartner published that about 12% of the IT spend is in the public sector. And about 1% of our ARR is from the public sector. And so we believe we're just getting started. In order to facilitate that, as you know, we've achieved medium impact. We've announced that we're going to go for high impact, which will allow us to access the demand in the defense industry. We have an instance, the GovCloud. And we're investing in go-to-market. So that's just one of many examples in under-penetrating areas that we think are in our future. And Sean also talked about geography. We talked about our growth. And it's right here, from 25% of revenues to 30%. We have been investing significantly in a number of markets. And it's paying off. And some of the ones you've heard of today, but just to echo that, that we have been successful in and are investing are Japan, Korea. We've been servicing India from Singapore. And we just entered India. It's a huge market. And so we're going to be there, and Latin America. And that's just scratching the surface in the number of geographical opportunities we have. And then to circle back, finally, to where we started, which is the opportunity and the size of the market. And Ollie went through that. But in order just to sort of summarize that, there are very strong secular tailwinds. This is one of Ollie's first slides. The cloud market is expected to grow at 20%. And I think, as we mentioned, get to over $1 trillion. And that's at the bedrock of what creates the demand for us. And the observability market also is large, $51 billion we put out, and is growing 11%. And it is very large. And in addition, we talked today about expanding our footprint. And again, this is research in Gartner, et cetera. The cloud security TAM is $21 billion and growing 16%. I think you've heard about our investment there. So we have very large TAMs, diverse TAMs, and additional TAMs to service. OK, I'm the CFO. So I'm going to talk a little bit about profitability and margins and go back a little through history where we've come and where we might be going. This is closing the loop even more. We have been a very strong performer on the margin line. And this is the history. We've expanded our gross margins by 600% over the last five years, all credit to the engineering projects that we've executed, as well as, as Ollie's mentioned, our eating our own cooking, our use of our own cloud cost management software. This enables us to monitor this on a regular basis and achieve these kinds of results. In addition, we have been able to expand our operating margins from roughly break-even to 23%. With that, we've produced strong cash flows. As was mentioned, we are a product-led company. There are many opportunities around R&D. I think Alexis said, as we get more efficient, there's a whole list of things to do. We've maintained a very strong posture in R&D. To evidence of this, this is a slide that we looked at. We looked at the epicenter of Datadog. Are we investing in the platform continually? We are. This is a look at us versus our competitors in terms of, one, how much we invest and the percentage and the path of that. We have been very successful in making those investments, monetizing those investments, creating value. This is evidence of it compared to the competitive environment. One of the things that makes that possible is that we have very strong go-to-market sales and marketing efficiency. That's the frictionless model, the way the platform's designed, the way clients are able to interact with us and buy more products. And that's resulted in, despite substantial expansion of our sales and marketing investments, being efficient, which allows us to invest in our product and grow, yet also be very efficient in our margins. Now, that's a little bit of a look at the past as context. So in looking sort of forward as the last part of my presentation, I want to review what we said at the IPO and what we're doing now. And I would say, like I said, we've met our goals. At the time of the IPO, we said upper 70s of gross margin. We said, in terms of operating margin, 20%-25%. We have been smartly investing and achieved that. So that's sort of what we've done. This time, we're updating our margin target. As we've been able to balance the investment in the company with the efficiencies in the company, we're putting out a new target, a long-term target in margins of 25%+. Cash flow, we've been above operating margins in our cash flow margin. And where that goes from here, we think, well, that'll continue in 2024. We said that on the call. From there, that depends a lot on our tax rate and our cash tax, which I'll get to in a second. In terms of using this cash, our capital allocation goals have been consistent. We're generating healthy amounts of free cash flow. We want to make sure we have the flexibility to make these investments, organic or inorganic. We have been very disciplined and gotten very high returns from our acquisition strategy. We certainly look at what's out there. As you know, it's been largely focused on expanding R&D capability and our platform. We've been disciplined. We'll continue to be so about that. I mentioned tax. Right now, we are not a significant taxpayer. $20 million-$25 million we're forecasting for this year. We got an SEC comment. We put out, this time, a long-term effective tax rate. What that does is that's a theoretical tax rate as if you are not deducting stock-based comp. You don't have NOLs. That's sort of a long-term tax rate. 21% is what we put out. When that happens, we don't know. We have the stock-based comp. There's a discussion going on in Congress about the capitalization and deductibility of R&D, which is important. That'll determine when we start becoming a more substantial cash taxpayer. I would say we will maintain that premium of free cash flow over EBIT. And don't know exactly when all this is going to happen. But we'll update everybody as we understand that cash tax position. Lastly, in terms of our stock-based compensation strategy and dilution, we always balance the providing incentives to attract and retain the talent that fuels the company. We want to do that versus creating shareholder value. And so the goal that we've been operating with and we're putting out here is dilution of 2.5%-3.5%. And I think we've been pretty prudent about that. We gave a history at the bottom showing that we've had this type of target. In the last couple of years, we've ended up slightly below that. So we're watching it. Hopefully, that gives you confidence. But we also want to make sure we're providing the right incentives to our people. And that's my last comment. With that, invite up the second-half speakers and Ollie for a second Q&A session. You're going to repeat the rules? Or do you think they all can remember them? I think they can figure it out. All right. Thank you. Thank you. OK. OK. So I'll let everybody get seated. Yep. Yep. Same rules apply. OK, everybody? Let's start on David's side. All right. Over here. Eric Heath from KeyBanc. Really appreciate this. So Prashant had this great slide where I had dev on the left, security on the right, a lot more users than dev, a lot less in security. But the ability to monetize is probably much higher on the security side. So you guys have a lot of customers using your security products. But it seems like maybe you're not monetizing it to the extent you can. So Ollie and Sean, I guess a question for you. Just is this something that you think you could get more deeply penetrated with your customer base? And I know that's kind of the direction you're going, of course. But maybe it entails having a go-to-market sales overlay. So I'm curious your thoughts of how you're thinking about this to further penetrate the go-to-market into the security organization. Yeah. So the one thing I'll say on that is I think the security vendors are over-monetizing the security users right now, especially when you put that in perspective with the actual usage and the value that is being derived from those products. One thing we do and one thing that is very different about the way we sell security today is that it is all usage-based. So if our customers don't send the data or don't use the product, we don't actually get to charge them. I think it's a much healthier situation when you consider the amount of shelfware and have deployed or have used security products that are out there. As I said in the earlier session, the strategy really for us is to have the combination of bottom-up and top-down for selling to those sophisticated customers on the security side. We know there's a lot of value to be had there. We know it's a large problem. We know customers are ready to pay up for solutions that actually make a difference. So we're confident in the approach there. By the way, I'm disappointed. I was expecting a question on the tax rate for David. I'm sure we'll get that. Yeah. All right. Megan? Hi. It's Taz Koujalgi from Wedbush. A question for David on the tax rate. Going forward, when the tax rate goes up to 21%, can we foresee can we expect the free cash flow margin to come down or be lower than the operating margin? We haven't given guidance on that. Certainly, paying cash taxes will be a cash flow element that we haven't had. There's a lot of uncertainty given the stock-based comp, the share price, of course. The Congress has to when that'll happen. That will be one factor to make it more narrow. But at the same time, we've also had, as you heard on the earnings call, an extension of contract duration and strong RPO growth. So it's really the interplay of the working capital and the tax that'll determine that. Thanks. Just one follow-up for Ollie. Ollie, can you talk about the attached rate of your solutions in the installed base and what the best case is? Because I think the industry number is about 20% of the workloads that are being observed or monitored today. What does that look like for your installed base? And what is the best-case attached rate in your customers today? So the number that's usually floated and that we owe to Gartner and we all have seared into our minds is 15% of applications are being monitored with APM. I think, in our case, we have two sides of it. On the infrastructure side, typically, all workloads are monitored. Unless it's non-critical in development, all workloads are monitored. If you don't monitor it, you have no idea whether it's doing what it's supposed to do to start with. On the APM side, we actually see our customers that are deep into deploying our APM product end up instrumenting way more than the 15% that you hear about in the rest of the industry. We think, in the end, as we remove the friction from instrumenting with APM and keep delivering more value with it, I think substantially every single application, every single workload would be monitored with APM. I'll give you another example. In the latest couple of quarters, we've released a product for data streams monitoring, which looks at the way data goes through queues, the systems that are built around queues, Kafka queues, for example, and stream processing. Fundamentally, you could consider this kind of product as part of being an APM suite. But it's just not something that was covered very well by APM products before. And so as we keep going deeper and broader with our customers, we keep adding these building blocks so they can get end-to-end coverage at the application level. Great. All right. David? All right. Yeah. Thanks for all the conversations today. Will Power with Baird. A question, perhaps, for Sean. A lot of discussion around both tool and vendor consolidation. David alluded to it as well. I wonder if you could just talk about how, if at all, that changes the enterprise go-to-market motion, what's required for that type of complexity, and how important are your partners there, GSIs, et cetera? Where do you stand on those relationships? Yeah. I don't think it changes our go-to-market motion at all in enterprise. As we engage with our enterprise customers, again, it's about understanding and doing a lot of discovery with them to identify the value that they're looking for, the pains that it might be associated. Many times, those conversations will flow between different use cases. And then we'll identify solutions that may be open source or other off-the-shelf tools. And they just become part of the overall solution for the problems that they're trying to solve. I think, with our partners, it's certainly an opportunity for us. Again, we primarily have gone to market directly. But our partners obviously have some very deep relationships, especially the SIs, with large enterprises, where they're driving transformation as these companies move to cloud and just go through digital transformations. So they can definitely be a huge ally for us as we continue to progress. Great. Megan's side. Hi. It's Greg Moskowitz from Mizuho. Thanks so much for all the time and information today. Just a couple of questions on the targets. First, for Olivier, you pointed out throughout the day, as have several of your colleagues, all of the opportunity that exists for Datadog on the platform, inclusive AI, some of the new products, security, et cetera. I'm wondering if you'd be willing to just sort of discuss how long, perhaps, you see Datadog as remaining a high-growth company. Then, secondly, for David, certainly, we've seen some really good progress on the operating line. Having said that, the long-term guide of 25%+ isn't that much beyond where you wrapped up 2023. So if you could just talk to that and just the potential for additional leverage over time. Thank you. Do you want to go first, Ollie? Yeah. You can go first, yeah. Please do. Yeah. So on margins, I think we said that last year, because of the environment and also our success in optimization, that we invested slower than we expected. We got to that margin at the end of the year, the 28%. But we gave guidance for 2024 because we feel so strongly about the investment opportunities that it's more in the lower 20s%. We want to maintain whereas we think that and we know there's a lot of scalability and economies in the model, we want to maintain the flexibility, as you say, to invest against the growth opportunity and feel that and the long-term target is we didn't put a date on it. But it's where the business might be heading. But always try to balance those things and want to maintain the flexibility to make the right investments to maximize the growth of the company and add value to clients. Yeah. And look, if you look at the trajectory we've had on the margin side over the past few quarters and when we've been in the last quarter, we're already above that 25% target. And it doesn't take a lot of imagination to see how it could be even more. So there's very little doubt in our minds that, at scale, it's a very profitable business. As David said, though, there's so much opportunity and so much we want to invest in. And it is our advantage over everybody else in the field right now that we get to scale to this and go deeper and broader into the product. And we get to make all these investments on the engineering side because of the efficiency of the business. So we want to push on that. Now, your question was, how long are we going to be a high-growth company? The answer is very long. I think one question that's on people's mind is, why didn't we give a long-term target or a revenue target or something like that? And the reason for that is we're extremely ambitious in terms of what we're trying to do. I mean, I've said in my part, we think, in observability alone, there's a 5x or 10x to be had if we do it right. And then there's all this other stuff we talked about. So obviously, very large in terms of the revenue we can reach. The one thing that is specific to our business, though, is that we're built on digital transformation and cloud migration. We don't fully control that groundswell or the rate of migration of that groundswell. It's sort of difficult for us to pin that growth at the 3- or 4- or 5-year horizon and know exactly where it's going to be. That being said, we're very, very confident in the overall margin of the opportunity. Great. Itay? Hi. Thanks. Itay from Oppenheimer. Great presentation today. Thank you for all the time and effort. Question for Olivier and David is and it's the same question, but hopefully, you can answer it in two different ways, which is, if we look 3, 4 years down the road, what will be considered success for you in security? The reason I'm asking this is, in observability, clearly, you're the number one player. Even though you have a 1% share, you are the number one market share. You have the broadest platform, brand, and go-to-market. In security, you don't. You don't have the go-to-market. You don't have the brand. And the portfolio still has plenty of gaps to it. Whereas in security, there already are very established vendors with lots of those things that you're missing. So I'm trying to get my hands around, if we look three, four years down the road, are you a top five player in security in the application space? Yes? No? Maybe you can answer it, Olivier, from a qualitative standpoint. David, maybe from a quantitative standpoint. What is success for you here? Would you settle for a number seven position in the market making $300 million? Is that good enough? Yeah. So a couple of things. So quantitatively, and David can speak more to that, it has to be a meaningful part of the business, something that we discuss as part of the earnings and things like that. So that's one thing. Same thing. We want to go from the point where, right now, we're very successful at the team level with our customers, or we can be wall-to-wall in small to medium-sized customers. We want to be at a point where we can be wall-to-wall at very large customers and fulfill all of their security needs. So that's the second one. The third one is, we actually want to deliver better outcomes to our customers in security. Right now, that's not the case. With whatever they're using, they're still behind. We want to get ahead of that. I think, if we can get all of that done in a few years, we'll be in a great spot for what comes next. David, you want to explain maybe how investments so internally, when we talk about investments, when we get money from finance, it's not a gift. It's a loan. We have to pay it back with additional revenue. So you can tell a bit more about that. Thank you. I'm a numbers guy. But I'm not going to give you a number. But I will say I'll harken back to some of the other analogies. When we talked about, right now, having the business being over $2 billion with infrastructure, $1 billion, and logs and APM, the combination of getting to significant revenue, as an example, as well as the kind of penetration and attach in a meaningful way is the kinds of things that we look at as to whether we are successful. So those are without giving a number, there are some other analogies in the company that we've accomplished that are in our mind when we think about what we can do in cloud security. Great. Megan's side. Is that me? Yep. All right. Great. Thanks. Gray Powell from BTIG. So that was a good question that was just asked. And I was going to ask part of it, at least. Sticking with the security side, can you maybe talk about where your advantages lie or your differentiation within your security products? I guess I'm looking at it from two different sort of categories. The SIEM space is pretty crowded. There's been some M&A there for a couple of companies. Maybe that creates an opportunity. Then, on the CNAPP side, I mean, there are a lot of players. There's easily like 10 legit players in that space. I guess my question is, what gets customers over the hurdle to go with Datadog? And just where are you most frequently landing and seeing your initial success? I'll take that. Our biggest advantage is in the fact that we bring the observability and security data together in one place. Mostly, the people that use our products are teams that are running large-scale cloud applications. These are not corporate IT teams that are securing email servers and so on and so forth. These are revenue-generating applications. They run at a very large scale. These are all homegrown applications as well. These are not third-party applications that they run in their environments. In order to secure all of these, you need to bring the data from observability, which keeps changing all the time because they push out new changes to these applications every single day, every single day, maybe every hour. Bringing that together with the security data is the only way, we believe, there is to secure these applications properly. And I think that's where our core advantage lies, is in bringing this data together so teams can actually debug problems quickly, solve them, fix them, as opposed to having two separate silo teams that are just operating on their own, where one team goes and makes a change, and another team goes and shuts it down. OK. Great. Peter? Thank you very much. This is actually incredibly helpful. Peter Weed from Bernstein. I think, in the earlier presentation, there was an example slide put up that showed customers adopting product. And it kind of emphasizes the huge scale, obviously. And David, you just pointed it out with the existing monitoring metrics and APM and logs. When you think of all the other potential product categories that could get to that same scale and I don't mean their scale today. But I mean, proportionally that large in the organization, you might spit out and say, it's security. But it's probably unfair just to say, that's the only thing that you think could be a huge business like that. What are we missing? What are those next tent poles that would be beyond security that could be that scale that we see out of those three tent poles today? Well, if you remember the slide I had with shifting left and shifting right, there's a big opportunity on the left side with the developing and shipping and testing software. And we do some of that today already. And some of it reaches into synthetic testing, which we already have a fairly large business in. But we think there's potentially a very large opportunity there. If you look on the right side at user analytics and product analytics and, more generally speaking, business analytics, there's quite a few opportunities there, too. Again, we're barely scratching the surface of that. Today, we're building that on the back of our digital experience products and release or monitoring. But there's clearly a demand for there. And there's a whole category of products that live in that world. So we think it's potentially a large category, too. If you look at the bottom part, the Cloud Service Management, right now, there are very, very large companies that are built on this, maybe for another era or another kind of other kinds of environments. But this is also a very large opportunity in its own right. So the way we see it, there's opportunity everywhere. I think, for us, the question is being aggressive enough in terms of going after enough of it and being determined enough in developing those products over time so that they can go from being applicable to a small range of use cases to a small number of customers, go from there to being broadly applicable to the whole of our customer base. So we think these are all massive opportunities. David, any other comments? Yeah. I think that's right. When you think about not only that, but also the expansion of the observability platform itself into not only the consolidation and all, but into workflow management and the Cloud Service Management, don't forget, as Ali said, 50% of the investment in the company is in the platform. So there are many ways to add value to our clients in the platform itself. Great. Megan's side. Hey, guys. This is Koji Ikeda from Bank of America. Thanks for doing this. I have a question. Maybe it's a sales question for Sean around how you sell to the biggest enterprises out there. Think about the ones with the longest transitions to the cloud, 10-, 20-, 30-year transitions to hybrid cloud, multi-cloud, whatever it may be. How you convince them to use Datadog as a long-term solution. Clearly, Datadog is aligned as the DevSecOps platform for next-generation tech stacks. But many other vendors out there, whether it's observability or security, that's really touting a value prop of, hey, we could address the future while addressing the past. So how do you get these slower-moving customers with mega-budgets out there comfortable with taking a long-term bet with Datadog? Yep. As you see, we've been at it for a while, certainly. It really comes down to the way we go to market. We're not a heavy come-in and top-down sell. Our motion is very much find use cases that we can attach ourselves to. So even in these large organizations that may be more legacy and some of the more legacy industries, we're identifying transformative use cases that we can go in and attach ourselves to. And as you saw in some of the examples that we showed, it may take some time. But we're winning the hearts and minds of those folks as they continue to transform the organization. And then they have that epiphany where digital transformation becomes a priority. And we've embedded ourselves as the solution for doing that. And then business units grow, products grow, and they continue to grow with us. So I think we continue that motion for those companies who are not yet a Datadog customer. We're investing in that and making sure that we're putting a lot of very focused attention on getting those newest customers through how we organize our teams and kind of the motion we use with those companies. One thing I'll add to that is, many of our largest customers also look at the digital natives and how they operate in cloud environments. So they want to look at those companies and look at them as almost the pioneers of how these things need to be done. So many of those companies use Datadog as well. And that's one of the ways that we get introduced to many of these companies because they're looking to move to the cloud and use best of breed, which is us in many of these situations. All right. David's side. Hi. Yun Kim from Loop Capital. Sean, as your install base increases, obviously, your renewals become more important. It's becoming a bigger mix of your business. Any dynamics to point to that? Is that when you attempt to do a pretty big expansion pitch then, try to set it up, a bunch of use cases on the time of renewals? That's when you try to make the big pitch for expand? And then, obviously, the contract lengths are increasing. Are you seeing some of these customers who committed multi-years coming back early? As they increase their product adoption, increases, or their usage increases, especially over the last couple of quarters, and how are you addressing those types of scenarios? I think, in general, we're meeting the customers where they are. So we don't prioritize long-term deals versus short-term deals as kind of whatever the customer is interested in. That's how we're going to engage with them. Obviously, as a sales organization, we spend a lot of time in conjunction with the product teams, with the customer success team, and servicing the customer, identifying areas that they may have challenges. It kind of happens naturally. We'll hear about new use cases, which bring in new products. We'll do more proof of values or more due diligence with them around solving those problems. Then that can ultimately lead to an expansion contract. If they find that their use is strong, they may or may not come to us earlier for renewals. But again, it's mostly about the interests of the customers and how we can solve those problems. Th at's how we'll engage with them. Just to add on to that, I think that's spot on. It's really understanding the customer's outcomes, where the customer's trying to go, and delivering value against those with introducing what other products we have that can help them. You mentioned the long-term commitment to multi-year commitments. It is a trend that we have been seeing more customers moving towards, especially in this year of optimization, where customers are doubling down, where they're able to some customers are now coming out on the other side, where they're able to forecast their business a little bit more and want to double down with their growth with Datadog. Partly could be because of locking in pricing with interest rates going up and trying to prevent against inflation. It could also be because renewals take up time. And to have to go through the procurement process every year is a detractor for them as well as for us, right? It takes you away from doing the building and developing your business for growth. So it is a trend that we're seeing, customers moving towards more so. But like Sean said, not something that we're actively pushing because we want customers to do what works best for them. But if that's the way they want to partner with us, obviously, it helps support a long-term partners hip for us. Great. Megan's side. Sanjit Singh, Morgan Stanley. And thank you for all the content today. To build on Ittai's questions earlier about Datadog being the number one market share in IT ops, which is totally true, but the market being fragmented, I think that's reflective of a category that has historically been very tied to changes in compute cycles. So we never got, historically, the $10 billion company coming out of this category. And so I guess my question, as we're sort of on this dawn of a new compute cycle, and I'm sure there'll be further changes down the road, what's going to keep Datadog continuing to sort of hit the mark and be on top of all of these changes in compute cycles to keep from getting disrupted, essentially? I mean, you guys were spot on with Kubernetes and microservices. It feels like you're on top of serverless. But there'll be things to come. And what's going to be the secret sauce that keeps you on top of these compute cycles? Change being the name of the game since we started the company, I think, to your point. When we started Datadog, it was just the beginning of cloud instances. So the world was just coming off the VM, the virtual machine era, and into the cloud instance era. That was it. Containers didn't exist. Or I mean, technically, yes. You could do container-y-like things on Linux or Sun or whatever. But it was not something that was broadly used. Serverless didn't even exist. So all of that appeared later on. Today, as you saw in some of the presentations, the way infrastructure is consumed is less and less whole instances and more and more containers. You saw the annual growth of cloud instances is quite a bit lower than the annual growth in containers. So the whole computing paradigm has changed. And we had to continuously evolve with that, evolve the platform, the product, the backend, everything as well. I think we've never been in a situation like the previous generation of infrastructure monitoring products where we could rest in our laurels for 15 years within a generation of compute. Everything has been moving a lot faster. By the way, there's an interesting fact about Infrastructure Monitoring, in particular, as part of what we do. In general, it's super sticky. That's why we have these extremely high growth retention numbers. Of course, our product is great. But the category itself is sticky. It sits very low on the infrastructure. And it's really, really difficult to change because there's all these other things that are built on top of Infrastructure Monitoring. What happened to the previous generations of companies is that because it was so sticky, they didn't really have to innovate to keep their customers. And as a result, they were completely unable to build and follow what was coming next in the year. And that's why they stopped growing at some point. I think we're in a very, very different situation, as evidenced by the continuous investment we're making both in existing products and in new products. One thing I want to add to this is, look, you saw we have customers that span the gamut from large enterprises to very small, very agile companies. We believe very strongly that having a healthy mix of customers across the entire spectrum helps us keep innovating because larger customers tend to move slower and smaller customers tend to move much faster, the technology adoption. So the early signal, the leading indicators of what technologies are coming next usually come from the smaller customers. We focus very heavily on that. Our bottom-up adoption, part of it is that, just listening to customers and making sure that we are serving all of them across the spectrum as opposed to just focusing on one side or the other. Yeah. I mean, that was sort of going to be my follow-up, is that in terms of serving that mid-market, maybe SMB customer, that's still in the playbook because there's a lot of companies that talk about moving up market and large enterprise. But you guys are committed to serving that market to get that signal in terms of where the puck is going. Yeah. And look, it comes at a cost, right? I mean, it's a deliberate choice because, as I mentioned today, the bottom half of our customers represent 1% or 2% of our revenue. So one question we get sometimes is, why bother? We bother because we actually get a lot of value in terms of knowing where the world's going, what technologies are being built and adopted. And we get all of these customers, all of these small companies, or even individuals in some cases, to use our integrations with new technologies and make sure that the product does the right thing. It also pushes us to keep the product simple so that it can be easily adopted. Great. All right. David's side. Hey. Fred Havemeyer with Macquarie. I was really tempted to ask a question about tax rates also. But I think I'm going to go in a different direction and revisit what I was asking about in the call earlier this week because it was great to see more about your AI strategy. It was great to see Bits. But I think at this point, I'm meeting, I think, almost one founder a week that's building agentic startups that are trying to automate away a lot of different roles. And many of them are focused on DevOps and security and the like. And I'm not saying that any of them they're great founders. We're not saying any of the companies will actually do that. But I'm trying to understand also, if we consider a maximalist future here where, as some of them might argue, developers go away in 5, 10 years, security potentially goes away, DevSecOps is automated to an extent, how do you think and in this hypothetical, how do you think Datadog continues to exist and grows? And generally speaking, what can you do to help enterprises also continue to grow and improve how they're operating their infrastructure in such a future? Thank you. I mean, I just take off the table the future where we don't need anybody to work ever again because I think that causes us broader questions about everybody in the room. But in general, I would say the philosophy is that everything that happens in the AI, whether it's agentic or not, whether you tell the machine to build you an application or not, or it just auto-completes the code when you start writing it, all of that means you're just going to create a lot more. There's going to be humans in the loop. And they're going to create a lot more stuff. But they just won't think about it at all when they create it. They will have no idea how it works and what it does, if it actually does what it's supposed to be doing. And so a lot of the value is going to be transferred from the act of creating into the act of understanding, running, securing, fixing, et cetera, et cetera. And that's what we do. Great. We'll take one more question. Megan's side. Hi there. Lucky Schreiner with D.A. Davidson on behalf of Gil Luria. First, Ollie, I love the Nikes. If you ever want to race, name a place and time, and I'll be there. David, I think I might know the brief answer to this question, but. Why do they choose these shoes? Cut off the run. If I look at your convertible debt, I believe the stock price is now high enough for them to start converting. Maybe any short-term impact that you see from that in this quarter? No. We look at, I think most of the convert investors take, there's optionality in that. And they tend to stay in the bond. And I think it's next year there is the call feature comes in. So I think that we haven't seen any impact. And our understanding is that there is a lot of retention of the notes given the protection at the same time, getting the upside. All right. OK. Well, thank you very much. That's it for the Q&A. Thank you to our presenters for sharing our story. Thank you for you for spending four hours with us. If you want to watch it again, a replay will be available as well as the slides shortly after this event. And of course, me and the IR team, Mike and Megan, are all available for questions. So thank you very much. Have a good evening.