Hello, everyone. Happy Wednesday to you. I'm Ollie. I'm one of the cofounders here at Count. And today, we're gonna be talking about getting started building metric trees with Count. So it's gonna be a fun, very interactive session. I'm looking forward to talking to Sue with you. It's been a thing we're often asked about by our users and also by our, by our customers a lot, and it's a thing which we we love doing and talking about. I'm just going to rearrange this a bit. We'll be using count as demonstration as you probably imagine, so let's walk through the agenda. So the idea of this, and we'll we'll do a slow start, you'll join in as we go. We're gonna do an introduction to the power of metric trees, so a bit of background on why metric trees are powerful, how we're seeing our customers using them to sort of change the way the they're working with the business, how they are using that to challenge the business to, to think about performance better. We'll be talking about how to start. What is the way we're seeing? Again, teams are adopting, electric trees, how they're getting going with those projects. If you buy into the theory, then how do you begin and how do you get the business bought into it. And then we're gonna look at modeling considerations, how to think about the data modeling side of things, how to go about the ordering of this, what do you do if you haven't necessarily got, like, robust metrics that are well adopted in business yet, how do you start if you do? We'll be talking about all of those things, and we'll have time for questions. I know we've got an hour booked in, but I'm hoping to keep the a lot of this, to be very concise, very, actionable for everyone. And then we'll definitely leave space to ask questions as well. So don't worry if you have a, if you haven't got a full hour, we will be as concise as we can and and and get into the weeds as fast as we possibly can. Just a bit of background on Cal, if you don't know who, who we are at Cal, I think we're we've been we're, we're based mostly out of London, where as you can tell by my accent, I'm British, but with North Americans as well, and Welsh. We are, effectively, Cal is a tool focused on how to stop data teams looking like this. We we see the BI market, and we feel like a lot of the challenges of being in data right now is that, often teams are seen as support function providing dashboards, answering giving charts, and answering ad hoc questions, which is a very low, trans very transactional relationship, not necessarily, hugely rewarding on either side. And we see that the BI tools that exist, the dashboarding tools that are in the market are a huge part of that problem. They form a barrier between, the data team and the business to stop the data team being, being leveraged more. So, yeah, effectively, this is our stance. We we're we we believe the IT tools turn data teams into support functions and count is a canvas based BI tool, which, which we see turns data teams into engines and growth. We've got, hundreds of different teams now using us across Europe and the US who are using us to change that way of working with the business, working closer, communicating better, not just as a team, but also with the wider business and resetting that relationship. Obviously, one of the ways that customers do that is with metric trees. So to start off with, let's just talk about the power of metric trees, why metric trees are are are really great, way to work and sort of help the business understand itself. I'm gonna start by showing you this. This is a a killer dashboard. You know, it's got everything here, charts, filters, everything. Here you go. We've got filters, gonna have those. And then we've got here it's a top level dashboard here. We've got results, revenue, goods sold, Got a trend line over here. Got more KPIs just breaking this out, revenue, cost, number of customers, etcetera. As you can see, this is a pretty standard, dashboard, and it's what ninety eight five percent of our our organizations are looking at as they try and make decision drip, data driven decisions. And as you can tell, this is the, like, built in count. So you can build dashboards in count in case you're wondering. But, ultimately, this is, the problems with this is that you've got top top level metrics of the business, but it's very hard to understand what's really going on, like, what's really driving performance, what's really, happening here. There's no context for these metrics as well as as well as they have been modeled and defined instead of the the data model of the business. The way we're presenting them here doesn't help the business understand what's really happening, doesn't help business understand what's driving performance, and is driving basically a lot of cognitive load onto stakeholders that really understand what's happening. And and it's therefore no wonder that when you see people engaging with dashboards like this that they are asking incredibly more questions to explore and understand. And a lot of ad hoc questions, if you look at the kind of backlog we've seen with our, our t our teams we've worked with in the past, a lot of them are exploratory questions. Why is this change? What is going on here? It is they're not often driven by decision. Very often they're driven by just a desire for clarity. So one of the powers of a metric tree is that it allows you to go from an environment where you where you are not just showing the numbers, but you're showing how these numbers fit together. So here is just to show you a transition, here is the same metrics that we've had in this dashboard, but instead laid out as a hierarchy and metric tree. So here you can see not just the numb metrics and the numbers, but you can see how they relate to each other using this these arrows. And these arrows are explaining kind of what is the drivers of profit, what is what is profit, what metrics are the driving force, the levers, as you'd say, of, of profit and revenue and cost of goods sold are, in this case, those most important metrics which are driving performance here? So in a metric tree, you're using their this this canvas as we'll we'll go on to show to to describe not just the metrics, but also the relationships using space and hierarchy, these arrows effectively to paint the business, explain how metrics relate to each other, and ultimately in this case you're clarifying the growth model of this business. You're explaining how, all these metrics fit together, how these these bottom up metrics relate increasingly lead to profit. So that's a great very, very brief introduction, a very visual explanation about why metric trees are powerful, why we find that our customers, love building them with the business, because they give them they give clarity to the business and explain what what's going on. The other big benefit of a metric tree is that it it it resets the kind of not just the presentation of metrics, but also resets the way the business interacts with the data team. For example, down here, we have website visitors. We believe that is a key driver of customers, number of customers here that we think website visitors is a a key lever of that. We don't necessarily have the data to understand that. And so as you can see here, we've got a post it note placeholder in here because we need to get the data to this. And this is an example of where as you understand your growth model and what's what matters, what metrics need to be tracked, you're able to then fill in with more with far more intention what data is required, what modeling work needs to be done. Additionally to that, on the analytics side of things, as you look at your metrics, understand how they relate to each other, the questions that you can ask about what happened in this dip here, for example, are much more actionable. They're much more related to less about understanding and trying to gain clarity. They're now driven by a desire to understand the growth model better. And this is what we call the virtuous cycle. This is why we think metrics are one of the most powerful ways that a data team can, change and reset the way they're drawing value in the business is through this idea of operational clarity. That as you build things like metric trees and map your business metrics in context, you're giving the business a clearer view of what's really going on and what's really happening and clarifying what can feel like a very complex environment and making it feel simple. And that means they are asking, better questions and your problem solving, your questions in related to outcome and trying to problem solve how to make things better. And that in itself, the answers of this then drive better operational clarity. So this is what we call the virtuous cycle. So operational clarity is one of the best ways you can reset, the operator model of the data team, the role of the data team, and how data drives value because you are taking the metrics that you've been trying to work hard to model maybe and presenting in a way which leads to action, least understanding, and leads to better questions and better investigations. I'm now going to switch, as you can as I mentioned before we I'm presenting this from our report mode in count which is effectively the the production environment of of a canvas. I'm going to switch now back to the canvas so you can see now this is this is the count canvas here. We can see these assets that I built in count and laid them out as different slides just to help us talk more about, more of a theory of where to start. So one of the challenges of a metric tree and and when it comes to how to get going with this, the challenge of metric tree is that it can the the relations, the levers between metrics, need to be discussed and agreed with the business. If you're gonna have a company wide metric tree like this, then you're trying to you you've got to get the business to buy into the fact that hierarchy exists. You've got the metric definitions become increasingly important. The levers and how they break down need to be, agreed. And there's many different ways that you can derive those levers, and it's best if those levers are matched to responsibility areas that the the clear owner for each metric as you go down the hierarchy so that you know that everyone's covering off, all the all the important metrics of the business. So it means that unless you have already a very well understood growth model, which most businesses don't, it can be quite hard to jump straight into building a metric tree, a company wide metric tree like this. Not always. Sometimes it's just about visualizing it better, but getting to the point of, collaborating and building that consensus around the growth model and how it fits together in the metric definitions, can be a quite big leap to go to straight away. So what we often suggest with data teams who want to go on this journey where they believe there's a kind of business engage that the business would value this kind of level of clarity, value having the complexity of the business clarified, we we suggest and we and doesn't have the sense that you can go straight to a kind of full company wide metric tree. Our recommendation is to move to, instead of mapping the company wide level where the where the measures and levers are more subjective or need to be agreed, it's to go for an onboarding funnel of mapping an existing process. That could be a user journey, an internal process, but map out a system that is already understood, defined, and then you're just clarifying out this together. This is actually a, a good example of a simplified version of what what our our customers, often build. This is an onboarding funnel for a mobile web mobile app. So you can see here we have downloading the app as an action, and then we have various screenshots of users moving through each stage of the new user sign up process. And as you can see we have here both the number of users at each stage, we've also got the activity numbers by time and their conversion rates. And this is, a relatively simple process, but this is obviously a user journey. It doesn't have to be users, it could also be support tickets, or it could be logistics, or it could be, like, any internal process you're using for, managing a sales funnel or any department often is a system. Ed businesses are just basically old processes, but you're taking what already exists where there is an ambiguity or a discussion around what that system is and just clarifying and building it out this way. And the reason this is useful is because you're then focusing on the presentation paradigm and focusing operational clarity rather than trying to work out what the metrics are. The metrics should be better defined or are much feature much easy to to get to. In this example here, by the way, just to prove this, we've got about, fifteen different metrics laid out in context. And suddenly, as you can see in this picture, a kind of the conversion drop off rate here of sixty eight percent suddenly becomes very clear what that definition means, and instantly start making you ask questions. So this is a very powerful way to to start working with metrics you already understand, processes which are ambiguous or can be at least clarified, and then working on how to help the business engage with this and and follow-up and ask questions as a proof of concept of the power of this this way of working. Just to clarify what this is, this obviously is, as you can see, a process, but you can also reverse this and show it as a metric tree as well. These are the same metrics, but just portrayed, as a as a tree rather than just as a as a process. This the metric trees and process blendouts are kind of the same thing. It's just that this is mapping it as a journey where this is showing metrics at each stage as a number and a conversion, at the same hierarchy level. So just to clarify, we are still looking at metric trees here. It's just that by mapping it as a system, the adoption that this the the adoption and clarity, what you're really showing is clearer. It's less of a theoretical conversion and much more real. So adding screenshots here, for example, is a really powerful way to do that. What's also very powerful about this way of working is that, we often see this with our customers, is that you're able to build this process. The way you build this out is often drives a much greater understanding and much greater ownership. In this example, what we often find because the kind of mobile app that you're working with a product manager maybe in the canvas, they're adding the stages of this onboarding funnel. They're adding in, the definitions and what they want to see in the arrows. An analyst then is coming in here to, to work out and define the met the, the analysis or modeling that needs to happen down here to, to get to an outcome, to find the logic and events that need to be tracked and aggregated. And they're working through this in full transparency there. The modeling and the metric definitions, the presentation layer, the analysis is being done with the stakeholder and analysts working together. They're effectively problem solving and building a report at the same time. That leads to greater ownership, a greater understanding on both sides, and that collaboration as you build is what makes this kind of, process, much more powerful, and much more engaging across business. It's the same process that you want to go on really when defining a a company wide metric tree, but obviously, this involves many more stakeholders perhaps to get conviction and understanding about the definitions and involves maybe the whole business or at least the c suite. So that's that's where we would recommend people start is actually just smart start in a department or start with a, an important area of improvement that needs to take place in business, a kind of OKR, like to improve a particular conversion or a particular metric, and then start to map that process. Give clarity to what's going on there. Highlight the areas on on this I mean, it's understanding or or confusion or opportunity, and then you can deep dive and understand what's really driving, the metrics at this case, this slight slightly lower conversion rate. And the power of metric tree, obviously, is that you if you modeled it well, you can actually splice some dice across metric tree. You can you can use dimensions to see how different segments look at this differently. So in this case, from, genders or sexes, and we're just gonna filter by this dimension to see how it changes things as well. And this just comes back to modeling. How do I make sure that I can look at a particular, a metric like this one? And I can take that visual, and I can, in this case, in count, apply gender as a a metric, and I can then start to look into the differences more within this within this canvas. And that's that's where a good modeling of a metric tree can really help because you can then basically explore any given metric and slice it by time or by or by a given dimension, like like my yawp country in there instead. And we can start a bit messy. Too many too many countries. But you get the idea that you can then slice and dice this tree by different dimensions that you think are relevant across the entire metric tree at the same time to help you explore and dig into what's really going on. So let's move on now to look at modeling and how modeling can help you how to think about modeling when it comes to the metric tree. What I would say first is the most important thing here, which we often see with with customers who would use count, is that the power of the Canvas approach is that you can build the system first and do modeling later. And it reverses it means you're goal orientated rather than modeling first and then showing the business what you're trying to build. The power of the this way of working is that you can define your system, define your metrics in theory, and then bring in the analysis and modeling in parallel. And you're working through the presentation, the scope, the analysis, and modeling in a much more agile workflow. But there are, kind of two different ways to think about modeling. The core idea with to get to for a model for a tree is the idea of this kind of three constituent parts. There's gonna be time, the metric, and then dimensions. And that's that's true for most if you do map the whole tree, that's gonna be that's gonna be the case. When it comes to the differences here between these two different models we would recommend, one is an event model, and one is a cube model. And these really depend on the kind of system you're you're mapping. In the case of the of this onboarding funnel, the metric here is number of events or number of users who've gone through an event. So in this case, the units across the entire tree are all the same, and that means that you can literally just aggregate an account event name by a dimension and by time. And that means you can work from basically real level data in this case. So it's very good for, as you can see down here, for mapping processes or where there's a single unit of time because you're effectively just got one type of definition, which is count of event or count of widget in that regard. There's a very good way to work. Event modeling works well when you've got a kind of a dimensionally consistent tree. It's the way one way I put it. Dimensions being the units that you're counting across the tree are the same. A cube model is slightly different. In a cube model, you have time and dimensions, which dimensions can be, you know, the just the descriptives of the of the business or the user or anything like that. But also the metrics themselves have also been pre pre predefined, and you've got therefore, a number of metrics, a cube of metrics, dimensions, and time stamps, basically. And that cube, that three-dimensional cube, or in this case, a flattened cube, is really good when you've got, a semantic model where effectively the metrics that you're comparing between the hierarchies aren't necessarily the same unit and therefore need to hierarchies aren't necessarily the same unit and therefore need to be pre ad predefined and put into the cube. You can't just count, the same thing and filter for different events in this case. So So a good example of a cube will be here where we've got profit, revenue, and cogs. These are all in dollar signs, but then down here, we have customers. This is a, this is a number. In fact, it's a number of a different unit. And in this case, you've got different metrics, which need to be rolled up slightly more to help you understand and slice and dice across the tree for different dimensions. And that's where a cube model can be helpful. The key idea, though, is you don't need to start thinking about the model straight away. Well, certainly, we would recommend if you've got the ability to build your tree and do your analysis and modeling in parallel, you can scope out the tree and the metrics, and you can define your models and bring in whatever data sources you need to prototype, define, clarify the definitions in parallel at the same time. And then you can then take this code and then push that into a or refactor that into a defined data model later. And that is a way to get time to value up and avoid kind of doing a, like, a lot of prework which doesn't resonate or hit, as you're trying to work with the business. The power of a good data model, though, is it allows you to have a consistent set of dimensions across an entire business, either dimensions, which means you can on time periods, which you can slice and dice and see how different segments, different dimensions impact metrics at different times. And that's a very powerful thing to get to, over time. So the key idea here ultimately is that when we're talking about metric trees and defining the role of the businesses to define the growth model of the business and help the business understand itself and then helping them improve those metrics, You want to make sure there's an environment where data engineers and the modelers, the analysts, and the business users are working far more in a far more unified way, in a far more agile way to define the different metrics, define the presentation, define the, define the data sources that you need, and are working in one place as you're building out that tree. That's something which we think is makes counterpart unique is that you can do all of that scoping of that key growth model, that key process at the same time, modeling and presentation and analysis as as we're going. I think for now, I I've I've spoken a lot, in one go. I hope that's been helpful. We've covered off to remind you just a bit more about, like, how account our mission is to try and turn data teams into growth engines rather than support functions, and we've done that by adopting a a canvas based BI tool. The power of a a canvas based BI tool is it allows you to move away from a a dashboard view centric presentation view of the world to defining metric trees where you're presenting not just the metrics, but how they relate to each other. And, ultimately, what metric tree is doing is define the growth model of a business in a really clear, transparent way. We've discussed how that's a virtuous cycle, how that if you get greater operational clarity, you get a better focus on the areas that really matter the question that needs to be answered to move the business forward. And that in itself leads to a better understanding of the growth model, and that's a virtuous cycle, of clarity and of progress, which the data team is at the heart of. We've then talked about where to start, and our recommendation is strongly to focus on processes, or metrics where, this you're mapping a an existing system already exists, where the metrics are already clear that need to be clarified and and and positioned so that you can then move on to tackling the improvement side of the process, which is to tackle a conversion rate and and drilling down to what's going on. And And then once you've proven that works, you can then leave it up to building across different departments and moving up to a company wide view, depending on maturity of your metrics and how well the the your growth model is understood already. We then touched on different data modeling and the idea of modeling in two different ways. Event modeling is great if you've got a consistent, dimensionally consistent process where you're can you can the metric you're you're counting and filtering by a particular event, for example, or a cube model where you maybe have different metrics, but you want to have a unified view of dimension and time, which you can then roll up and down on, as you understand what's driving the performance of these different metrics at different levels of detail. Hope that's been useful. There's a lot covered a lot there. I'm gonna leave the rest of the time open for questions. So I hope that's been useful. I, I'm not gonna rush off, but, please ask any questions you have or feel free to reach out to us, on the website. Oh, there's loads of questions. Great. Thank you very much for asking these. Andre, I've seen that you asked a question. Is it possible to apply dimension based filters, country, and channel, etcetera? Absolutely. Yes. You've you've seen that. Just to point that out in this kind of onboarding funnel example, we have because we've done an event based model, we've got some dimensions, and then, therefore, we can filter that dimension across all of this this entire metric tree. Caroline, how do you do comparison between segments? Yeah. A great question. One of the powers of the canvas is that you can literally replicate everything in in very quickly. So for example, in this particular example, I'm gonna take both the analysis and this metric tree and just fork it to the side. This isn't necessarily how you do it every single time, but this allows me to therefore now control this tree and look at two segments side by side. I've now got this filtered for age seventy rather than age fifty. And so if I wanted to do this a bit more side by side, I could hide the model. I've, I'm doing this partly because I've, I built the model this way, but you can now see I've got side by two segments side by side, within the same canvas, and I can then control them independently of each other, and that will update the metrics on both to be different. So you can absolutely depending on how you've done your analysis and how your data model works and how you've wired that up, you can look at two different segments side by side. In this case, because I've done the analysis in, like, a kind of a raw format, have to duplicate the analysis as well, but that's only, that's only because of I've done this example. So I hope that's clearer. If not, I can happily share some more examples of that. So, yeah, that that's such a way of doing it. If, again, the power of the canvas is that you've got this ability to have, you know, a rather big as as much depth as you want in one place. So we've had customers who built trees of sixty metrics or more broken out by these frames so that you can present each segment separately and push different parts of the metric tree, different parts of the business on different cadences, but you've then got that single a single one place where the whole business can be mapped out within one canvas, and that's a very powerful place to be as well. So that's what these frames are doing is this unless you have that reporting layer to push a segment of particular segment or a particular portion of the tree, to different locations. Great. Any other questions? I'm I'll be we'll stick around. Hope that was a a good introduction to how to start building metric trees and how this all fits together. Obviously, you can you can start to account and give it a go yourself. There's a there's a there's a free trial available to get get you going with the product and building out these trees with a lot of examples available to you as well. I hope that's been helpful. Thanks so much.