 after the presentation plays out. So I don't have to do anything during the presentation itself. Absolutely nothing, enjoy a morning coffee. Yeah. Perfect. Okay. So we'll give people a couple of minutes and yep, just has GK, we just give me a shout out on the chat window and that's all I need to get started. I wish you a life with GK. Hey. So good evening everyone who's joining us for this bonus talk. This is the real after-party after the talks that we've had today during the day and if you're here, you will definitely enjoy this one. So to summarize and to see how this talk lines up with the other conversations we've had during the day, we did conclude saying that as and when the governance and data privacy and security laws are coming more and more into mainstream from an engineering and a product lens, a lot of us are tempted to view it as yet another line, that more bureaucratic tape or probably, or yet another process that would probably slow us down wouldn't let us be as agile as I would be. And when we concluded, we concluded with the hope that just as, sorry, just as some point in time, a few years ago when a lot of DevOps practices, a lot of GitOps and other practices were viewed as a bending curve, a bend all over or a turn around the corner, few months, a few years down the lines, the same but also happen with these governance protocols that they would become an established best practice and we would all start adopting them right from the product inception. I think I did make a mistake in terms of saying that it would be a few years or a few months down the road because here we have Nneka Soenka at the absolute pleasure of introducing her. She's the program manager, privacy program manager at Mozilla. And what she's going to talk about is actually a flexible framework that Mozilla uses in order to incorporate privacy from product and an engineering standpoint. And so imagine the space at which we move in our world that a few years ago we were talking about that we hope that frameworks will emerge that help us incorporate privacy, security and governance much more easily than how we look at them today. And here we are with Nneka talking us through the same. So on that note, let's hear Nneka talk about the framework and as we the protocol and as the audience has been extremely supportive, please put in your questions in the Q and A window. Don't forget to upload and at the end of it, we'll have Nneka answer some of the questions till then we let her enjoy the morning coffee and also enjoy the presentation with that. Or to you Nneka. That's someone else's job. Lean Data Practices, Privacy by Design. These concepts, they sound great in theory, but how can I actually apply them in a way that doesn't affect our user's experience or doesn't hinder our innovation efforts? Welcome to our Lean Data Practices class where you will learn practical ways to apply our Lean Data Practices framework in the product management context in a way that still keeps your customers at the center. Today, we'll start first with providing a quick overview of Lean Data Practices and their benefits. We'll then dive deeper into how to apply each of the LDP principles in the product management context. And lastly, I'll leave you with our website and the downloadable toolkit that you can use for your company. So what are Lean Data Practices? Lean Data Practices or LDP is a flexible framework that anyone can use to stay lean and be smart about how they collect data in their organization. Through LDP, you're then able to build trust with your customers. Now there are three pillars to Lean Data Practices. Our first is engage your audiences. Now this is about transparency and being open with your customers so that they understand how you're using their data, what you're doing, who you're sharing it with and are empowered to make the decisions that are best for them. Our second pillar is to stay lean. And this one is all about data minimization and only collecting data that delivers value. And our third and final pillar is to build in security. And this is all about protecting the data that you have. Now there are many benefits to Lean Data Practices. Through LDP, you are able to build and develop trust with your customers. Now this trust comes from many different ways. The trust that you build with your customers comes from easy to understand explanations and a well-designed user interface that the customers can use to exercise their choices in an easy and not confusing manner. It also comes from explanations that are not only clear, but also well timed in the location that your customer would expect to see those explanations. The trust comes from transparency and being open with your users around how their data is being used and the fact that you are minimizing the data of theirs that you are using. If you have other business partners that you of course trust with the user's data, you want to be transparent and build that trust with your customers because you've explained to them why they should trust them too and that you've done your due diligence before deciding specific business partners to partner with. The trust also comes from helping your customers to understand that their data is protected within your organization. And lastly, because issues inevitably do happen, trust comes when you resolve those issues swiftly and when you handle them honestly. Now LDP also helps you to avoid untrustworthiness. Now this comes from collecting user data without explaining to them what you're collecting or getting their permission or helping them to understand how you're going to be using the data, especially if it's in a way that they otherwise would not be expecting. The untrustworthiness also comes when the user interface is confusing for your customers and designed in a way that is difficult for them to really take control over their data. We also see untrustworthiness when human errors inevitably arise and our customers credentials or their data is exposed. And also when the product is designed without privacy in mind. And so it was engineered from the beginning in a manner that resulted in the leakage of data. And then lastly, the untrustworthiness comes from how you handle situations that do arise when the issues happen. And if data breach headlines that implicate you or your business partners put your company's name at the forefront while the untrustworthiness can come from that and can impact your brand. But of course it's all about how you bounce back from that and how you handle those types of situations. So let's dive deeper into lean data practices in the product management context. We'll start with our first principle of engaging your audiences. Remember, this one's all about transparency. Our first tip is to identify your audiences so that you know all of the different stakeholders at play. So who are the audiences for your company, for your product? You have your customers and that could be in the business to customer setting or the business to business setting. You have your colleagues, engineers, product managers, marketers, sales, legal, all of the different parts of your organization that helped make it a success. You have your leadership and you have your investors. Perhaps you're like Mozilla and you have specialized communities that contribute to your success, that are invested in your success and that because they're so specialized, you engage with them in a different manner compared to how you would the general audience. You also have your business partners and your clients. And then lastly, you have the general public perception of your brand. While all of these different audiences are important, today's presentation will primarily focus on number one, your customers. Our second tip is that when it comes to sensitive issues or things that people would find surprising, remember to engage early and be very clear so that you're reducing the chance for them to be surprised by what they're hearing, especially if it's related to something that they were not otherwise expecting. Here's an example from the Mozilla context within our Firefox browser. If I am a user of Firefox and I see recommended by pocket, I might start to think recommended recommendations are these recommendations based off of my browsing history? Are these based off of an algorithm? And I didn't know that they were using my data in this way. If a user starts to have that concern though, they can quickly click learn more to understand how we are actually making those recommendations and rest easy knowing that it's not based on their data and that we still care about their privacy. On the right side though, perhaps the user is still not interested in having these recommendations. Well, they can then take action to remove the section or just hide it if they don't mind it being there, but they just don't want to look at it or perhaps they want even more information and so they can go to the privacy notice to learn more. Here's another example from a privacy notice. It lists out all of the different categories of data that this service is receiving and using. So before a customer engages with this product, they can see all the different types of user data that's being collected from their data partners. Perhaps the customer is okay with mobile ad ID or a cookie ID or an email address, but the fact that the service is also collecting age, gender, income, language, purchase data might give them some hesitation. Well, by being transparent with the data that the service is relying on and helping the customer to understand the full breadth of that data, we're helping to avoid surprises and giving them the ultimate choice in making the determination of whether or not they want to interact and engage with the service based off the information that they know. Our third tip, and this is speaking of privacy policies, don't solely rely on your privacy notice to provide people with information. Engage where your audience would expect to receive that type of information. So as I mentioned earlier, Mozilla has specialized communities that we engage with and one of the locations where we engage is via forums. So depending on the type of information you want to convey, you'll want to find the best location to share that. It could be in a informational or marketing email. It could be specifically within the product or it could be in something like a forum where the people that that information applies to know to look and would expect to hear and receive that type of information. Here's another example. This is a signup screen where someone has to simply enter their mobile number before they continue on with the service. Now, before providing your personal data, you might wonder who are they going to share my data with? Why do I have to provide this? Well, from the beginning on the left side we see we do not share your personal details with anyone. So now customers know before they provide their information that their data is going to stay with this company and it's not going to be shared elsewhere and they are hopefully more comfortable with them giving their mobile number and continuing with the process. Our fourth tip, engage when it matters. Here's another Firefox example. This is from our Firefox nightly browser. There was a change where nightly was now going to be routing DNS requests through a partner service whenever possible and we wanted to make sure our users knew and understood that. This could have been a blog post, it could have been an email perhaps, but the best place to let people know of that change was when they opened the nightly browser for the first time after that change was made. And so we popped up this notification for individuals and as we see here, if people are not interested based on what they've heard, they can click disable and if they're okay and appreciate that we let them know, they can simply click okay, got it and continue on with their browsing session. Our fifth tip is to say what really matters and give details elsewhere. Remember, people do not want to read a lot and we only have so much space to give them the information that we want them to know to get them to continue to use our service. Here's a common example that we've all seen in our personal browsing lives. When someone logs or accesses this website, we see a notification pop up asking, will you allow us to access your location? Now for some customers that generally speaking don't typically like to allow location access, based off of this alone, they can go ahead and say don't allow and continue on. However, for others that generally do allow, they can say allow and move forward as well. And then for that last group that may or may not be okay with it but want to get more information, they can click learn more and read up and on whatever else it is that they need to know rather than providing all of that information to everybody. And here's an example from our privacy policy. So the left side is what anyone will see when they're looking at the Firefox privacy notice. And this is a section that says, hey, if you use these features listed below, then Firefox will share this data to provide you the functionality and improve our products and services. Rather than bulleting out the information for each one of these, we keep it high level so that if someone for example, doesn't use sync and they don't need to click and learn more information for the sync context. Perhaps you do use Firefox accounts though and so you want to click that plus sign to further understand what that means in the Firefox account context. So if someone clicks the plus sign, the information on the right opens up below the Firefox account subheading and then they can see the categories of information and brief explanations on what data falls under that category and how it's used. We also see that there are hyperlinks within. So for individuals that do want more information than what was already provided, they can click to read more. Our sixth tip is to give people options if you don't actually need the data. Here's an example from an account creation screen for premium membership. We see a variety of data fields listed here from email to name to password to phone number to address to profession to annual income. A better option for customers or prospective customers is to let them know which fields are optional or conversely, have the mandatory fields and leave the rest there to give them the choice of whether or not they want to provide that information. To create a premium members account, perhaps email, name, password and phone number and country are critical pieces of information. But if state, city, pin code, profession and annual income aren't actual requirements, then we should reduce the amount of data that we're collecting from our customers and give them the choice of whether or not they want to provide that additional information since it's not essential to running that service. Our seventh tip and this is our last tip, expectations and behavior patterns change. So remember to reevaluate engagement over time. We're learning this all the time at Mozilla. One example here is when we learned that if we compared the engagement of our Firefox privacy notice link underneath a download now button compared to when the privacy notice tab opens separately, there was a lot more engagement with the tab as opposed to the link. But if you're not reevaluating engagement and continuing to check in, you miss opportunities to continuously improve. And so remember to reengage over time. Another example, cookie banners. We're continuing to hear more and more information about cookie banners and what is the most meaningful way to use them so that our customers don't find them annoying or that so that we can consider the consent received through the cookie banners as valid consent. But if you just provided a cookie banner on your website and went about your days and years without reengaging or reevaluating use of the cookie banner and how it was used and what the general public sentiment is, then again, you're missing an opportunity to continue to improve and ensure that you're reaching your customers in the best way possible. So let's recap. Here's some tips for improved audience engagement. First, provide timely and contextual in-product communications through the use of things like permission panels, overlays, onboarding tours and other features that are user friendly and taking advantage of your UI in a meaningful way for your customers. Give your customers choice within the product through things like unchecked boxes or optional fields or accessible controls so that they're really are empowered to make the decision that they want to make and not that they're forced to make. If you have specialized audiences, communicate to them through places like forums, blogs or bugs, we'll talk about our bug bounty program a little bit later. And lastly, remember to reevaluate your engagement over time. Let's talk now about our second principle, stay lean. Remember, this one's all about data minimization. Now our first tip is to stop collecting what you do not need. And here's an example. If you access the Common Voice website, anybody that accesses it can immediately start to use their microphone to speak and donate their voice to the program or listen to other voices to validate the accuracy of what it is that they said. There is a login and sign up feature in the top right, but that's not a requirement for using the service. Now, if someone wants to do additional things, access additional features or engage more deeply with us, then they can sign up and create an account, but that's not a requirement from the beginning for them to use this service. Here's another example. Now here, this company, they're being very transparent before an individual has downloaded their service. They're letting people know the types of data that they do need access to. Now, just like any of us should do within our own roles, we should always look at the data we're accessing and ensure that everything that we're asking for are things that we actually need in order to use the service because when we have a lot of data, that also can scare customers because they do feel like they're giving a lot of it away and so it's helpful for them to understand what it is that we actually need and to only collect that from us. Our second tip is to understand therefore what it is that you actually need versus data that you want. Let's revisit the cookie banner talk. So with cookie banners, there are both essential and non-essential cookies. Essential cookies or necessary cookies, these are ones that are required for the website to operate and so it's essentially mandatory and we don't typically see an opt-in to those because it's needed for the site to run. Now contrast that to your non-essential cookies that might help to personalize the content that your customers see or help you collect statistics or other types of analytics. While those could have benefits to the customer or especially to your business, they're not essential and so we don't want to make it mandatory for customers to provide that type of data. We need the necessary cookies but we want the preferences, the statistics, the marketing cookies and so the choice we give to our customers is going to be different between those two groups. Our third tip is to find your old data and evaluate if you still need it. So I'm going to give you a few questions to think about. When was the last time you looked at the data that you had and considered how old it was? How old is the oldest data that you currently keep? When was the last time that you determined how long you actually need certain pieces of data? Perhaps you originally collected it thinking you needed it for five years but you realize you stopped using it after six months. Or when was the last time that you looked at the data that you were collecting and confirmed that you actually were using all of it? Perhaps for account creation, you were asking customers to provide their name, their surname, their email address but you realize that you only use their email address or you only use their first name and you don't need their surname. These are just a few of the questions that you should ask yourself as you're evaluating the data that you have and whether or not you still need it and of course how you can improve going forward. Our fourth tip is to evaluate your unverified accounts and for those unverified accounts you're going to want to determine how long you need that data. Now an unverified account happens when a customer or perspective customer completes your form to sign up for the service. You then send an email to them saying congratulations, one more click and you'll be signed up with us but they never click that verify or confirm button in the email and so they sit in your systems as unverified. Do you have that today? And if so, how long do you actually need to keep that type of data? They didn't actually complete the sign up process. So short of metrics to understand how many unverified accounts you have and perhaps looking at that over time there's not much value in holding onto that type of data because they didn't complete the process you can't fully engage or interact with them. So look at your unverified account and determine how long holding onto that type of data is helpful for your company. Our fifth tip is to evaluate your inactive accounts and your unengaged accounts. And again, you're going to want to determine how long you need that data. So these are accounts and customers that signed up for your service and for whatever reason, they're no longer engaging. They're not opening your emails. They're not logging into their account to actually use the product. They're not opening the app. How long do you still need to hold onto the data for folks that haven't used your service in two years, five years, et cetera? So consider after you determine how long you need it, getting rid of that data as well and reducing the amount of data that you're holding onto. Now, when we talk to people about this topic, sometimes it can be scary. They think, oh, if we get rid of our customer's data, that's a bad user experience for them. How will they know? What if they later change their mind and then they realize that we got rid of them? So I'll show you two examples now of meaningful ways that we're seeing companies take action and inform the customers without being overly scary. So here's our first example. Subjects line was inactive account cleanup. And they sent to this customer saying, hey, it looks like your account for this email address hasn't been active for a while. In 60 days, we're going to delete you. But hey, do you not want us to delete your account? No problem. Here are the steps you can take to ensure that we continue to keep your information and you continue to use the service. Here's another example. Dear user, we're writing to let you know that we have some new policies for how long we're storing data. Let's summarize those policies. If you're inactive for two years in any of these products, then we might delete that content for the products in which you're inactive. If you don't want us to impact you, so now we move to what this means for you, this is only four people that have been inactive by this date or this amount of time. And so we're letting our customers know if you don't like this, here's what you can do to take action. Our sixth tip is to auto-schedule periodic audits to confirm your policies and making sure that they're being enforced. Now this includes your retention periods, but it can be any policy that you have. It could be who can access certain types of data or who it gets shared with, et cetera. The important thing is similar to reevaluating your engagement over time. You're going to want to continue to reevaluate and check in to make sure that whatever it is that you determine is actually happening. So let's recap with some tips for staying lean. If you don't need it, quite simply, don't collect it in the first place. And if you don't need it anymore, then remember to get rid of it. And if your customers are no longer engaged and they haven't used your product for a long period of time, consider removing them. And then lastly, identify those specific areas for periodic review, also known as an audit, to ensure that your established policies are being followed. All right, that's a very engaging and fun talk. Thanks a lot, Nekha. So for our audience, Nekha is now with us and please put forth your questions. She'll be very happy to answer them. Go for it. So why do you wait for the audience's questions? So just a quick doubt that I had. In one case where you say that there is a need for constantly reevaluating the older data that the company has aggregated over a period of time. And to save some of that and be purged and in order to keep on, have a curated set of data that needs to be managed much more efficiently. In my experience, there could be two roadblocks to that. One, companies that have been really old, companies that exist for, let's say, more than a decade and a half have been collecting data, even before some of these governing rules and policies were in picture, right? Also over a period of time, a lot of this data changes form and shape. For example, he isn't in fancy and it's just a startup. The data that you're collecting could very well be just, let's say in one format and then over a period of time you keep moving, you keep on aggregating more and more data. So as personnel change in the company policy, products change, how feasible it is in reality to go and keep on curating this older data. Because at least I have seen my experiences with data is the moment you talk about data retention, people like, well, can't we just keep it all and keep life really simple because that's one dimension of looking at it. So just wanted to understand your experiences around the scene that is it, how easy or difficult it really gets to evaluate and get rid of your old data? Yeah, that's a great question. And I've seen it in a number of ways at this point in my career and in my experience, to answer the how easy or difficult part of it, it first will start with, does that knowledge exist within your organization? Do you have the right people that even know what data you're collecting, where it's being stored, how long it's sitting there? Sometimes I meet with teams and if you don't have the right folks on the team or no one ever thought to ask that question, especially to your point about it being before the policies existed, then it's going to be a much more difficult battle to have with individuals compared to you're already talking with the people that own the data and they have like a pretty decent handle on it. It also is going to depend on how much data you're collecting in the first place and people in general seem to love data and when you start talking about data retention and disposal after certain periods of time, it can be very scary, especially when you haven't done it in the first place or when you haven't ever done it before. And so because it is difficult and this can be seen as one additional thing on top of people's individual job responsibilities, I try to recommend usually a risk-based approach. When it comes to data, it's not an all or nothing and when it comes to reducing the risk to the data you have, there's also various approaches you can take. And so it could be disposal of the data and maybe you figure out which are the data points you're no longer using or the data points that are the riskiest in the event of a security breach. But then you can also de-identify it, anonymize the data or sorry, yeah, de-identify, anonymize, aggregate it, remove the personal aspects of the data so that perhaps because it's in an aggregated form or de-identified, you still have the data available should you need to do metrics or use the data for certain product development means but the more sensitive parts of the data have been removed. And so when you give people options, when I give people options, it becomes a different conversation when you're able to talk to people and meet them where they are or help them find a solution that still meets their needs as opposed to just saying, get rid of the data, you've had it for too long, you know, no more say bye. So that's a way to make it less difficult and challenging. So there is also, I think there are a couple of questions from the audience maker if you can, yeah. So it'll be great if you could take those as well. Sure. Okay, so I see the first question. How do we keep balance when we get constant requests from data scientists, growth managers, marketers to collect as much data? Aha, yes, great question. So first you are going to want to, if you have existing policies or practices, first see what it is that you all say you do. If you already have a privacy notice, for example, that's a great first step because if that's not clear in the privacy notice or it's something that you say you do not do, well, then you are putting your brand at risk if you are choosing to do something that perhaps goes against what you're already publicly declaring that you use the data for. And so of course, that could be an opportunity depending on what the data is and what the use is. Perhaps you need an update to your notice or perhaps it's a conversation with the requesting team to talk about the risks and perhaps why you cannot do this. You can point to a specific regulations or best practices, competitive, other companies that are maybe more privacy centric, what they are doing to help drive that conversation. Also, you want to look at the type of data that they're requesting and balance that against what your users' expectations are and how comfortable are they going to be with something like that happening. For me, I always try to put myself in the customer's shoes and think how would I feel if this specific product started to collect my behavioral data? Would I be comfortable with that? Would I expect that? Or that be something that would make me want to report that company or put it on Twitter or do something to perhaps tarnish the brand's reputation because it's not something that I would expect. I hear you on just the volume of the requests that you can get from so many different parts of the organization. And so the last thing I would also say is challenge, and I don't mean this to be combative, but challenge your requesters to be able to demonstrate the rationale for why they want this specific data collected or what they ultimately want to do with the data. As a privacy person, I always tell the business folks, like, hey, I'm privacy, you're on the business side, you're the marketing experts, you're the data scientists. So tell me what it is you ultimately want to achieve and then I can help you do that in a privacy preserving manner. Sometimes they just know, ultimately, as a data scientist, I want to be able to measure these specific data fields for the company or we're trying to predict growth for XYZ areas for our new product. Well, once you actually understand what their problem statement is, many times people think it's easier to just collect the raw data, but you realize that there could be other ways to still accomplish that said goal. Another example is asking, okay, here's what it is you want to do, what specific data fields do you need? And in one of my previous privacy roles, I focused only on marketing, primarily at least, and so I was able to dive so deep with the marketers and you would see so many examples of, if you ask them, they'll say, oh, we need their name and we need their email address and we want to track them with their badge ID at events and we want to be able to know their location, their precise location, but then as you start asking the why and understand what it is that they actually want, perhaps it's, do you really need the precise location or is a more generalized location that's not specific enough to the individual? Do you need to know the pinpoint of where they are or if you know their city is that sufficient for your needs? Are you really going to be using all of those data fields or you're only addressing them by their first name anyway and so you don't need those other data fields or whatever it is that they're asking. So when you understand what their ultimate goal is, it's a different conversation with them and you're actually then working together to come up with a solution because many times they're just, we all think and process information differently. So they're thinking of their end goal while we are or while I am thinking through the types of data and how we can still get them what they need in a clean, great user-friendly way but while reducing the privacy risks. And I see another question. Can you please elaborate on legality of we use cookies in Europe and worldwide? Okay, so if I understand this question and I will tell everyone here that I am not an attorney and even if I was, I probably couldn't provide legal advice but if I understand it correctly, elaborate on the legality of we use cookies. So whenever you're communicating with your customers, like the way we communicate, especially as it relates to our data handling behaviors and our things that can impact them from a privacy perspective, we always want to remember we're using language that is clear and ensures that they understand what is happening with their data. And so if you are using cookies, then and I will admit that I may not fully understand this question but if you're using cookies, then you should let them know that you are using cookies and how those cookies would be used and the types of cookies that you are setting. Now from where are cookie banners required perspective, for the most part, it's from that EU, that European context. However, especially because, you know, a lot of us work for global companies or even if our companies are only based in one or two countries, we serve an audience that's across the world. And so you may not know where your visitors are coming from or you might just want to be transparent to anybody regardless of the location where they're based. And so, you know, while displaying a cookie banner may or may not be required in all regions, it can be easier from a business perspective and just more transparent and open for anyone to tell anyone that visits your website that you're using cookies. And now when you're using, I guess I can speak briefly on like a cookie banner specifically, we see many different ways that people are using cookie banners and not all of them are, I guess if you're thinking about the annoying and deceptive part of my presentation, the headline that appeared. Many times, if you pay attention to the cookie banner, usually it says, hey, FYI, we're using a cookie banner and by continuing to use this website, you're inherently agreeing. And continuing to use will be even if they don't hit okay, even if they don't close out of that cookie box, the moment they scroll or the fact that they visited in the first place is going to be considered consent in order to use those cookies. Now contrast that with a cookie banner that pops up when you visit. As you continue scrolling, it doesn't start placing cookies until you say, okay, or I agree. And you can also manage the types of cookies that are being placed. Perhaps the essential cookies are of course on by default, but the other ones are opt out by default and give people the option to opt in for those specific ones. So even though that type of cookie banner isn't legally required in most parts of the world, I hope we can all agree that in terms of what's best from the end user's perspective, what is actually the most transparent for them? What actually gives them the ability to make the choice that's right for them? You know, there's a clear difference between those two types of cookies. And so Miss Berger, I hope I answered your question around elaborating on like the legality of we use cookies. And thank you for the question. All right. Thanks a lot, Nekha. I think we are out of time and this is where we will be computing the day. And once again, thanks a lot, Nekha. This is one of those Saturdays where the start is unlike anything else in a good way. Yep. And also thanks a lot to our panelists. I think we'll have one more question if you're going to take after this while partying. But before that, just a quick teaser for what's to come on day three of our privacy conference. Tomorrow we're going to go a lot deeper and a lot technical. We're going to start talking about encryption techniques, TLS techniques and how these usually apply to the domain that we're talking about, which is we are going to start marrying data privacy, data governance and also data security paradigms. So do tune in tomorrow. And once again, thanks a lot for being an amazing audience. And with that one parting shot, we'll take this question from Shake and then we're going to end the day. So yeah. All right, and I will try to keep it brief because I know it's late over there. While retention and periodic review of data collected makes sense, data is replicated across various layers and you have the, let's see, rich audience profile creation using the first party data. How easy is it to clean up this mess? So definitely not easy to clean up the mess, but I would say what can make it easier is if you understand the data lifecycle and what the flow of the data looks like. So the data might be collected within the primary system and you know that it's being held there for three years and perhaps that's your source of truth. But you know in terms of sharing of the data that every week or whatever the cadence is or real time even, that data is feeding into various models with their own separate retention periods. Each of those separate points that are getting the data from the source of truth, they're all now used for their own separate purposes, right? And so when you wanna look at like retention, while you want to look at it as a full ecosystem, you're going to want to handle those different pieces separately which can also likely make it easier because the use cases for how that data is being used is going to differ. And so if your source of truth might collect the data and have it for five years, but those individual models or whatnot will only need it for a few months because the data for those specific purposes are more stale. We're not getting value from the data after six months or whatever the specific period of time is. So it's not a very clear answer. I agree that it's challenging, but I would just say look at it in silos and also remember that if someone says hey, delete my data, we can't say, well, it depends on legalities and whether or not someone's actually required to for various reasons, but the data's tied up in our machine learning model. Depending on your jurisdiction, that type of response isn't going to be sufficient anyway. We're still going to have to honor it. And so it's better to make sure that we're building things out and there's a flow of things in a way that we can handle the different data points separately without breaking our overall system. And again, remember, you can de-identify the data. There are other ways to handle that retention other than deleting the data that can reduce the privacy aspects of it. But that was another great question from Sheik. Thank you. Nika, if I think something in response to Sheik's question. All right, let's take it down. All right then. Thank you once again, everyone. Nika, a great weekend up ahead and a good week as well. And for our audience and panelists, thank you so much. We'll see you tomorrow. Have a good day evening. Bye. Thank you.