Privacy-First Analytics: Mastering Cookies and Data Privacy in Adobe Analytics and Customer Journey Analytics

Transcript

Hello, everyone. Thank you for joining. We will be getting started here in a few minutes. Today’s session will be focused on mastering cookies and data privacy and Adobe Analytics and Customer Journey Analytics led by myself and Riley Johnson. But we are going to wait for some more attendees to filter in, and then we’ll get started for anyone who just joined. We’re going to give it a couple minutes and then we’ll get started. Right. Give it about one more minute. I see we have a few more attendees that are trickling in. All right. Let’s go ahead and begin. All right. Hello, everyone. My name is Sean Holbrook. I’ve been at Adobe for three years now as a project lead and field engineer working within Adobe Analytics and Customer Journey Analytics. My experience in the field is broad guiding customers in their usage of success accelerators based off of their needs, as well as working with clients with their analytics instance to audit implementations, support governments best practices and educate best practices and data analysis within the Adobe Solutions. I also have my colleague Riley Johnson with me. So, Riley, I can kick it to you for an intro. Thanks, John. Yeah, really? Johnson, Technical consultant within the field filled engineering team. I have been working at Adobe Analytics for four years, along with Adobe Target, Customer Journey Analytics, a little bit of AP Tech and you name it now, but I’m based out of the Lehigh, Utah office. I’ve got a beautiful wife and two children here. My oldest turns five next week, which is crazy, and our youngest just turned one in March. I guess it’s not just it’s already August, but yeah, happy to be here and happy to chat through cookie compliance cookies and privacy and all things that are a little bit scary at times. Awesome. Thank you, Riley. Okay, so first and foremost, I do just want to say thank you everyone, for your time and your attendance today. Just to note that this session is going to be recorded and a link to the recording will be sent out to everyone who registered. This live webinar is a listen only format, but is very much intended to be interactive and that as we go through today’s content, feel free to share any questions into the chat and the Q&A pod that you may have. Our team will answer as many as possible there, and in addition, we’ll try to reserve some time to discuss questions that are surfaced at the end of the session. Lastly, will be sharing out a survey at the end of the presentation that we love your participation in to help us shape future sessions. So with that said, I am going to begin the recording and kick things off. Actually, I’m sorry, we are already recording, so I’m going to share my screen. I actually forgot. All right. Welcome everyone to Privacy First Analytics, Mastering Cookies and data privacy in Adobe Analytics and Customer Journey Analytics. Our agenda today includes the following topics. We’ll start off with the best practice workflow of how to ensure proper data governance within the analytics and customer journey analytics solutions. And then we’ll move on to utilizing managers for opt in opt out management. Provide an example. Use case for fallback tracking and opt out scenarios. And lastly, discuss cookie origination scans through a possible field Engineering Success Accelerator. All right. So data governance in Adobe Analytics involves a series of strategies and technologies used to manage customer data and ensure compliance with regulations, restrictions and policies applicable to data use. This process is critical for maintaining data integrity, trust and compliance within your organization. Now, according to the GDPR law, visitors to your website are called Data Subjects, and they’ll be making GDPR requests to your brand. These requests are made to the Adobe Central Service API or user interface and branch out across each experienced cloud product that you are subscribed to within the experience cloud audit organization that you’ve defined. Now, once the request has been processed, Adobe will return a response to you. In the scenario where it’s an access request, you’ll find a file with the data for that data subject. In the scenario of a delete request, you will receive confirmation that the data has been deleted and from there you can format this data however you please and return it to your data subject. What we will discuss today is the workflow of best practices in regards to defining your settings within Adobe Analytics so that your data is processed however you see fit. The examples provided in this webinar are high level best practices for the workflow and specifics on labeling. Data, for example, is not a recommendation as those details should be decided on by your organization. And I’ll be presenting this section in the order of the workflow that Adobe considers best practice. So starting from the beginning, your organization needs to align on several key decisions of your privacy requirements and the kinds of identity data that you collect from your customers. You’ll then want to set your data retention policy, and then next, you’ll want to familiarize yourself with data privacy labels, Adobe Analytics, IDs, namespaces and ID expansion. Then you actually want to proceed in assigning the labels to each variable in a specific report suite. Connect to the data privacy API or UI. And lastly, view and manage your report Suites Data Privacy settings to ensure ongoing compliance with any changes in beta usage or legal requirements. So for the first step, in order to effectively manage privacy requirements, identity data and CRM integration within our privacy service, several key decisions need to be made, and these decisions revolve around understanding your organization’s privacy requirements and the types of identity data collected. So diving a little deeper than that. You’ll want to think about legal and regulatory or a compliance such as, you know, what data privacy regulations apply to your organization. What are the specific requirements of those regulations? What types of personal data are we collecting and how are we collecting it? So. Are you collecting names, email addresses, IP addresses of the web analytics or mobile apps? What are our data retention policies as long as data kept? And what is the process related to deletion? Who has access to the data within our organization and what analytics tools and platforms are we using? The next step is setting your data retention policy. Adobe Analytics retains data for a specific period of time, which varies depending on contractual agreements. This policy impacts all analytics reporting capabilities. So Adobe as a data processor assists customers in fulfilling access deletion and other data privacy requests in compliance with regulations such as GDPR and CCP is obviously very crucial and applying secure deletion policies is part of that compliance. Now, some key points here include the fact that the default retention in that period is 25 months and can be reduced or extended upon request. Extensions are available in increments of one year, up to a max of ten years and one month. And once data exceeds retention, Adobe does reserve the right to delete it without recovery options. Now some key steps in setting your data retention policy should be let’s include all the stakeholders. Let’s include the marketing, analytics and privacy teams, determine that window and then in the scenario where you need to reduce or extend, contact your Adobe Account team. Reducing retention period is of no charge, but extending it does require a purchase. Okay. Next, we want to familiarize ourselves with data privacy labels, analytics, IDs, namespaces and ID expansion. But before we do that, you’ll see on this slide a screenshot of how you can get into the tool to manage these features. You’ll want to get into Adobe Analytics, click on admin and find the data governance privacy labeling link. Once you click on that link, you’ll see the privacy labeling for data governance user interface, where we can assign our components, the proper labels. And as you can see, I’ve highlighted the columns that identify why the identity and sensitivity labels. Okay, So data privacy labels in Adobe Analytics are used to classify data according to its sensitivity and the privacy regulations that it must comply with. These labels will eventually help you manage data privacy requests. So they come in a couple of different flavors, right? We have identity data labels bucketed as AI one or I2, which is directly identifiable or indirectly identifiable, directly being things like name or email address, and indirectly it might be something like a CRM ID. And then we also have sensitive data labels, right? So as one would indicate, precise geolocation, whereas SE two indicates broadly defined geo locations. Moving forward, we have privacy labels which include the following HCC all in HCC person, which is data to be included in all data privacy requests or requests specific to individuals. Delete all or delete person data to be deleted and all data privacy deletion requests or requests specific to individuals and IED device and i.t. Person, which is data that can be used to identify either a unique device or a specific person. Now Adobe Analytics also uses various types of IDs to track and manage data, and some of these might be familiar to you. We have the air ID or the Adobe Analytics ID, which is a legacy tracking cookie. The ID which is a more modern identifier that’s persistent across all of your experience cloud applications. And then you also have custom IDs. So again could be like a CRM I.T. Right. Namespaces namespaces in Adobe Analytics are custom strings that identify IDs in any variable used across all report suites. They help in searching for specific IDs during data privacy requests. And here you can see I have the namespace structure which includes the namespace field, the type and the value. An example of that would be the namespace here would equal email. The type is analytics and the value is the actual email address. And then we have ID expansion, which in analytics is a feature that allows the inclusion of associated data and data privacy requests. And this is useful for ensuring that all of your, you know, all relevant data is included in these access or deletion requests. So maybe, for example, different cookies or device IDs. Hey, once you familiarize yourself with all of these terms and determine the privacy requirements within your organization, you can head over to the privacy labeling for data governance user interface and begin assigning the appropriate labels to each variable in your report suite. Now you’ll want to use the dropdown here on the top right to toggle between report suites and keep in mind, when you click on a specific component in this list here, you are able to edit the labels and you can also you also have the ability to copy the applied labels into other report suites. On the left you’ll also see that you have the ability to filter your categories for quicker and easier searching of the components of okay, so the next step is connecting to the data Privacy API in order to submit access and delete requests. And to do this, you need to follow a systematic approach. And this includes understanding the Privacy Service API. So this API allows you to manage privacy jobs programmatically. This includes creating, retrieving and managing privacy jobs for access and delete requests. The API is designed to help you comply with data privacy regulations like GDPR and EPA by enabling this automated processing of data subject requests. Next, you need to set up your authentication so before making any API calls, you need to set up authentication, which involves obtaining an access token and setting up all the necessary headers for your API requests, such as API key or your org ID and so on. Then you’re going to set up your privacy job. So each job contains identity information related to the data subject, metadata about the experience cloud product and the jobs processing status. Then you’re going to submit the access requests. And in order to do that, you need to specify the type of requests and the identities involved. And then for delete requests, again, you need to specify the identities to be deleted. And then lastly, you want to monitor your job status. So after submitting a job, you can monitor its status by querying the jobs endpoint. And just a couple of best practices here. When dealing with a high volume of IDs batch them into as few requests as possible to optimize your performance and avoid misuse. So the privacy API should not be used for data cleansing or non data subject initiated requests because this could lead to some unintended consequences downstream. Also, as you can see in the very bottom screenshot, you can also submit access and delete requests as well as monitor statuses within the private within the privacy UI available on your experience. Cloud Main Dashboard. Okay. So the last step in this process is to include regular reviews and updates of your data privacy settings and and all your labels. And this is essential to maintaining compliance with any new legal requirements or or changes in the way that you’re using your data. You’ll also want to maintain audit logs of changes for accountability purposes. And so all of this really includes your privacy settings management, where you can enable the consent or consent management opt in or opt out includes data governance and labeling as we just went through. But it’s important to, you know, review and ensure that each variable is appropriately labeled to reflect its data privacy status. And also whenever new variables are introduced or existing variables are repurposed, again, your data retention policy, just making sure that you regularly, regularly review and update that to comply with legal requirements or your own policies, and then monitoring and compliance and just regularly checking that status of all those submitted privacy jobs, either through the privacy UI or via an API endpoint. Okay. So now let’s discuss just a bit more briefly data governance and customer journey analytics. The biggest point that I want to make here is that generally speaking, data governance related settings and CGA are inherited from Adobe Experience Platform. Also, much of the basis of best practices here are similar to Adobe Analytics. And so rather than repeating myself, I’m going to focus this section more so on the key differences between the solutions. Our overall workflow stays fairly consistent with the steps for Adobe Analytics. We’ll start by asking the, you know, the important questions and working with your organization to determine your requirements. Since data governance related settings are inherited from ADP, it’s imperative to consider all applications in the step, not just chain will then set our data retention policy familiar to familiarize ourselves with the data usage, labeling and enforcement framework or door and its components will then label the data within APP for privacy requests. We’ll use Privacy Service to submit privacy requests and lastly, we’re going to again monitor those privacy jobs. Okay. So determining privacy requirements and the thought process behind that, again, is very similar to what I’ve already mentioned in this last section. Aside from that one major caveat that’s very important, we need to consider all Adobe Experience platforms and their applications that will be used. So since the scope of this webinar is confined to Adobe Analytics and CGA, we’ll move on to the next step. Okay. So here we have a comparison chart where we are going to focus our attention on the right side under Adobe Experience platform to manage your usage. The connections UI lets you define customer journey analytics, data retention as a rolling window and months at the connection level. So one month, three month, six months, etc… The main benefit here is that you store or report only on data that is applicable and useful and delete older data that is no longer useful. This helps you stay under your contract limits and reduces the risk of overage costs if you leave the default unchecked. The retention period will be superseded by the ADP data retention setting. So if you have 25 months worth of data, for example, an experienced platform, CGA will get 25 months of data through backfill. Now if you deleted ten of those months and platform CGA, we would retain the remaining 15 months. Data retention is based on event data, timestamps, data set timestamps I’m sorry, and applies to event data sets only. No rolling data window setting exists for profile or lookup datasets and this makes sense since there are no applicable timestamps. If your connection includes any profile or lookup datasets since they’re joined with event datasets, the that data is retained in CGA based on your data retention settings. On the event data set timestamps. Next, we’ll want to familiarize ourselves with dual or the data usage labeling and enforcement framework and begin assigning labels. Now the platform provides these features to take complete control over governing your data from the point it’s collected at data sources to when it’s sent to destinations outside of the platform. The framework is based on labels, policies and enforcement. And first, you would classify data using your labels. Then you can author governance policies that define usage restrictions. And lastly, those policies can be enforced when the data is being used. So one call out here is that when labeling, you may see some extra options aside from the ones we’ve already gone over. These include contract labels which categorize data that has contractual obligations. So an example of this, you can you can use, let’s say, ac3 contract label to indicate that that data cannot be combined or otherwise used with directly identifiable information. You also have the option to create custom labels which categorize data based on your specific business needs. And remember, data privacy labels are inherited from the Adobe Experience platform level, and you can label your data and schemas and our data sets namespaces, IDs and I.D. expansion are all handled through API as well. Also, when we think about how platform resolves policy violations and S.J., for example, a data view would provide warnings or completely stop a user from, let’s say, like creating metrics or dimensions from from sensitive fields. Okay, now that we’ve covered data labeling, let’s look at policy management. AEP provides the ability to define usage label. I’m sorry, I define data usage policies based on their corporate, legal and privacy guidelines. A governance policy describes what kind of data usage actions are not allowed based on the classifications applicable on data. Two features are provided here governance labels and marketing actions or analysis actions. The example I provided a moment ago covers this, right? So again, you can use a see through contract label to indicate that that data cannot be combined or otherwise used with directly identifiable information. AEP provides out of the box core policies, as well as the ability to define custom policies in order to fit your own needs. While those policies are defined and enabled, applications such as CGA can enforce these policies at the point where data is used for specific actions, the following steps occur when enabling governance enforcement. First, all the classifications for data requested for usage is retrieved, then all the marketing and or analysis actions for which data is requested is retrieved. Once the labels and actions are retrieved, any violations against policies can be checked, and if policies are violated, data usage can be controlled within CJI, CGA To honor those policies, all four of these steps can all be performed using the Privacy Service API or the Privacy service UI. And lastly, platforms approach to governance is not just about restricting usage, but also to help you make informed choices on what you can do to mitigate the violation and continue delivering customer experiences. Whenever a policy violation occurs. Enough context is provided about why this happened, and this includes a list of violated policies as well as a lineage analysis. And by analyzing this lineage analysis, you can figure out how the activation you are trying to perform or the analysis that you’re trying to perform caused violation. Based on this information, you can decide on the course of action, right? You can, you know, edit the governance settings based on your needs. All right. That concludes this portion of the webinar, and I’ll kick it to Riley to take it forward. Thank you so much, John. Appreciate you going through how we can manage our data once it’s in Adobe Analytics and all the consider all the the policies we can put in place to make sure we’re not using data we shouldn’t be. I’m going to cover today is not collecting data when we shouldn’t be. So we’re going to be discussing cookies. We’re going to discuss in consent managers and lightly touching on CCP GDPR like regulation. So if you can hit the next slide formation. So the first thing we’re going to talk about today is going to be consent managers. What is a consent manager? A consent manager is a tool that’s designed to manage and document all of the consent for all the users on your website. They’re critical in ensuring that we are compliant with data privacy laws and regulations. So what do consent managers actually do so they can they manage the collection of the consent in a transparent and straightforward manner? They are making sure that everything is presented in a clear, understandable way so that users know what data is going to be collected or what data is being collected on those users of the website. They provide information of how the data is going to be utilized once it’s collected, and then offers easy solutions for the users to opt in. Opt out, they manage the consent that is being selected by the users, so the cookies and things will be utilized to ensure that the consent accepts or opt ins or opt outs are managed and maintained for repeat or repeat visitors. They’re automatically going to update systems and processes based on the changes of these consent. So if I go in, I often and then, you know, two visits later, I then opt out the consent manager is going to be managing all of that for us. And at a store, the consent as well. They need we need a way to be able to to report and show how many interactions with consent forms we’ve had, how many opt in, opt outs and things like that. And then they ensure that consistent records are easily accessible for audits and compliance checks as well. So as we move on, why do we need a consent manager? Consent managers are needed because of the privacy laws, right? Data regulations. They typically come in two flavors. And now looking at this slide, it looks like I’ve voted yes on CCP and voted no on GDPR. That wasn’t the intent here. But with the two flavors we have CCP like regulations and a GDPR like regulations, CCP like regulations. The key idea here is that it’s an implied opt in, meaning that when a visitor visits the website, it’s implied that they have opt in to tracking. They’ve opted in inherently. And so all of your typical cookies, all of your typical tags, everything’s going to fire as if they’ve manually selected an opt in option within the consent manager. So if a visitor doesn’t want to be tracked, they will have to explicitly go and find the consent forms or find the cookie tracking policies on the website and select the opt out of tracking that. On the inverse, we have GDPR like where the key idea is that it’s an implied opt out. Once the visitor hits the website, it’s assumed that the visitor has not given consent for tracking. So nothing will fire. No tags will fire, no cookies will be set until they’ve actually opted in to the tracking of the data. And when I say no cookies, I mean there’s there’s still going to be some cookies. Right? I’m talking about tracking and analytics data, identifying cookies and things like that. And next slide permission. So how do these consent managers work then? So again, consent managers, they’re designed to manage and document the user’s consent, right? So here’s like a very, very simplified flow. We have a page load or a site interaction with somebody visits the website. The first question asked for these consent managers is have they opted in? So the first thing we’re talking about is, yes, Next slide for mission. Yes, they’ve opted in. What is it going to look like now that they’ve opted and everything’s going to flow as expected? Right. The user selects opt into the data. Consent managers are going to relay that information to Adobe tags. If you’re using Adobe tags as the tag manager or whatever tag manager you’re utilizing and then Adobe tags or your other tag manager is going to begin firing those tags to collect data. So Adobe Analytics would fire Adobe Target Audience Manager Your ECI ID, the experience Cloud ID would be set with that identified that individual as a unique visitor and it have the full data collection. All Adobe identities and all the custom variables that are implemented within implementation and just full sets of data will be then collected to those users who’ve opted in. So let’s take a look at the inverse then for the opt out, how does it work with opt out? Same flow the user lands? Have we opted in? No, we haven’t opted. They’ve selected to opt out of the cookies and data collection. So what happens here? Same thing, same flow that the consent manager will pass the data to your tag manager and then no data will be collected, right? No identifying cookies will be set, no tracking or marketing tags will fire anything like that. And so all of it’s going to be just suppressed and not sent through and to server calls. So let’s look at high level Adobe recommendations and general approach of how we should be approaching consent managers deciding which ones we should be using and implementing these. So obviously, first things first, we need a team alignment. We need to identify internal key stakeholders from privacy and compliance teams and or legal team members. They are the ones that are going to be the final deciding excuse me, the final deciding voices on which cookies should should not be tracked within the flow of analytics data. These decisions need to be made, you know, across the organization and clearly identified as to why and why not. We’re tracking these cookies. So what consent manager should we be utilizing? So some questions that we can ask ourselves in determining which consent manager tool or consent management tool we should be using. What features does this tool supports? Are there specifics that we need or don’t need? How is it going to be able to communicate with Adobe Tags or a different tag manager system? Is there partnerships in place between Adobe and these other consent managers? So just some basic questions that need to be asking for, which could set manager should be using here. And then privacy, Privacy law alignment clearly define which regulations you need to have applied to your properties, your web properties, and when where they will apply. Obviously within GDPR, if you have any interactions with the UK, you know web properties in the UK, you need to ensure that you’re compliant with GDPR just a little less Ccpa, GDPR, LGBT, CNIL and many, many more and many more to come regarding privacy or data privacy and regulations as well All right, so one last thing to call out here is what’s the expected impact for opt out and implied opt out selections? So potential data loss is going to be 100% of bounces. A bounce is a single page visit if we’ve opted out or if we have the implied opt out like a GDPR flavor data privacy, then we’re not going to see those single page visits, right? We’re not going to have information on that first visit until they opt in. Are we going to then be collecting data? We’re going to be losing all of our bounce data, 100% of first page views and of new and of the new opt in visits will be lost as well will have potential loss of marketing channel data. Right? Marketing channel data, the first touch information and we can see how they’ve landed into the site, but without any data collection tags, we won’t know how they’ve made it to the site. And then any accurate entry dimensions. Entry dimensions are the variables that are set on the first page of the visit. And because we have the data collection tag on those first pages, we’re not going to have any of that information. Estimates had been suggested that at least 70% data loss would occur for opt out regions, when in reality we’re seeing clients report the we’re losing up to 90% of data on those first page visits are first hits. And even just 90% of data collection on those opt outs as well. We lose a lot of data. We we are limited in what we can collect and how much we can collect right? But all of this assumes that the ITP will never prevent cookies from being deployed by the content or the consent manager partners. So like one trusts as they manage the privacy preferences, right? If we lose the ability to set cookies on consent management, then absolutely going to lose the ability to collect the data. Right. With this new privacy push coming through, we’re going to lose the ability to to to collect the data and identify unique individuals or unique visitors. So all that said, we’re losing data and not being able to collect the data from opt out scenarios. There are opt out tracking potentials. The biggest thing here is that this is not a one fits all and this is not a recommendation by Adobe. You know, as everybody knows, Adobe, isn’t your privacy a legal recommendations team were your technical implementation team. So definitely take this as oh it’s possible to implement something like this but. We definitely need you to be checking internally with your team’s legal and privacy teams to ensure this is something that you can’t or want to be doing within your organization. So there is a way that we can do a fallback implementation. So there’s other factors for the fallback tracking information. Is that global reach, how much data is going to be collected, which regions are going to be there, etc., etc… So let’s look at what we could collect with an a fallback tracking situation. And so same kind of flow, right? We have our opt out situation, but instead of suppressing all Adobe Analytics calls, we could still collect some very, very basic information about these about these visits. Now, we cannot be identifying individuals with a cookie with a unique ID cookie, and we can’t be collecting data that’s going to be able to identify those individuals as well. And we can’t use the information for remarketing information too. So we have no tracking cookies. So no tracking our identity. Cookies can be placed or stored for the people who’ve opted out. The IDs that will then be used are going to be fallback IDs or legacy IDs like Shawn had mentioned previously within Adobe Analytics, and that’s going to be utilizing a concatenation or combination of user strings and IP addresses. So what data can be collected, you know, very minimal data can be collected here. Again, we can’t be using any of this information for remarketing information. We’re going to see site interactions. We can’t look at, you know, flows or behavior of these individuals. But we can see what’s, you know, something that has happened on the site so we can obtain the domain page, URL, friendly page names, opt in status, opt out status, and then the events that are happening on there. And the technical hurdle here is going to be the analytics is typically disabled in opt out scenarios. So there’s going to need to be some custom code. And if we go to the next slide on, there will need to be some custom code that’s implemented here. So I’ll go very high level. I know we have like 17 left. Hopefully I can get through this that quick and if there’s any questions, we can address the questions at the end as well. But this is going to be like a typical flow of what this type of of fallback tracking is going to look like for the implementation. Now, again, that’s not a recommendation. This is just an option of some ways that it’s been done in the past by other clients. So seats on the bus, we need to identify which team is going to be part or which team members are going to be a part of this implementation team for a fallback tracking. Again, we need to make sure that we are including legal and privacy teams to ensure that they’re giving us the green light of what can and can’t be tracked in these fallback implementations. We need an analytics business representative who understands the business needs as well as the data within Adobe Analytics and how those two tie together. And then an analytics technical representative or technical team member that’s going to be able to implement and do the work on that. So designing this out. So obviously you need a co-operatively design. What’s going to be approved by the privacy legal teams Analytics business provides the tracking options. Legal will give us the red lines of what can and can’t be and then approve the solution. So some examples fall back to the work we just saw previously. Domain page URL, friendly page name, opt in statuses, and then if there’s any events of opting in, opting out, number three is going to be building out the solution. So one trust is one of our partners that we recommend utilizing within for the consent management. So within one trust, one trust sets a cookie based off of the selection of those users. And these are just the cookie values that are set here. And so what we would do is we take the cookies that are set here and then we would use custom code within Adobe Tags that’s going to send a page view with the data from step two when we have a functioning cookies at the c0002 up to 6004. And so those values we can send Adobe Analytics data on according to one trust. And so when they select that, you know we can send analytics data but not any targeting information, then we can use the c0002 cookies and then it will build out the logic that’s going to say if that cookie is set to that value you will send these Adobe Analytics tags and then it will send the rules for the opt out scenarios. And then obviously with like opt in with any time that, you know, the values specifies that it’s an opt in to everything and it looks taxable fire the rules with all of the values there. So you’ll need to customize this to your needs though. So not every course could set manager is going to have the same values obviously for their cookie values but you can create custom code that’s going to review the cookies. If there’s no extension within it, there’ll be tags that’s going to review the review those cookies and them based on the different the different values. So one of the requirements here, I know we’re getting very technical in here, but the server call requirements do require if you’re using custom code tracking server reports with it. And then these three creation parameters AQ b seal and aq e aq B starts the server or starts the server call seal means that there’s a cookie lifetime of none, and then aq e is the end of a server call. So very technical. Take it for whatever you can do to but all the features can be configured and set up based off of your needs. There. And the number four is just going to be validation. We need to build a deliver to a dev environment first. Absolutely. Every time building with data collection or doing any kind of dev work for data collection, we need to be doing it in a dev environment. Bing being there, making changes into production environment and just following all that new implementation stuff into production is very dangerous. So definitely need to make sure that we’re sending this test data into a dev environment, validate page level server calls with opt in, opt out statuses, and then you can pull any clickstream data that you need to from data feeds to make sure that you’re looking at visit type to make sure we’re looking at. I visited visit type one for this opt outs, which is going to be that fallback idea that Shard was mentioning previously and then monitoring reporting, building out workspace reports. That’s going to take a look at the opt in statuses, opt in opt out events and then just see what the trends are of how people are interacting with the sites. And then that’s it for that fallback. Now, there’s an appendix at the end of this deck that has a bunch more technical support in a potential solution for fallback tracking. So if you’re interested, we can get those additional deck slides over to you. So call to action. What can we do going forward then? How can we ensure that cookies are, you know, being set when they’re supposed to be? Or are consent managers working the way that we intended to be? So this is for for teams or for organizations that already have a consent manager in place. So maybe you don’t have a consent manager and you want to just see what cookies are being set Like what I mentioned at the very beginning, we have a license with Observe point, if you can hit the next slide for mission observed. Point is an automated tool that’s designed to help ensure that we have accurate and consistent digital digital analytics and marketing data through tag auditing at TAG governance and web analytics audits. So this is a bot that crawls through your site and intercepts every server call that is made on your site. So this allows us to see every single tag Adobe Analytics and third party tags that you have on your site. It gives us a snapshot of the health of those tags. How long does that tag take to fire? And then it gives us a snapshot of the inventory of those tags. Which pages are missing, those tags, which pages have those tags? And the same thing goes for cookies as well. We can evaluate all of the cookies on your site using this, this, this tool. Now, like I mentioned, Adobe has license that we can offer this solution or this read out as a service for. Our clients within the field engineering team and within the Adobe Consulting Services as well within professional services. So these automated audits, they help us identify and fix data issues before they really impacted business decisions. Again, privacy compliance, we can take a look and check for the privacy compliance of the cookies that we’re trying to set and a tag governance, ensuring that we are firing tags when we’re supposed to be and the tags are present on pages where they’re supposed to be as well. So next slide is just a little snapshot of one of the options that we have. So this view that we’re seeing here is just a snapshot of the cookies from Adobe dot com. I walked through and we can set up two different scans. We can scan to look at the opt in cookies and we can set up a scan of the opt out cookies. And so this is the difference we can see. So 159 cookies being set on opt in, 132 cookies being set on opt out. And we can do a comparison against the two to know what cookies were removed and which cookies stayed on the opt out scenario. And then validating against your business use cases is are these the intended cookies that we need just to be here on the site within the opt out scenarios? So again, work with your customer success managers or your technical account managers. If you are on ultimate success contracts and get a field engineering activity put into place that we can help you out with one of these cookie origination scans. And Shawn, I think that is yeah, that’s everything that I have today. I’ve been keeping an eye on the Q&A and chat pod and haven’t seen anything. Maybe it’s because nobody has access to them. Not sure. But if there’s any questions, please feel free to the chat. Oh, I saw a come through. Looks like we do have there. Yes. I just see. Yeah. Lots of insights. Thank you. Could you share the slides with the documentation links? How can we register for the upcoming webinars? Good question. Let me reach out to the manager of this program and and we’ll be sure to get her to reach out to you also. Yeah, this deck will be sent out after this call, I believe, sometime next week. And so you should receive that. And then this presentation and yeah, the recording will be provided on experience league as well. And so it can be accessed on the fly when needed to. Yeah. And really we have another question. If the user opt out and declines, if the user opts out and declines cookies to the target test run. A great question. It won’t run effectively if we lose the ECI. The experience cloud ID cookie, we’re also going to be losing other cookies are going to help identify and identify or help identify which test that user falls into. So I don’t have a ton of experience on on cookie consent within Adobe Target, but my expectation is that we would not run the target tests if the user has selected to opt out of tracking or targeting information of targeting cookies. What’s your guidance on the recent Google announcement regarding third party cookies? Third party cookies within Chrome make it very tough, right? Safari has already put in place an expiration of 24 hours for third party cookies. Our our recommendation and guidance for the third party cookie deprecation is going to be utilizing what’s called a C name. It’s just a DNS server resolution to make it look like the cookies are being set as a first party cookie from your domain rather than a third party cookie from the Adobe domains are the Adobe servers. The web SDK actually sets cookies as first party cookies much, much better and allows us the ability to store those for a little bit longer as first party cookies. So the web SDK is going to be the the fix for long term implementation. Brant You let me know the Chrome had pulled back for that for right now. Yeah CROSSFIRE you’re on like this battle of like oh we’re going to announce you know super hard privacy regulations and then end up pulling it back or extending when that’s going to be released or implemented. Yeah. Thank you, Brant, for Orion for putting that out. Just a quick call out. I did drop a link in the chat. If you could all just take. I think it would take you. Maybe 60 seconds. It’s two questions. One’s a yes or no and one is a little more open ended. If you could please just take 60 seconds and do that before you leave this meeting, we’d really appreciate that some. Any other questions? Give it another 30 seconds to a minute. Thank you, Gabrielle. Okay. And thank you all for your attendance today, your time. It’s very much appreciated. Yeah. We hope you all have a great rest of the week and hopefully we’ll see you at the next webinar. And Happy Olympics. Thanks for the.