Hello, everyone. Thank you for joining us today. We'll be starting in about well, actually starting in about fifteen seconds. So thank you for being on time. Looking forward to going through this all with you. Just letting people add in as they come. You may have gathered on the right hand side, there is a chat function. Love to hear your questions as we go, and then, obviously, we have a q and a coming up, at the end of the session. Broadly, this is gonna be about sort of thirty five, thirty minutes of discussion as you walk through this webinar, and then we'd love to get your questions throughout, and at the end as well. We'll we're here to answer any questions you have. So let's well, let's start. This is this is wonderful. Thank you for coming. As you can tell, this is one of a a really important topic if you believe in data being valuable. This is the idea of how can you use data as a growth leader, how can you use it to identify, your biggest areas of opportunity in your business and then use it to solve problems? It's kind of a fundamental question, but, it's a thing which we know we can do better. I'm, introduce myself. I'm Ollie Hughes. I'm one of the cofounders and CEO at Count. If you don't know me before, I'd like to see a few familiar faces. We'll be hearing from Emily and Matthew from MoonPay as we go through this session. As I said, it's gonna be, a bit of both a bit of q and a and discussion with you all as you're trying to wrestle these questions, I'm assuming, and also hearing from them, hearing their story about how they've led, MoonPay has led themselves into a much more targeted focused approach to their analysis and reporting. So to tee up this conversation, to sort of set the context, I wanted to set a few kind of statements, which I I wonder if resonate with you. But firstly, I think really the most fundamental question is, that what we see in the market with the organization that we speak to is that organizations realize that data isn't enough by itself. That if you're as old as I am, we've been in data as long as I have, you remember the time when just getting a dashboard into the business was a was a huge unlock of value because that just seeing the business with data was a huge was a huge deal. This is back in the in the naughties really, so that's sadly quite a long time ago for me. And, yeah, the more data you could have, the better off the business was. Like, data was generally a kind of lever. Just having the data was a lever of value. We're no longer in this is a big maybe a big statement for to to think about, but we are no longer in that state anymore. The kind of the shift the mindset shift that we are seeing in the market is organizations now have more data than they can cope with. Data is not the problem. We have data on everything. Every single SaaS app you have gives you dashboards and metrics that you could that you could possibly cope with. Organizations have dashboards everywhere. The goal that the the the really important thing now is how to use that data well to drive focused, and and intentional value. And and that's really what we talk about today. The best companies are which I would class MoonPay in this category are the ones that are using their data to create focus, creating clarity, and using analytics to drive continuous improvement in their business, to move away from just visualizing data and instead visualizing their business and showing, where the areas of opportunity are and using data in a targeted way to find the biggest unlocks of growth and making that a reliable process rather than something which is app, ad hoc, or potentially a bit random. So that's the goal of this conversation today. We we're is that we're hoping to use this as a one of a few web webinar series to talk through how to go on that journey, how to go on a journey from big data being everywhere and confusing and almost overwhelming the business with information and getting it to the point where data is actually leading you to focus and prioritize and being having direct link between the the data you're seeing and the value you're producing. So this is this is obviously, episode one. We've got how to identify and solve your biggest business problems. We then have an upcoming webinar, which will signpost you all about when it's when it's live, about how to build a metric map, how to go through that process. We'll be hearing more about from Emily, Matthew, about how they've gone that journey at MoonPay as well. And then episode three will be then how to actually go from a metric tree to leading your organization to a truly data led culture, which doesn't mean data everywhere. It means focused, intentional analytics. These are the three we have in we have in the pipeline, but we'd love to also hear from you about what would be helpful. If you buy into this need to make data more focused to drive structure and improvement from the data that you have and make analytics more intentional, we'd love to hear what would make a difference to you as you go on this journey. That's what we would love to hear so we can play back most valuable things. So I hope that's been a helpful tee up to this conversation. Today, we're gonna be hearing from MoonPay. As I said, MoonPay are one of the organizations I think have gone on this journey one of the best. I'm sure they'll tell us that there's lots of problems and there's more they can do, but they are on this journey to leading analytics in a focused intentional way, creating a a a culture of business improvement. And we're gonna hear from their journey, hear how they've gone through that, and we're gonna look at their their pre world, their moment of of realization, how they've gone that journey, and what is meant in the business more widely. So that's kind of the signpost of the session. So enough of me talking. Let's hear from them. So, Emily, Matthew, love thank you so much for joining us and walking through this and sharing what you've learned in this session. I wonder if you could perhaps, Emily, tell us more about MoonPay, and tell us about your role, and then, Matthew, you can introduce yourself and the and how the data team kind of fits in MoonPay as well. Yeah. I'd love to. So welcome, everybody. I'm Emily. I am the director of data here at MoonPay. I've been with the company for over three years now, which is, in the crypto space as well as in tech in general quite a long time. And, yes, MoonPay is a crypto company, and we are primarily in the payment space, actually. So our main core product is ramps, and that is essentially, connecting traditional finance and fiat currency as we call it in the crypto, space, to crypto. And we're trying to onboard pretty much as many people as we can onto the crypto economy in as easy of a way as possible. We work with major players in the crypto space, including Trust Wallet, MetaMask, Bitcoin and Calm, and some other major players, especially on the wallets, area. Yeah. I've been running the team for my time here at MoonPay. We include data engineering, data science, ML, as well as, you know, kind of everything in between. But we like to call ourselves, you know, sort of like full stack data partition practitioners. I think when we, have titles that are traditionally defined, we limit ourselves. So, yeah, this is kind of the transition we've made in the past few years. Matt? Cool. Thanks, Emily. Yeah. Hi, everyone. I'm Matt. And first things first, thanks very much, Adi, and the team account for for having us. It's, yeah, hopefully, gonna be a great a great session now, and, hopefully, everyone that's that's tuned in will learn a few things as well. But, yeah, I'm Matt. I've been a senior data scientist now at MoonPay for just over three years. Emily and I joined at a similar time. So we've come through a company, which, as you can see there, we raised, series a in twenty twenty one around about the time I joined, and it's obviously grown from there at extremely fast rates, not just because of the series a, but just the crypto space as a whole, obviously, is forever evolving. My role in MoonPay has also evolved. I mean, we'll get into that a bit more later. But, when I joined, we were a very scrappy data team kind of picking up what we could wherever we could. And now I've moved more into the payment specific space, meaning that I'm helping support any sort of go to markets with new payment methods, making sure that our rails are working correctly in different, countries and with different, customer segments and just making sure that we're obviously optimizing those flows as well as we can. And as Emily mentioned, we're at our heart, our payments company, so there's a lot happening, within that space. There's a lot lot of things learning, and, obviously, that means you have a lot of data to work with, a lot of cool things and opportunities that I work on on a day to day basis. Yep. That's that's it. Thank you. Yeah. That's a that's a great background. Yeah. You have a lot of data. That's for sure. And I guess so as I mentioned earlier, what I'd love to do with you both is just sort of walk through that journey of, you know, what it was like before you realized that clarity was the thing that was missing, how you then well, like, when when did you realize that was the penny drop moment, how you went about building out sort of what we call metric maps, which is a kind of a key use case you started to go on this journey with, and then what's what's that done? So let's let's wind back the clock, I think, you know, about a year or so, you know, before we started really working together, and just tell us what it was like to be in data at MoonPay, like, what your stack was like, what it felt like to be in the data team. Because what I want people to understand, and it's I think it's a really important thing, is that you are a very data led organization. In many ways, you had you executed the, like, best in class data stack, the modern data stack. I I we wanna make Troy clear that you are the best at your trade, and you were less your trade a year ago, but there was still something missing. That's the kind of context of this conversation. Right? It wasn't that you were doing anything at all wrong in many ways. You were doing the best best in class. So maybe you could talk us through a bit of that, like, you know, before the journey started, what it was like, where you were, what you're prioritizing then. Yeah. For sure. So let me start, and then I'll I'll have Matt, pepper in his experience, on on his, on his side. When he came into to MoonPay and this is very typical. So I've I've worked at many startups, Uber, Coinbase, being amongst some of them, And each organization had very similar problems, right, with, with, a lot of data being deployed in very different ways. There's a concept of data driven culture, which does apply. But, of course, what that means practically to different people around the business is a very different thing. So what we had was was something that worked. Right? So our tech stack is, DBT primarily, into Looker for our BI tool, primarily, of course, until we got count. And then we have, in the back end, you know, airflow and GCP, which are pretty typical players. And I think the the tech stack is less relevant here mainly because that is, again, pretty standard across the board. In crypto, specifically, things move extremely fast, like, at light speed. If we compare where the crypto industry is today versus where we were even at the beginning of this particular year in twenty twenty five, so about six months give or take, it is a vastly different landscape. That's just to give an idea of what we're dealing with at MoonPay and companies like MoonPay in the crypto space where data really is the center around which you need to orient because you can be pulled in a million different directions, and you're going to have a hard time making decisions, essentially. So before, we were doing our ramps we were basically optimizing our ramps product primarily and so forth, and I would say we were doing quite well in in a lot of ways. But I think the moment, especially for me, was that I was on a period of leave, for personal reasons. And when I came back, I found it, was almost like a reset period for myself personally as the leader of the team and the leader of the function. And it was it was hard. You know? It was sort of, like, on a day to day basis, you're being pulled as leader in this much on data, but everywhere, as to in a million different directions again. And you can be looking at a thousand things and really not be looking at anything at the same time. And so that was basically when we start to look into metrics trees, and that is how we start to orient our thinking around metrics trees and also understanding, you know, when we're talking about what does success look like. Yeah. It really kinda shapes that narrative way better than before where we were, you know, sort of going across the business and identifying, of course, KPIs. That's always been the case at MoonPay. We've been very good at that, but KPIs can mean a lot of things. Right? And there's also, of course, vanity KPIs, and there's a lot of things that people are measuring towards and, you know, the sake of measurement seems like it's a success in and of itself. But if we're being completely realistic, that's not the case. So that's been the experience for from my side, at least. That's really helpful. Yeah. That's it. You because you're what I think you're describing is actually you are a quite a data literate organization. I'm I don't think you struggle with your stakeholder, the wider business querying data themselves, exploring data. Data's yeah. That that's very natural. The challenge is just the immense amount of information to troll through as you were saying. So, Matthew, maybe from your experience, obviously, you're you're you're primarily, like, running, in yeah. Thinking back to the start, you're obviously the one primarily charged with getting data into the organization. What was the day to day what was the, you know, typical week look like? How is it struck how is the time structured? What was it feeling like? It was a bit of a scary time back then for sure. So when I joined MoonPay, as I mentioned, we were very early on. The data team was small. We'd kind of hacked together some nice looking dashboards, but, ultimately, we didn't have much visibility into many things. We we were lucky that we were kind of in a good phase of the crypto market, and we were launching things. It's it was fine if the data was even a week or two late, and we could say, cool. Things look great. But, ultimately, there's no way you can actually launch products and run a business. So we kinda went through the stage where we didn't have much visibility, and then it quickly ballooned into this phase where we had almost too much data. And that's kind of what Emily was alluding to is we had too much. We had to sort through things that were kind of popping up here and there from different stakeholders and trying to juggle that and find out, you know, what was actually important, what was driving the business forward was incredibly difficult. So kind of my time move pay is almost in three phases. The first stage, not enough data at all. So hard to actually help, you know, guide the business. Then into the stage of, you know, almost peak euphoria of we have data. It's amazing. Let's get as much as possible as we can into Slack, which was also just then on a day to day basis, you know, also extremely difficult. Things used to happen. There'll be a one or two percent dip in one metric, and it'll be all hands on deck, which took away, you know, the whole data team's time and took us away from the more important things of our day to day jobs. And now we've gotten to the stage, thanks to the metrics tree, thanks to kind of a lot of change that Emily has made within the team where we've, you know, trimmed down this data and, you know, can focus on what's important. And then from there, the data scientist go into that and actually apply our knowledge into streamlining things and finding what's important rather than just throwing, you know, paint on the wall or seeing what sticks type thing. So, yeah, that's kind of been my experience so far and a lot more orderly and a lot a lot more focused now, which is great. That's that's great. We'll we'll definitely come on to the metric tree and how you built it. If there's if one one question I was gonna ask you, which is, maybe hard to answer, but just sort of for someone listening in the audience who's like, I feel we might be in the same situation as you, that we have too much data. Like, can you think of a kind of a, like, a a litmus test of, like, how you would they would know they're in that state? Like, what would you if you look back and think about what I was doing then or what we were doing as an organization then, which really was a was a was a warning sign to us that there's something wrong. Like, can you think about what that might be? Yeah. From my perspective, it really is a feeling. And I think sometimes, you know, being data people, our instinct is sort of like, let's ignore that feeling and look at the numbers. But I think in this particular case, we really do need to just lean into the feeling. We'll be like, if this feels not great, then it's probably not great. There's something wrong. You know? And I think it's hard because exactly as I said in in the startup space, not as in the crypto space, but in startups in general, that is sort of par for course. Right? You're still, like, every day is a little bit chaotic because that's the nature of being a startup. I mean, if we wanted to work someplace that was super structured and and clean and and is a nine to five, we wouldn't be here. And so it comes, you know, part and parcel of the job. However, I think there's, a a it's sort of like a like a tipping point in which you're sort of like, you know what? This is not sustainable. So I think Matt can also speak to this as well, but exactly as he said, the problem with not having that structure and we're not giving ourselves that structure. And for myself, this is exactly right as leader as well as, I know that Matt had this experience on the ground. Right? That you're just feeling so overloaded, which is very typical of most data teams, especially at the very beginning. And, that was essentially sort of the place where I'm just like, this is not sustainable. We're gonna go burnout. There's massive risk there, and that is not the intention. Right? As a leader, I don't want my people to burn out, one. Two, I don't want myself to burn out. And three, it was also one of those things where, exactly the sick we we keep harping on on, basically, is that it just didn't have that much focus. And so I was sort of like, okay. How can I give myself focus? How can I give my team focus? And how can we therefore also give the business focus? Yeah. And I think there's also something to be said here about also claiming that ownership is super important as a data team. Think, again, in typical, in typical startups or actually most companies, actually, because data especially at bigger companies, in fact, this is even more of a problem or more of a more of a how do I say it? Like yeah. It it harder to uncover, let's say. It's because data has typically been a sort of sub team or support team that people go to, and then their expectation is that they the data team just answers. Yeah. And that is extremely problematic because, actually, all the knowledge sits on the data team. And so you're asking the data team to simply be servants in some sense, which is I mean, maybe service isn't the best word, but, like, that's essentially what it felt like to some extent. I remember early in my career that was exactly what it felt like. Yeah. I mean, that's not the best use. It's also very, yeah, it's a bit of a waste, to be honest, of the skill sets that are available and the capacities that are available on the team. And so, essentially, what we want to do is make sure that, that feeling, again, right, is is sort of alleviated. And and there's a way to do that where, exactly as we've, you know, been talking about today that you can just say, you know what? I'm gonna claim. I'm gonna reclaim my ownership. I'm gonna reclaim my place. You know? If I wanna sit at the table, I wanna influence. I wanna I wanna maximize my impact. I wanna maximize my team's impact. That's all on me. I need to make sure that I take control of that, and that is essentially where we ended up. I think that's really helpful. Yes. So I think one of the ways we often hear about talk about is the idea of, like, not being on the hamster wheel. Because the if you're just if the data's not data's not giving structure to the business to help prioritize, then your main outcome is the faster I can produce insights, the more the business might grow. But it's it's non it's nonlinear direct correlation because if you just keep doing stuff, it doesn't necessarily drive more quality of outcome. And what you're describing there is giving yourselves time to think and a time to say, actually, the role of the data team, in this case, for you, was to give structure clarity to allow the business to see itself. But anyway, we're getting ahead of ourselves. This is wonderful. Thank you so much for sharing that because I think it's really helpful people listening to hear, you know, where they where they might be able to sense that they're in the same spot as you you were in. Let let's move on. Let's talk more about then you mentioned a bit bit before this kind of moment of clarity when you realized that you sort of had a chance to introspect. Emily said you're away for a bit and you came back, and you sort of had a chance to go, this isn't right. We need to make a change. We just started looking at metrics as a solution. But what was that moment? Where did you what was that thought process you went from when you realized that it needed to be a change that you could see a better way to go about things? Yeah. So to be completely forward, the team had already been talking about so one of my managers, Shannon Sass, she had discovered metrics trees, a couple months prior to us sort of starting this, and we were sort of orienting more and more towards that model. We just didn't have the resources we thought at the time in order to do so and really dedicate time to it. And so the thought process was essentially, okay. What are the problems that we're facing? And we basically, I listed the all of them out, and there were there was a pretty long list. But as is usual. Right? I mean, it the work is never done in a lot of ways. And I would like actually Matt to to to pepper in as well, like, what life was like, you know, what we had, the sort of swirl and the thrash that we tended to have. And then we we basically came to the conclusion, like, you know what? I think that having a metrics tree would strategically solve about eighty percent of these problems, which is a pretty good, you know, coverage and batting average, I would say. Yeah. That I mean, that that idea of, like, we've give I think one of the things you said to me I've I've always thought as before was the idea that if if the data team doesn't know what's going on in business, then how can anyone ask? And I always have always loved that phrase of the idea of, like, the data team is unique because you have data across the entire organization in one place, and then it's your job to then visualize it first the business to feel that feel that clarity too. So, Matt, what I mean, tell yeah. So was it was it a hard sell then from Emily's perspective to try and get you to start building into this stuff kind of stuff? When did it click for you? Not at all. And kind of going back to the previous question about when we realized that, you know, things maybe needed to change or we've kinda reached this point where where things weren't exactly going as we wanted to in the data team is we got to a stage where we, as data scientists, were never able to spend any time on on the real, like, juicier problems, and we were spending all our time kind of debugging, trying to find issues with with certain launches, what's been going wrong in in different places of the business. And all of these took ages, and it was just one of those where I would get to the end of the week, and my manager, Emily, would be like, what did you do? And we would list out we've, you know, we were in this incident. We're looking to this x y zed, but we're never actually getting to the things that we really wanted to get to and the things that, as data scientists, I think, excite us. Right? Like, we don't want to be debugging and looking at dashboards every day. We wanna be, you know, focusing on how we can drive the business forward. So we we're in the state where it was very difficult to to look into issues or, you know, as I said, we had too many dashboards. We had too much going on. We had different stakeholders sharing different things from different sources, and even matching those up made our lives difficult. So when the metric tree idea came around, it was kind of one of these things. Okay. Cool. Like, we can very easily show it to the rest of the organization. This is this is what's gone wrong where, and then we can either enable them to go dig into further or very quickly allow us as data scientists to dig into it further and and hopefully resolve any problems as quickly as possible. And tell you what, so we mentioned before that you there was inkling in the wider business that Metatree could be really powerful. Was there you mentioned a lot about what it felt like to be in the data team just doing tasks without feeling an outcome. What what would the what was the wider business saying to you about, and what was the perception of the data team as well? Because, obviously, if you're feeling pain, I'm sure your organization was feeling some other pain as well. I don't know if you wanna take this one. Go for it. Yeah. So the rest of the org, luckily, as you as you mentioned, I mean, Pay is quite a data driven organization, and we've we've we've got to a position where we're in a great place. And the metric g in itself did make a lot more sense to everyone. We were coming from a place where we were losing out a lot of opportunities. And because of the crypto space moving so quickly, it was it was not small, you know, mistakes that you make if you if you miss, like, a percentage or two in, like, one certain launch in a region or whatever it may be. And the metric tree was quite an easy solve, you know, how we can drill down things and get to the bottom of things a lot quicker. And and most importantly, very clearly, you know, indicates the rest of the business what's going on and why it's gone wrong, rather than throwing a bunch of different, you know, hypotheses together and and hoping one sticks. Like, the data is there. The numbers are there. So, ultimately, having the data and numbers in a clear state was just like a huge help to to also help us prioritize what to look into and also help, you know, them, you know, direct an engineering resource, whatever needs to be directed to. Product managers can step in and get involved a bit more because they had the support now from the leadership team who could see, okay, if this is down, we need you to to to jump into this, and it wasn't a kind of a a fight to get people to look into things. It was actually people coming to us and wanting to to get involved because they'd seen the numbers on their side. Yeah. I'm just actually gonna bring up because I think we're talking about metrics. I should show this is not this is a a demo metric tree, but just to give someone give us both a kind of all of us are kind of a visual interpretation of metric trees just so you can see what we're talking about and the the principle of this. I mean, you mentioned before, Matthew, that one of the powers of this is it lets you just organize metrics in a hierarchical way so you can drill down on this kind of hero metric and and see what is the driving force of of the changes you're seeing, see how the business fits together, understand which lever is gonna have the highest impact to a particular KPI. And you're you're you're you're giving metrics a hierarchy that you can't on a dashboard. Right? So you're giving that that structure. Maybe you could talk us through now, like, how you went about building this? Because one of the things we often get asked, people love the idea of metric trees, but actually the question is, well, how do you build one? How do you get the business to buy into the hierarchy that you build? Can you talk us through how you went about it? You obviously had a degree of interest that they understood, at least in theory, but how did you go about building one? How did the organization lean in and grip it? When did they get really excited? Yeah. So, actually, we did it, in a sort of bottoms up approach. The reason why I did this and this goes back again to the ownership piece I was just speaking about where data, we really do need to stop deferring to others. We are the experts in a lot of ways. And so when we went to build this tree that we have, which, again, I think some of you have been asking, you know, can we see are you a sample? We will be showing a a a sample of ours. We really kept it to the team to determine. So each data scientist was assigned essentially an area. Well, they were every data scientist on our team is already assigned an area. And so for their area, they were basically tasked with coming up with one to two, absolute max two, metrics that they thought should go on the tree. And then we all got together and took about, I wanna say, about six weeks from end to end to decide exactly how we were gonna break everything down. Our North Star is pretty easy because that does come from our company OKRs, so that that works really well for us. But, you know, that is revenue and profits, which I think for every business is the case except for nonprofits. So, you know, that is also why we decided to build a tree because there's always a question of, like, what is driving revenue. And a million pays, as we we all know, can be driving revenue. And that's exactly as we were talking about about the investigations and sort of the bugs and incidents that we were that we were encountering was that it was so hard to understand what exactly is the root cause of the movement. And sometimes, maybe we don't even care that much. Right? And let's just be completely honest. Not everything reserves, needs to be looked at, and it creates a lot of, just, like, missed spent resources when we don't have that level of clarity. So that is essentially how we approached our tree. Mhmm. We came together as a team and essentially established these look good. And then everyone has ownership again. Each data scientist has ownership over one at least one, sometimes a collection of the metrics on the tree. So what we do, and Matt can speak to this about how this works on my day to day, is that we do monitor what's going on, and it becomes a lot easier to do a couple things, which is one, troubleshoot. But two is also equally as important. And that when we go to build and, develop parts of our product, we're no longer sort of like, okay. Well, what is this supposed to do? We have a metric on the tree that we want to explicitly move, and we want to make sure that that is very clear. Because if you're talking about wanting to increase your user base, that is a very different conversation than needing to improve your transaction success as an example. Mhmm. And so that's also another way that we've used the tree in order to make sure and, actually, we that was one of the requirements of the tree that we were able to use it for that purpose and and many use cases like that. That's great, Matthew. Was and so you were you were actually in the weeds of building it out. Tell us more about your your the the kind of the actual execution of building it and how you got your your wireless stakeholders to get excited as well. Yeah. So we were quite lucky because when we really started getting into building metric tree, we were actually at an off-site, a company wide off-site. So the whole data team we're we're a remote first company, so we're not always in person. So the whole data team was together in a room, and each data scientist kind of has a domain specialty. So I'm within payments. There's someone that's more, you know, related to compliance, maybe someone else on cut the customer acquisition side. And we at least had the chance to come together in person and and really, you know, discuss what drives our specific part of the business and also then how they will interact with each other within the tree. So we we came together and we obviously hacked this out. We we started over that week. We got pretty fun. As Lemmy said, then over the next six weeks, we kind of ironed it out, made sure it's working well. Initially, we tried to do it in a looker, which was a mess. So we've got, like, a very basic one in Looker, and it it does a certain job. But, fortunately, around about this time, we were onboarding, accounts in US, so we we very quickly migrated this to accounts. And that made our life a lot easier to to get that into kind of the format we wanted. It's something a lot neater. I'm gonna show it to all of you a bit later, just that kind of a version of ours. And, yeah, it's that first look at section probably set us back a week or two, but after that, it was a bit more smooth sailing once we'd, put it onto account canvas, which was great. And then tell us tell us how you you got the wider company. I think I can remember a story you told me before about how you I think you presented a metric treat on all hands, company all hands meeting and everyone got super excited. So, clearly, as soon as people started seeing it, you really there was an elevation of understanding across the wider MoonPay organization. Tell us the kind of reception. And it and it's also worth mentioning what you said there before, which is like, you took six weeks in total, but you got a long way in a week. And And it's an it's an evolution. Like, the part of the benefit building one is it it you can evolve it. It's not set in stone. You're you're you're going through a kind of an organization clarity exercise as you build it out. You're left with a reporting structure, but the journey as well as is important. Sorry. That's me just summarizing what you said. But tell us more about the the way the company gripped it and how they received it as well. Yeah. So, I mean, the intention actually, so, Jayesh, I think you have a question that's very similar to this question as well. It's like, what what now? What after the metrics tree? Right? So a couple pieces to this answer that I want to make sure that, everyone does kinda learn from, because we it was a bit of a a road for us. And to be honest, like, we presented it. Everyone looked like everyone had had great reception. And we surprisingly you know, I had some questions just to, like, oh, did you get buy in from exec leadership, for example? To be honest, no. I think the clarity needs to come from us. Right? I think that that is also part of the the next steps as well is that so we had very good reception when we presented this and we released it and so forth. If we're completely honest, however, it was sort of like, that's cool, and then it was just kind of that. That was it. So what we had to do on the day team, and Matt can speak to this as well when working with PMs more more directly, is that we had to make sure we were the first front, like, line of defense. And we were the ones who needed to push for what is the success metric here? What are we trying to move? What has gone wrong? What has you know, what do we need to work on? Where do we need to optimize? And all of those things. We were becoming the ones who were asking the business those questions as opposed to the opposite. So it really gave us leverage as a data team to be part of those conversations, not just be part of them. Sorry. Drive them. Instead of a PM or exec leader, whoever, coming to us and asking, what happened with conversion rate, let's just say. We're the ones who are saying, excuse me. Conversion rate has been dropping or what have you for the past four weeks. How do we fix this? What's going on? And that is another way, of course, that we've also gone buy in tacitly, let's just say. Because when you're pointing out and calling up things and also driving things forward in in both ways, so to take more of a positive stance on that, what ends up happening is that everyone starts to look to the data team, which is exactly what happened, to help them understand how they're going to maximize their impact on the business as well. And, of course, collectively, we're improving the business overall. Right? And so that's, I guess, to your answer, Jayesh, is, like, how do we shift our focus? That's basically it. It's like the irony about being a data team is that once you have these processes in place and you're essentially controlling the narrative, in the way that you want and that you think are the most valuable, which are going to be the most valuable because you have the most information at your hand, right, is that you can start to become this weird hybrid. Like, we're we're actually playing around with, like, different words for describing what data does because we're not really even a data team anymore. It's like somewhere in between science and information and strategy, and that's basically the ideal situation, right, where the data function essentially becomes a foundation, and the technical skills we require are absolutely, you know, necessary for us to continue to improve our craft. But we are focused more on the outcomes as opposed to the output, and that is, you know, more and more of what we're starting to do as well. I'm just gonna bring up because I think what you're describing so nicely, is there is this this slide here, Emily, which is what we call the improvement cycle encounter. It can be called many different things. You see in almost every, in in in every loads of different sort of business improvement frameworks about how to drive insight. It's basically a scientific method. As you say, it's not science. The idea of, like, when identifying opportunities, exploring and making solutions, making a decision, and monitoring the change. And what you're describing there is the identify step is where the metric tree sits so well. It's like, let's make sure we understand what's really going on, where there are problems, why is that metric dropped for for a period of time, and the data team can then drive well, encourage the wider business to start strategizing on how to solve that problem in the explore phase and reach a decision. And that's the wonderful thing about what you described there. It's not just doing a metric and saying, here you go. It's then what you described there was how you then use it to drive conversations to basically talk take the business round this loop as fast as possible. So I think I hope that was helpful. I'm not trying to I think it's what you were saying, but just put it to a diagram. That's really cool. And and so, you mentioned also something which is really powerful there, which is that your the role of data team has now changed, and I think it's a really helpful power interest that you've gone from being, as Matthew was describing, like, building, doing tasks, doing analysis, bug fixing, building dashboards, very transactional, unsure of the outcome. And now what you've described is actually you might even change the title because you're just you're now operating at a strategic problem solving level, and that has to be one of the most exciting things I've heard. It's such a great thing to see that shift that by by clarification and then leading them through the problem solving diagnosis stages, you're you're you're you're driving change, which is really cool. Is there anything else I missed on this on this kind of outcome? Because I think the key is that, as you've already say, Metrodigies alone are just a report in a in a very clear way, but the the the fallout is you are you are actually driving driving change as a result of it and focusing on the right areas. Yeah. I think you you nailed it. Cool. Well, I mean, so let's let's move on from this. Let me stop sharing that these slides. And, Matthew, maybe you can talk through your yeah. You're you're wonderfully sharing a kind of a demo, a a sort of a a demo version of your metric tree. Obviously, the data is completely random and and anonymized, but show us more metric tree. Talk us through it in count. And then we can maybe spend a bit of time just talking through some of those so some of those improvement cycle journeys. Like, what have you what has fell out? What has fallen out of doing this kind of work? Sure. Yeah. I'm just gonna dive into into our canvas. Yeah. As as Ali may mentioned, it's it's all randomized data, but this is essentially kind of what we've landed on at our metric tree of late. And you'll kind of see a kind of some examples of of how stakeholders will come in and and, you know, be able to decide for themselves or see for themselves what's going wrong and then, obviously, also help us as data scientists dive into things. So as Emily mentioned, at the very well, actually, first things first, for, like, our account dashboards, we we like to keep things pretty clean. So we have, you know, pretty descriptive stuff going on just so if anyone's coming to this metric tree for the first time, they've never heard of a metric tree, they can actually, you know, quickly understand or read up about what it is and and how people use it and what exactly it's measuring. And in this instance, as Emily mentioned, our NorthStar metric is revenue. So what we have, for this metrics tree is comparing the last twenty eight days versus twenty eight days before that. And we split the metric tree almost into two sides. So we have a cut a customer focused side and a transaction focused side. And this goes back to what I was saying about how when we first came together as a team to figure out, you know, how we're gonna build this thing, Each data scientist that kind of owns a certain pillar within the organization, there's a few of us on transaction side, a few of us on the customer side. We had to kind of go off onto our own sides, chat on what's important, and then be able to bring that together to see how that actually impacts revenue. So we essentially came up with almost a formula of sorts of of how revenue is driven at MoonPay. And what we came to is we obviously have revenue, which is essentially a combination of our monthly transaction you transacting users and our average revenue per user. And these metrics themselves were if we originally used to look at this and you thought to get MTUs or down month to month, so, obviously, this dummy data is down forty two percent, that would raise alarm bells. But where to go from there? So, historically, it was very complicated. I don't even know. I can't even remember how he did it. Maybe I blocked it on my memory. But, essentially, we would maybe, you know, say, okay. What are key regions? What's gone wrong in a key region? We'd look into that, see if anything's weird. It would take ages to kind of get to the bottom of things, whereas now you can very quickly kind of just follow this path on on what's actually driving each step. So we break down our MTUs further, so new and returning, and then we break our new and returning into their respective, basically conversion steps or, you know, are they where they're dropping off, are they not coming back, and what's the reason? So quickly, I'm just gonna run through things, not spend too much time, though. But for instance, new MTUs, we look at, you know, who's getting converted and who's coming coming back, essentially. And then we break that down to respect to conversion rates. On the returning MTU side, we've got our retained MTUs. So the ones that, you know, from the last month we're bringing back and our resurrected ones, which essentially are the ones that, you know, hadn't transacted for a certain period and are now back and further break that down. And what this enables us to do on each side is you could quickly dis distinguish which is the driver of these two and quickly go to the essentially, all the way to the bottom. And what we found now on debugging things is or looking into, you know, what's gone wrong is it might not just be one of these. Obviously, it can be a combination of things, but at least it directs you where to look because there's a bunch of things happening with within each of these. We have different partners, different regions, different customer types, but it makes your life significantly a lot easier to to quickly be able to say, okay. It's our new customers with a problem and their conversion's down, and then figure out what where in the world and what type of product what segment segment of our product is it down, for example. Then on the right hand side I'm sorry. I can't see your face. If you wanna jump in, just No. No. This is amazing. I think I think you're just it's so it's so great to see you see a real life example. And, obviously, these metrics are quite specific to MoonPay, but it could be Yeah. What you're doing here is taking the metrics that matter then and then breaking them breaking them down dimensionally to make sure they're always self consistent and they add up to the level above. Exactly. And and within each kind of product in MoonPay, you can actually have its own metric tree within that. Right? So this is, like, kind of the company wide one, which is awesome and enables us as the company to see what's going on. Especially as MoonPay grows, right, we have different products and different things coming out that will maybe require their own metric tree. And in a way, it could fall into one of these, obviously. But, yeah, ultimately, you've gotta adapt it to what your business needs. Yeah. I like that. So you're saying that, actually, you can you can keep going down the tree. It may not be practical to have it at all every metric of the business in one view. But when you get to a certain level, like, new customers, you can then go to metric two, which is more about marketing and the the lead the the acquisition funnel and break those metrics down even further. Like so you you can keep going, and the further you go down, the the, you know, the more tactical more operational you're going. But you, you may not share it all in this place, but you yeah. It's the same principle all the way through from the highest level down to the lowest level. So how far have you I mean, you mentioned that. Have you got, a metric for each product now, MoonPay as well? How far have you gone with the rollout of these things? No. So we haven't. So I think, I think, Tian, you have you have a question actually that's very much about this. We can. As Matt said, like, it is very possible as you simp as well, Ollie. We can. We actually created the upper level metrics tree by design, and we maximized it. The reason for this, and this is, again, you know, different depending on your organization, is that we know at MoonPay specifically, within our own organization, it can create too much noise. Right? So going back to what we were talking about at the very beginning of this session, the problem was that we had a lot of data. And so we really wanted to limit it to just those on the high level tree. If it comes to the place in which we think that there is, a need for a more specific tree, again, I think marketing is a great candidate for that because there are a lot of, there are a lot of data points that are not present on the tree that are very important. Yeah. That is very much possible, but it does depend on your organization for sure. And for us, this is actually something I wrote in the chat. Again, going back to the piece of ownership, I wanna say ownership paired with controlling the narrative. I think it's very important for data the data team and for yourself even as much as we want everything to be as self-service as as possible. There's a very fine line between self-service and chaos. Right? Because you can imagine that when everybody is is, is querying the data, you know, they're making their own stories. And that can be extremely problematic, I think, as most people in this webinar probably experienced. And so that's also another reason why we kept it to just this tree because it enables us to say, hey, guys. Like, this is the main story. Maybe you have some side stories. Maybe you're going on a choose your own adventure. That's totally fine. But, officially, this is what this is, and that's, again, by design. Yeah. And and just building on that. So as I mentioned earlier, I'm in I'm involved in, like, the payment side. So this transaction success rate tile is is my baby pretty much. And I I have my own metric tree for this, specifically for the transaction success rate. I don't it's it's available for everyone to see, but it's not something I broadly push on everyone because it as Emily said, then you might be overloading overloading, you know, stakeholders or relevant parties of of what's happening. But it does make my life easier that when this metric is down, I can quickly then go and see what's wrong. And then for my stakeholders that are a bit more data savvy, they also know that it's there, and they can also, you know, look into things as needed. But as, like, on a on a wider business scope, we kinda stick to this because it's it's quite easy for someone to see. Obviously, these numbers are very extreme, but, normally, what we like to see, obviously, is some small changes here and there. And then you maybe have one that's a bit more extreme that then pushes you where to look. And then each data scientist within their domain often has their own metric tree or some sort of dashboard or count canvas in a way that that helps them quickly debug things and and, you know, get to the bottom of the wrong way. You're just driving focus. You're driving focus. You're trying to make sure people understand what's statistically relevant, what isn't, where to go if they wanna be be and you're removing questions which are kind of guessing questions. Why has this changed? You're actually giving that answer without even even being involved as well. That's really cool. Before we move on, I wanna actually have time for q and a. Is there any I'd love to just if you can is there any examples where you can paint that kind of full improvement cycle where you had a metric tree, you saw a magic change, and it led to a business outcome all the way through? And that could be a big thing, a small thing, just to help people understand that kind of vision of that. It is a it is a it is a it is a process, not just an output. Yeah. Actually, sorry. Matt, can you share the share the screen? I mean, this is anonymized data, but, there is an example that's very similar that we can speak to. So here, for example, again, in theory, what we'll say is like, hey. Revenue is down eighty three percent. Obviously, that's a massive problem. So if we zoom out, this is how we would approach this problem. We'd say, okay. Is it coming from MTUs, or is it coming from ARPU? In this case, it's, both. Can you zoom in? Sorry. In this case, ARPU is twenty seven percent. MTUs is forty two percent. Okay. So there's obviously two big problems. And in this case, we would split the team. I would say, hey, guys. Whoever is on the MTU side, please take a look. And we break that down as well. We look at returning. Returning's fine. Returning are actually really, really good. So the problem is mainly on new MTUs. And when we look at this, again, we just continue to go go down in each branch, and we say, okay. Where is the main problem coming from? And it is coming from In the sense because the data is random. It's not gonna Oh, yeah. That's right. It's not gonna make sense. So but in theory, you kind of I think you get the the gist of what we're trying to get at. Right? And this is this is happening pretty much on a weekly basis, sometimes on a daily basis, depending on what we're looking for and what we're trying to get at. So it depends on, you know, if we're paying particular attention to specific partners, specific regions. And it really, again, rallies everyone to say, hey. Instead of us you know, previously, when we didn't have the tree and there was something that went wrong with revenue, we we would know because that would go down very obviously. But when we went to investigate, we'd be like, where do you even begin? How do you tackle your entire warehouse to figure out where this where this problem starts? In this case, we can say, you know what? We can ignore returning MTUs. We can't. Yeah. We can ignore, transaction success rate. Let's just say, we need to focus, however, on traffic or, ARPU or net margin or COGS, etcetera. And so, and, again, that's another way for us to bring it to the the the exec leadership or decision makers too. Right? So if I go to the exec leadership and I say, hey. Revenue's down. That's it. Right? I mean, that that is not a great answer. And then they lose trust in me. They lose trust in my team. They it's it's extremely problematic. This way, I can say, hey, guys. I know we've identified that there's a problem with the MTUs. Revenue went down because of MTUs. We found out that it was because of this particular partner. We didn't have as much traffic. We're working on it. There's a campaign going out. We're doing x y zed. And, again, you can just say the problems we fixed and such, or if there's a bigger problem that requires, you know, higher levels of decision makers to get involved, then it's a very clear sort of, like, what do you want us to do, a or b, as opposed to presenting them with a whole bevy of of issues that they're just sort of like, I'm exasperated. I mean, we're also exasperated even investigating. So, yeah, that's essentially kind of how we use the tree today. And then kind of building on a a real life example, we had one recently where we had a particular region, which had a sharp drop in in, basically, in revenue. So we saw the metric tree was down. We while the revenue was down, we kinda got to the bottom of it, and we went off and explored, and we determined that it was a particular country. And that allowed us then to filter this this dashboard for that particular country, and we could then quickly figure out, okay, that particular country is down because of, you know, one of these respective tiles. And that, you know, took the the investigation, which would have historically been extremely difficult because you would have had to get teams from this transaction side and this customer side involved from the start. What happened is actually, again, in this instance, Emily raised it, but there is there has been multiple times when the PMs actually said, okay, guys. The metric tree is down on the left hand side because of new customer conversion rates. What's going on here? And then we could quickly dive into that and figure it out. So that happened in a particular country recently. Another one that springs to mind is we released a new addition a new version of our app, and the flow on that just wasn't working as expected. And, essentially, we had a few parts of this metric tree that had shown significant dips or or problems. And something that's on that scale when our app our app is a revenue driver for us, you know, a few days of problems is a lot of money, cost the business. And, historically, that kind of piles pressure on everyone. Of course, you got the PMs that are getting shouted at by leadership. The PMs are then shouting to data scientists. It's just all chaos. And then but, essentially, because of the metric tree, we managed to resolve that in a much, much quicker, process. And at the very least, we could say to them, look, we know what's wrong. We're investigating it. This is what's wrong, and we're we're gonna get it fixed out for it. But historically, even getting to the stage of pinpointing what's wrong took too long, and that's when people get stressed because then they don't know what it is. It could be anything. And historically, that was our main issue of just trying to get to that point, which then makes everybody obviously upset or frustrated. Just removing the guesswork. That's why Exactly. Well, the when people get stressed, guessing starts happening and pet ideas come out of the woodwork, and that that's even worse. So you're done working on the wrong things. Both, this has been an incredible walk with you. Thank you so much for sharing that metric as well and just sort of re bring it to life. There are a lot of questions. I think, Amade, you've been giving me a hero's effort of answering someone already, which I'm really grateful to you about. That makes my life enormously easy. Before we move on to the QAs, I just wanna share just to make sure we in case people know, I wanna share that we, so you can get going with Build Your Emmetric Tree step by step. There's actually a tutorial we have in the CAL platform, which walks you through the full journey that, Emily and Matthew were were describing of, like, scoping it out together, doing the analysis, working out the data gaps you might have, building a metric tree, iterating it. You can build those directly in Cal now with a free account. You go to camel co slash sign up. You can give it a go and follow on on a template for that. You can see our websites full of lots of metric examples and other metric maps, which are not just for revenue, but could be for any conversion funnel you're building. There then this concept of metric trees extends to any part of your your business. And, obviously, we will be sending you all as part of the wrap up of the webinar, the plan for the second webinar of the series, which is gonna be how to build your metric tree in count tangibly. So, hopefully, that's that's helping you with some of these questions, and make sure you don't feel you're left your own. We've got our loads of results to help you get going as you wanna go on the same journey as Emily and Matthew did. So that's that's it for, the the kind of walking through this. Emily, Matthew, thanks so much so far for getting into this. Now let's get some of the let's please ask us questions you'd love us to to dig into, and, and how we can help you think through this for yourselves as then go on that journey. So, let me just pull up some of the questions we've had so far, and then, I'll I'll deal with the ones we haven't had an answer to quite yet. I think that I think you've just got us a bit both of you. Just the idea of Justin's asking, can you explain a bit more about how metric how the metric here was structured? How did it did you have lots of iterations? Because you you mentioned there, Matthew, for example, that you you filtered by country, but you could have split revenue by country as the first level. Does that matter? Did it did you did that was that a bit was that one of the things you had to think through, like, one of the one of the splits that you're doing it by? Yeah. So the the original idea of the metrics tree, of course, we mentioned a few times just to keep it a bit simpler for someone to come in to to take to grasp. And we thought about splitting it by a few different things, and we do have versions which have split sets. But, ultimately, when we have too many splits that are coming from, you know, over I don't know how many countries we have. Over, yeah, over fifty countries, you know, then then it Like a hundred and seventy, I think it was, actually. Crazy. So as soon as that happens, then it kinda takes away from what the metrics she's trying to, trying to do. And, ultimately, as a as a data scientist, it was very easy for us to come and come and filter it and or we have our other kind of methods to to then quickly identify what's going wrong in what region and then filter as needed rather than giving everyone too much data and then asking them to just just sift through from there. That makes sense. I'm actually gonna tackle a couple of questions in one go. I'm gonna give this a try. So it's like, how did you start building I think Haroon's question, mentioned a bottom up approach as well as what percent of your metrics would say are most common to the business. So these, I think, are not really wrapped up and together, but let me give it this a try. Alright. Yeah. Go for it. I'm gonna start with a bottoms up approach. I mentioned that yes. So part of it is, exactly as Matt had just ref has has, alluded to is that we did have a few requirements, right, which was that, actually, the first instance of building this tree is for the company, but it was meant to be operational for the data team. And that's why we took a balanced approach because we are the ones, again, who are catching all the strays. Right? We were like, oh, we need to figure this out. We need to figure that out, etcetera. And so it was mainly meant for us to mobilize as quickly as we possibly could without having to depend on a million different resources, too many cooks in the kitchen, and that is also why it's constructed that way. And so it is for the company, but it's also mainly for the team. It just happens to be, which is again by design to be fair, that, you know, it does translate upwards, and that is also the way that we're driving the again, the narrative. I keep harping on that because we're the ones who are sort of like, okay. You want us to own this? We'll own it. We'll own it end to end, and this is how we're gonna drive things forward. Yeah. And so that also goes to, you know, what percentage of the metrics would you say are common to most business? I would say a hundred percent in a lot of ways. This is also again by design, though. It's mainly because when we're talking to stakeholders around the business, there are levels of, data literacy. And when we get into minutiae that are too specific, let's say, to crypto, as you know, we do have, like, metrics that are around crypto in and of itself, but they're not really translatable to the entire business. And so that's also why we made a conscious choice to choose metrics that were very easily understandable with, you know, some parameters that we have to put in place. Of course, the parameters are very specific to us, by anybody around the business so that if it came to the time and when it comes to, which is kind of the era we are in today where a lot of people are looking for tree, we're able to say, you know, that they can do this on their own. They don't need, you know, anybody else on the data team to say, well, it's actually the denominators, you know, filtered by x y zed and and so forth, and that makes it a lot harder. I I I think that's that's really helpful, and you've nailed those two questions well. I think the, the other thing I wanna just make sure I remind people when you were to talk about the journey is that you do structure the data team by area, by business area so that there's an implicit by getting the different parts of the data team to build their own parts of the tree. You are aligning the metrics to ownership of this of the organization. So, you know, you know, you I don't think what you're saying is you have, like, country level ownership of KPIs or revenue. You haven't got country managers across a hundred and fifty countries. So therefore, there's no point in spilling the tree by a dimension which actually no one's owning the revenue from whatever country you choose. You know? So you you're basically, you you align the metric between the metrics to the ownership of the org, the structure of the organization. If you work if you're for example, if you're gonna make a change, which impacts everyone regardless of country, then you should structure your your org your you should structure the metric tree by organizational structure and how change is gonna land. So you can measure the train most directly. That's what I'm trying to say. Bad and right. But yeah. Yeah. So that's that's also just implicitly the part back to the way you've already structured your team, but it's a key insight which I think others who may not have that alignment should be thinking about is this needs to align to our organizational structure, metric ownership, and the way we go about doing implementation of change. Correct. Yeah. I'm gonna again try and tackle a couple of questions at the same time. Matt, can you bring up your your sample again of the the tree that we have? In the meantime, I'm going to actually answer Tom's question at the very beginning, which is about, like, what are the actually, let me let me shell that for a bit because this this is a is a lot easier that I wanna show. So I think, do we ever use the metrics to do a prediction? We actually do. So if you zoom in on the very bottom rung of our tree, you can see that we've in we have these input fields that change all the calculations that go upwards. And so we're able to determine essentially so I think I have something on on the right side. If you go to the right, actually oh, yeah. You can just do that. Exactly. I don't know if it will work out, but well, yeah. Kinda comes through. Yeah. So it's randomization is a bit different. Right? It's a bit yeah. But yes. So in a word, yes, we do have the ability to predict, and this is, again, a a tool we use for opportunity sizing as well as to drive initiatives that we think are very valuable forward. So we can say, if we increased critically transacted users, our retention rate by five percent, let's say, you know, this is the outcome on the revenue, and it makes a much easier dialogue than sort of going on gut feeling. So, yes, in a word, yes. So thank you for that question. That is very important for everyone to also consider when we're talking about the tree as well. And then I do wanna get to Tom's question because I think it is interesting about crypto, and it's not applicable to literally, you know, anybody per se. But, what happened in crypto is that this year specifically, the, to be honest, Trump regulations, and the sudden sort of governmental appetite and institutional appetite for crypto has grown immensely to say the absolute least. There's a lot of debate around, you know, know, politics as to whether this is good or bad. However, that is just an example of how fast the space is moving because stablecoins I don't know if you all know what stablecoins are, but for those of you who who do, who don't, it is essentially cryptocurrencies that are pinned to normal currencies, and that space has moved incredibly quickly from January to today. And so all of a sudden, everybody's getting on the stablecoins. Everyone's creating their own stablecoins, but it's because it's the most easy, understandable crypto right now. And that's just an example. So six months for us is, like, night and day, and this is you know, again, we're going back to the metric tree. This is how we understand what's going on, where we need to go, how to push forward, and so forth. I wanna quickly touch on that as well with with another thing that that counts really helped us with is as as being involved in the crypto space with MoonPay, we're in a very lucky position that we have access to something called on chain data. So, obviously, everything that happens on the blockchain is publicly available. If you go on to, you know, Bitcoin's block explorer, you can see that this wallet address sent money to this wallet address. This is how much, what time, etcetera. And, historically, you know, that that data is extremely valuable. As if you think about most other companies, when the customer leaves the ecosystem, they don't actually have visibility on what the customer is doing, whereas we have a bit of visibility on, you know, certain wallets or things that are happening after they've interacted with MoonPay and what's happening from there. And, historically, we had we were a bit blind there, and it was always something that was being asked for and pounded home, and that was extremely difficult to to get into Looko or any BI tool. But luckily with count, we managed to bring that in quite easily and also in one of our hackathons. And we have very nice visualizations of what's happening there, and that's also helped us drive some some cool new things as well and initiatives within the team. Thank you as much. Yeah. That's four hundred terabytes of data, by the way, as Emily was mentioning just in case you'd missed the chat. So that is a great use case. We have had an amazing session. I can't thank Matthew and Emily both of you enough for just walking through that whole journey from, like, kind of what you've been, like, transformation of going from chaos to clarity, how you build your magic trees out, how you've it's tangibly being used to diagnose, to find opportunities, to take the business with you, and I guess ultimately to elevate, the data team to being kind of the strategic partners of the business rather than just being the people answering questions in a support function way. It's been great to hear that, and you've gone in such depth and answered everyone's questions, I think. So I'm I'm grateful to you both. Thank you so much for doing this. And if you wanna dig in more, I said you can head to Canva Co. You can find the tutorials we have on building your own metric trees, or stay tuned to some of our other webinars in the series where we're going into the guts of building your metric trees and then how to go on that improvement cycle journey with the business so that, actually, the business is being led with the metric tree as well. So thank you so much, everyone for coming on board and joining us for this afternoon, and thank you Matthew and Emily as well. Thank you so much for having us. Yeah. Thanks for having us. It was great. Hope to see everyone soon.