Hello. Hello. Welcome, everybody. My name is Taylor Brownlow. Sorry. Just letting a few more people in. There we go. Welcome, everybody. Just kicking off. Thanks for bearing with us starting a few minutes late. My name is Taylor Brownlow. I'm head of data and product at COUNT, and we're here today with Veronica Sutsirova from Otrion. I'm really excited for today's talk. Veronica has, she's been with us for a while now, but, yeah, a couple of months ago, unprompted did a did a talk in Amsterdam to to talk about Count, which is great. And a lot of the examples that you shared, I was really anxious to kind of share more broadly. And I think a lot of what, what you discussed in that talk and and today feeds into this question of of collaboration that a lot of data teams, I think, are struggling with. How to make that work, how to make it more than, you know, sending PR requests, how to make, you know, the way that within data teams, how that actually what collaboration looks like and with the larger business. So a bit of context, for today's session. But, Veronica, I'll I'll hand over to you. Thanks thanks for joining. How are you doing? I'm doing great. Thanks for the intro. Yes. Indeed, I'm super happy to just share how we have been using it and because I really believe more people should be using count. So happy to share the excitement as well, in the real Amsterdam meetups or online, talks with you. Yes. Yes. Same. Yeah. Let's let's dive in. Maybe to start, do you wanna tell us a little bit more about, background on Atrium? Of course. So Atrium is Amsterdam based online ecommerce marketplace for fashion. So that means we solve the problem of unsold inventory for, hundreds of different brands that all deal with the issue of, having leftovers after the season. So that means that we take all of these, clothing pieces and we try to, make every piece of clothing be worn. It means, sell them to people for, attractive discounts. Nice. And what's the what's the data team like at OSHA? Alright. So our data team has, four different subteams. We are thirteen in total, but it's split into data engineering, data analytics, recommendations, and pricing. So data engineers, as usual, take care of more of the low level infrastructure stuff. But, analysts, take care of our dashboards, multiple different models, while recommendations and pricing people take care of the specific models used for these specific domains. So that means dynamic pricing optimization. That's also the, area which I had been working in for two years, Notrium. And the recommendations, which is quite, recent. We created team with Notrium, so that's about ranking and personalized recommendations, so that people find, the matching pieces in all of the different, fashion pieces that we offer. Yeah. You guys have a really nice setup, I find. It's a good kind of you've got a bit of analytics, as you say, doing reporting. You have some really good data science ML activities happening that plays really closely with the product, and then you have the kind of data engineering group that's the the foundation to all of it. I think it's a it's a nice nice setup. So, yeah, you you sort of mentioned you were working pricing and things like that, but but more recently, you kind of been more on the data engineering side. Is that is that fair? Yeah. That's correct. Indeed. So I've been in Notrium for almost two years and a half now. And the first two years of that, I spent working in pricing. So many of my examples and, the things I relate to actually come from the pricing domain. And recently, I switched to data engineering. So I've been focusing more on supporting all of the domains that I mentioned before. Nice. And, last thing before we kinda dive into your examples is can you just talk us through the data stack if everybody loves to loves to know that? For sure. So I also had the nice diagram for this. Sure. Sure. Feel free to share. Yeah. Yeah. Alright. So as well. Maybe. One sec. I think that is the best way to describe. Yes. Visual is always best. It's so fun. Yes. Indeed. So one one thing that, well, it not always look like this, but at the moment, we use Fivetran for ingestion of, data into the data warehouse, which for us is, Databricks. So the Databricks like house platform, running on AWS, with, DBT core that we use for maintaining all the dependencies and, four different layers of our medallion architecture stack. And, from there, from the final layer, we, of course, use this for different use cases like the dashboards, which for us at this point is, still looker and, various models which might be, for example, Databricks notebooks, as well as Hitech that brings this data to different, use case domains. It hasn't always been like this. We also used Airflow before. We used, AWS Redshift as a data warehouse before we migrated to Databricks, but, now we are quite happy with the setup as you see it at the moment. Yeah. And I guess good context here, because, obviously, we see count used in a few different places in the data stack. This is a helpful diagram to show that, a lot of the examples that you'll be talking to today is is related today. Engineering is related to dbt, but also a few analytics examples as well. So it's not quite, you know, not dashboarding per se, but it's that problem solving stuff, that more analytical, kind of stuff that, Sara mentioned last week quite a bit, which, I recommend people go check that that talk out as well. It's a lot about, problem solving, but I think it's a good context before we dive in about, you know, where account is sitting in this in this diagram here. It needs it's like an umbrella above everything from the beginning till the end of the pipeline. Yeah. Yeah. That's, and it's, that's quite unique. So it's a good, good to set that set that up. Well, cool. Thank you for thank you for sharing that. I think then let's dive into the first example that you have if that's you guys you're sharing your screen already. It's a good place to dive in. Alright. Let's let's go right into that then. Alright. So the first example that I have is, about image data, which for us, in the ecommerce and, fashion domain is, super important. And I believe this is one thing that, like, initially makes it very, visible why account makes so much difference for us. Because in these domains, you oftentimes need to inspect your, tabular data alongside the images that because the tabular data relates to certain products, or, yeah, items that are simply seeing them will make so much difference, in how you want to affect them and you want to inspect, for example, in pricing or recommendations. It's, like, checking whether you are recommending the right set of products, might be okay within the tabular, information that you get at once when you query your, data. But seeing those recommendations actually visualized, makes so much more difference. And, also in domains like machine learning and computer vision. I imagine when I was building computer vision models and when I needed to inspect all of my failed, test cases, I what I did before was going through the folder of my images that failed or that didn't get the right predictions and clicked one by one to find out which kind of examples were failing. And in this case, we are also the way people inspect when stuff goes wrong or when, items that are not selling. Let's say, people would export CSV files, which then get the URL, and they would check the URL one by one to see what kind of items maybe are, not selling at the moment. But, the way, we can do this right now in count, I hope people here, have seen this kind of sale before. So here, I select just random twenty five products, from from our data warehouse. But, this could be also, I don't know, a filter for the things that we're selling the least last week or anything else. And I just wanna see what things what kind of things what do they have in common. So one thing that we can do and that we use quite often right now when, I collaborate with, other people in the multidisciplinary team such as pricing, where, commercial people might not be able to or, like, are not super comfortable using a Jupyter notebook like I do. Just need that there's mirror board or, account board, to inspect all of the images that we wanna effect with certain campaign, and we find out, the common ground. One thing. I see that it's syncing. So let me reload this page. The, live demo. Intricacies. Yeah. I think I think you're describing. I mean, I think Mhmm. The the need for visual context, I can see totally being, you know, in in fashion being really required or any kind of ecommerce type of business as you said. But I think just in general, we see people who are doing, you know, like a website analysis or something like that. And even then, like, having the visual context of, you know, what does the page of the website look like, you know, when we're converting it, all that's because of things. I think that having the analytics with the context is really important, I think, as you say as well from a collaboration perspective, because you're trying to create a common ground, like a common space where, you know, if you're, somebody in marketing or somebody in product is looking at, you know, what product should we be offering or someone in that recommendation team or something, be able to look visually and see, like, well, this is, you know, their frame of mind of what these products actually look like. And then to have the analytics layered on top of it is, is really powerful. Great. It's, it's really the example of, people having to go through URLs and open seven tabs. Yeah. To or seventy tabs, which no one is ever going to do. And you can just inspect it in one cell and can. It makes, so much more so much difference. Alright. I believe we are back. So let me share again. Back up and running. Nice. Alright. So what happened here, is that we have this one cell that I was showing, which selects certain products. Then I have a different cell that fetches images from a different table, because that's not where, the image URLs are stored. And what we can then do is use, canned request library, which helps me show all of these images, like I have here now. And if I want to maybe, like, this was a filter for some selection of products, I can also change the filter and then, apply a different filter. So if everything reloads, I will just get a new set of images, again, and it's very responsive. So people that would never be able to inspect this with, yeah, like, can do it right now. Makes so much difference. Yeah. I think when we were we were speaking earlier, you're mentioning that, yes, this is this is useful for for you and the data team trying to dive in to figure out what's going on and find root cause, but more broadly with stakeholders as you mentioned because they they're the ones who would be opening all the different tabs in Google Sheets. So having this place to just that shortcut so much effort for them, right, to just be able to look at and look at this at once and for it to be responsive. And you can imagine, you know, slicing this a few different ways and and looking at different sets of products as you need. Yeah. I really like this. Hundred percent. And here is maybe a good, point in time to mention that, the I got this board running or, like, this example with images running with the support of the counting that has just been there for me whenever I need something that I haven't built before. Like, is it possible to build multiple images, visualization in a in a count part? And I just yeah. For sure. And I'm sure there are so many other things that I will find useful, and I will just ask. And you you guys will just, tell me, oh, yeah. This is possible. We love a challenge. Yeah. Especially our some of our dev team, love any challenge you throw at them. So this is a this is a fun one. Yeah. Love the attitude. Oh, nice. Cool. With those of you that are are tuning in, feel free. I've got the chat window open. So if you have any questions, feel free to drop some questions in at any point. But we will have some time at the end for questions as well. But just in case you think of something, feel free to drop in. Otherwise, Veronica, any anything else you wanna add on this example here or kind of the next one? Yeah. No. I think we can move on. Okay. Great. I do love this one, though. Yeah. Cool. So this one is a bit, more data engineer domain, example. So, here. I'll do this. One thing that I find, is a common thing for neuron working in data engineering. Common scenario is that you need to alter a piece of code that someone else has written before you. Or maybe you have even written it, like, a year ago, and it's a massive piece of of code because that's the simplest way someone could have built it. And for sure, there is logic in it, but it will take you another half a day to remember why and where the flow was going, what was the logic behind it. And I'm sure many of you or many, many, people working in the data engineering domain have gone through this. You have your Versus code open or your favorite IDE, and you go through the click through rabbit hole of which model refers to which model. Okay. Like, let's go further and further and further, and you don't even remember which file you came from originally. Or then you copy everything to Miro and you start adding, sticky notes around it to remember, okay, this is about that domain. This is about this domain. This is how it relates to one another. In fact, I've been to a test talk where someone described, for a few minutes how they, have this process of sticky notes and Miro boards, outline. And all I could think about is how I could easily do it in count because, count has the connection to DBT. And for those that maybe are not super familiar with DBT, DBT is this, framework that ties the maintains the dependencies in between models like, you have in your directed acyclic graph. It maintains all of those dependencies and disconnects, or, like, one of the things that it does. And since account is connected to it, I also have, my entire data catalog here, and I can easily import a table that I wish. And I have selected a really, really large model for me to import here right now to illustrate, that it would be quite lengthy process for me to, go through it. So what we do here is, add this model to Canvas. I can also choose to add, upstream or downstream models, which I really love. As I said, this prevents you from going through the rabbit hole of clicking through many different files. But for the sake of this example, I'm just gonna add this one cell, which will import this super large, piece of code into my canvas. And That's not Yeah. This is actually massive. But what, yeah. So what have I gotten just by having it here instead of having it in another ID, is that I can easily break this model. And get the Yeah. You basically broken down all the the CTEs Yes. Into cells there. Yeah. So now I have the entire map of what's going on with, all of the intermediate steps in the data all displayed in one place, which is amazing because now I can actually see what's happening. Yeah. I think you explained well to start, like, what what this feels like, you know, to do this without it. I think, you know, Sarah last week was talking as well about onboarding and having to do this exercise in an ID of just, you know, commenting out CTE by CTE, testing the the live results, all that. So to have this instantly broken out against live data, and and I get to tie it back to this collaboration as you say, this is knowledge that's that's in a silo. Right? This is some someone has written this. They didn't understand why they've done it. Maybe even if they've commented out really well, it's still difficult to make this accessible to everyone. This could be data engineers. It could be, you know, other people in the business, whoever needs to understand, what this is about. Exactly. So the process of adding sticky notes and comments, it can still be easily done here. Actually, it can be done in a better way because, people can collaborate live here, and then they can come to the same board. We can all choose the same minimal example. So I can choose okay. Like, I can filter this little model here, for just five products, let's say. And, then we can follow step by step what actually happens through this model. So this is super invaluable. But another thing is that you can just edit it here the way you would in your in your ID. And then once you are done is if you're using GitHub, you can also commit your changes back to GitHub directly from here. Or, take the final model, which I think is this one here. Or I'm not sure. However, if I have the final model, I can copy the final SQL, and either, as it is or with Jinja as well, which I really love and use very often. Yeah. Yeah. We see this is, it just saves that extra step. Doesn't it? Just yeah. Pushing things back through completely. Yes. Another thing someone asked as well before was, why why would you even end up with such a, such a large piece of code? And I think the answer to is, to this is that within the past year that we have been using count in Atrium, I think everyone has gotten, so used to using count for any kind of debugging, working progress development of new, all those work that I know that if I build a large piece of SQL, no one else is going to be scared of it and having to go through half a day of understanding what's going on there because everyone will just copy to count or import it directly into count the way I did, and it will definitely not be as daunting. So we are not worried about building, yeah, like, the large piece of SQL is not a problem at this point because the understanding, is not an issue. Yeah. I think that's a good example of, you know, kind of maximizing the the data team, like, making sure you guys are focused on the on the right things. It's you know, let your models get as complicated as they need to get, and and that doesn't become a hindrance later down the road that, you know, people are still able to understand and interact with them. Yeah. I think that's a really good point. Exactly. So the alternative would be having all of these in separate models, but we don't need to do that, or, like, formal models that are not materialized or something. But you can just keep it all in one place, and it's cleaner, and not less transparent. Yep. Yep. Yep. So this is the way I do development work right now or any kind of debugging work or, altering piece of logic that I'm not so familiar with. I just, use count as the one place. And also to verify whether, the modifications that I made actually result in what I would expect. So one thing is, like, okay. I'm not quite sure maybe what happens here in this, CT that was, originally, in the large piece of SQL, I can just quickly inspect what's going on here. So let's say I don't know. We can, how many brands are here and how many different products are there for different brands is probably gonna be but, yeah. So Yeah. Just doing little, like, checks. Right? Yeah. It's all live for you to So all of these, I can inspect what's going on one one by one. Yep. Yeah. I have to say we use this all the time for our data modeling as well. Yeah. It makes a big difference. Sure. Yep. Yeah. Any more questions in this example? How, I mean, how often are you guys doing this kind of thing and then sharing it with other data engineers? Like, maybe when you're building a new model or something like that. Is this is this also a place that you might, yeah, maybe build from scratch, maybe with, you know, bring people into the building process together? Mhmm. That's a good question. I think, so there are multiple ways in which the data engineers, use count while, debugging or building models. So if it's just, fixing issues or, understanding what's going on, altering the logic slightly, then maybe there is no necessity for, someone to also go into account even though you use it in the process because it really greatly helps you, your understanding on, like, what's going on there, what needs to be altered, why it was built in such a way before. But, when building something new, there definitely is, a, yeah, point in the in the workflow when, you might maybe want to compare different versions of the same logic. And that's also the example that I'm going gonna go through, in a bit. But, you can easily, yeah, build different versions. And unlike maybe different ID or a notebook IT, you can compare them side by side, and everyone can alter them at the same time. Or you can compare minimal examples and take real data minimal examples. So that's one great difference, when taking just Google Sheets or maybe something we came up with on paper, where you would come up with a minimal example, which is not really real, and then you're a bit detached from what's actually in the data. Well, here we can work with the real data and the real example and, still build the real logic in the real code that is later gonna be committed. Yep. Yeah. It's a good point. So I didn't mean to preempt, the last example, but I think I have, inadvertently cheats us up for that one. Yep. Okay. Then I'm gonna bridge over that. It's a bit of a concrete example. So while these last two were a bit abstract of, on, like, how it could be used in a hypothetical situation, this is a, a real example of, a real piece of logic that, we built recently. I'm going to quickly explain what it does over here. So it's an example from the pricing domain. Yes. That's the one I'm, pretty close, close to. So here we have, super small sample of some products from three different categories of products, where we would have, some products in scarves and gloves and some jeans and some swimwear. And what these lines are showing is how fast or how ideally we would like to sell out these products. So that means if we had, sixty four scars in January twenty four, then we would like to be roughly on thirty seven by now, if, all the sales went exactly as as we would like to. And this piece of logic that was built in here was, altering this in such a way that we make the, targets faster or, like, more ambitious in moments when products are in season, while less ambitious when they are out of season. So that means swimwear should be selling faster in summer, and scarves and glass should be selling faster in winter. Yeah. And this is something that, yeah, we agreed on before. We aligned on maybe what the logic should look like. But if I were to build this without count, I would put this into DBT or, no. Maybe I would first create a Google Sheet to go back to my product owner team lead, to discuss the logic again on the random made up examples that do not relate to the real data. Or I would build this in DBT fully and then create a Looker dashboard. And only then she could, come back to me and say, okay. Like, what about this? I'm not sure if this works exactly the way it should. And we would enter this super lengthy process of feedback where all the changes I make need, like, a day, of to propagate to her so that she can tell me something about it. Well, this way, while we have count, I haven't created the tables yet. I'm just, like, this is a work in progress. I can invite her to this count board, and we can, go through this together at the moment. And what she would probably this is we didn't actually have this discussion. But if she had seen this graph, she would probably tell me something like, oh, like, you have hundred pieces of swimwear in the beginning of January, and you plan to sell out fifty percent of it by, yeah, twelfth of May. This is maybe not something that I would like. Maybe, yeah, we should be bit less ambitious in this time period and make the season effect a bit stronger. And this is not something that I would come up with maybe as a data engineer or data analyst because this is the kind of feedback that you only get from your commercial business stakeholders that look at the graphs and think about it in the very commercial way. So they always come back with questions and comments that I did not anticipate. So what I can do super easily in this scenario is copy the entire thing and answer the question on the side. Okay. Like, what would have changed if we went with your suggestion in the logic? And now, for the viewers, I'm just gonna unblock the hidden cell here because you don't need to, see me modify the code live. But let's say I did modify this code, and, I would have a new version of the same thing, which would look like this, for example. And I can then join this new version to the old version that I had here, and I can compare them side by side, oopsie, here, to see what what the effect would be if we were to use the suggestion of your stakeholder. And then you can together come up with the third version and create a green line on the same graph that would, do something completely else. In in in this case here, like yes. The swimwear blue line is more ambitious previously, and now it's a bit less ambitious. So that's what we wanted. But you can discuss right away. Is this something that we want? Is this something that we don't want? And this is not something that you could come up with if you are siloed in your, data engineer analyst workflow without including the stakeholder directly in your work in progress. Yeah. Yeah. I think this is really true. I think, I've had a lot of teams who who have this question. It is a question a lot about efficiency and, you know, how do we how do we improve time to value? How do we improve time to insight? Whatever kind of the the speed metric you wanna go for. And I think one of the biggest things that I've seen is the biggest way you can stop wasting time is is to stop building the wrong things. So I think having this kind of approach, as you say, saves you from building, not just a dashboard that doesn't get used, but, a TBT model that needs to go through rounds of testing and approval before it goes out. Like, this is now affecting, you know, multiple people who are not wasting their time on something that's not quite ready to be productionalized yet. So I think it's a good example of, like, only do what needs to be done, and that's how you're gonna actually save time, for everybody and get to the right decision. Especially as you say, when you acknowledge from the start that this isn't this isn't a problem that the data team alone can solve. I guess it's something, I think in all the examples, to be honest, you know, it's kind of understanding that context and, you know, having the the stakeholders input on all this is just as important as what the data team is bringing. All the models that you can build here are only as good as as you said that that context of people who are looking at this every single day to come in and say, well, actually, I think we need to to tweak this, and that's what makes it useful. So I think leaving just leaving space in the process for that kind of input, is is really valuable. Hundred percent. All of the new features, especially in the pricing domain where it's really not so straightforward what the correct version is. So maybe if you have a domain in which it's very clear, we just need to increase this one KPI, which, we can AB test as soon as we, push this to a staging branch, then okay, then maybe you might need such a strong collaboration. But in in my opinion, investment strategy of the means is not so straightforward, to know that this is gonna be better than the other thing. Pricing is definitely one of them recommendations. Okay. Before you can AB test, but before that, you might want to also see for yourself how it's going. So this is really, like, become a huge part of the process. Nothing actually gets developed outside of the board, at least. Yeah. Yeah. I think, yeah, that's well said. Yeah. There's certainly certain domains for which you can just just operate, but especially when things are unknown. I mean, you it's gonna take a lot of iterations. It's gonna take a lot of, you know, just waiting through not quite the right thing, this and that. So the quicker that you can navigate that, the more impactful the team is gonna be ultimately. Yep. And I feel like people then also feel more involved Yeah. In the so your stakeholders might initially feel like, okay. We define what we want, and then it's out of our hands. But now they are involved in so many like, we have multiple checkpoints before, the feature gets into production. There are multiple checkpoints before where they can still influence, what it's gonna look like. And you don't account enables you to speak to each other in a, yeah, not so technical way. Like, it really bridges, the way I work with with, like, their style of work is. Yeah. Yeah. It is a really good point on the, one of the just observations I've seen, I I would like to quantify it, but I haven't quite found the way to do it, is, you know, with with a lot of data work, if you're able to bring in stakeholders early on in the process, then the end result will be, you know, x more valuable. I think not just because you're gonna be building the right thing, but there's also this sense of, just kind of human nature, like feeling like you're involved in the in the end result. So I think even if you get a great list of requirements and you pick every box and you you end up in the same place, you're still gonna have more buy in that end result is gonna be more useful if somebody's brought in and they're they're feel like they're working on it with you at the same time. So I think what you guys have done, not just in this example, but as you say, I think kind of in just the way that you guys work now, just bringing stakeholders into the process as early as possible, has had a big effect on, yeah, the how people are are using this. You know, going back to that first example. Right? If you have stakeholders coming into this space as well, playing around with different, little tools and things that you've built, help them explore different aspects, I think even that usefulness comes down to bringing people into the process at the right times. Certainly. Plus, I feel like besides, having the involvement, they also even if they maybe do not modify the way I have, showcased here, definitely, there is more understanding of Yeah. How it works. So then in the future, when, there when you discuss road map and suggestions and, different features, there is much more understanding of how things work. So then oh, like, we have already explored this one thing on the board. So now You can come back to it. So that's one great thing. And throughout this process, also, they become super comfortable, using it themselves. So they end up building boards themselves for things that they would previously build Google Sheets for Yeah. Which makes it much easier for me to collaborate with them on other things. And I felt previously there wasn't a place where I could review their logic for something because oh, like, we always use a Google Sheet for for this thing. And I'm like, okay. Like, what's the formula? It's always different in, what's the so Yeah. This way, I can jump into the board and see exactly what's happening. Yeah. Yeah. I mean, I could I could talk about this all day, but I I don't have to go on, too long. So I will, one last little bit that I have heard, recently that kinda plays into this and then we'll have close-up. Is this idea, you know, like you mentioned, that people having their own bespoke logic in in Google Sheets or even, you know, wherever it can happen to any kind of tool. But you have this, like, siloed effect of these different numbers and people have different interpretations. And that's kind of this big fear of the always the data team of that happening. And, one data leader I spoke to recently said, it's not that their fear isn't that they have different numbers. It's that you don't know that they have different numbers. Like, the first thing that you need to solve is that you actually realize that you have different numbers, and then at least you can have a discussion about it. But the worst case is just not knowing. So I think having a space like this where at least you know. Right? It's it's there. It's visible. It's transparent for anyone to see, then that opens it up to to have the conversation. Yes. Hundred percent. Also could have many different examples on this. But yes. Exactly. Like, I can now I don't have to. Previously, if someone would tell me and this has happened, in the past. Right? Like, we have I'm seeing this thing in the data, and I need to go back to see their queries. And they might have, exported something yesterday that they now, have, as a CSV file or just download it somewhere else, upload it somewhere else. No. We just go to the account board together, and we see exactly the same thing. So hundred percent agree on that. Yeah. Let's yes. We should, we should wrap up. But, any questions from anyone listening in, please, feel free to use the chat. But while that happens, Veronica, I'll leave you a last question. What's what's next? What are what's kind of the next big projects, or what's, next on the horizon for the team? Oof. That's a difficult one because, of course, there are many, smaller projects that are very, very different within data engineering, recommendations, pricing, analytics. I am now using account board at the moment to check the data differences between one system and another system. That's also just one account board which, multiple data engineers return to at this moment to to still check the differences and align what are the remaining differences that we need to, still account for and resolve. So that's definitely the one that it's more active in my mind at the moment. But, there is also one very active board in development to check back, efficiency of different campaigns, again, where we use this feature with, showing images, because the campaigns, of course, always contain some product. So it's easier to see which products are in which, which campaign. And that's also something that's built by people that have maybe not, had so much coding experience before, but now they are super comfortable building a board by themselves and, do analysis work just because it's such a it has such a low barrier, for entry for anyone. Nice. Yeah. Yeah. Any any kind of database migrations and comparisons is, can be quite, a headache. So I I empathize with you there. Well, cool. I think, I think we're just gonna go ahead and and wrap up then. Veronica, thank you so so much for joining us, sharing these examples with us. Thank you everyone to to join in, and, yeah, we will speak to you next time. Bye, guys.