 Hello, everyone, and welcome to our Privacy Sandbox for Publisher Series. This is Webinar 2, and I hope you found the first Webinar on Tuesday to be incredibly informative. My name is Christian Heizer, and I lead the Central Eastern European News Publisher Partnerships Team. I'm going to kick us off today with a very brief refresher on what we discussed during Webinar 1. What is the Privacy Sandbox? It's a 100% open source and collaborative initiative where we are committed to maintaining user privacy by default. Through a depth of collaboration with the industry in the testing and trading of our privacy enhancing technologies, which is a series of around 20 APIs, it is our goal to ensure that we protect a user privacy, as well as be enabled a healthy and digital ecosystem and economy. We are moving away from a world that has been highly dependent on identifiers as the critical infrastructure of the Internet. Into a future privacy-first world where we are able to continue to transact the digital economy level while ensuring user privacy by default through privacy-preserving APIs. All the APIs we have shared with you have been generally available since 2023. This means that you and your businesses probably have already or can already start testing, training and implementing these APIs. You may know that in January 2024, we began to phase out 1% of the third-party cookies. Later this year, in close consultation with the competition and market authority, we will begin to phase out third-party cookies entirely, starting in Q3 2024. On Android, please stay tuned for more information. We will be able to share with you a similar roadmap that we will build out in the mobile ecosystem. With that, please allow me to introduce to you my dear colleague, Scott Friesen, who will share with you the ads APIs for Privacy Sandbox. Scott, over to you. Thank you, Christian. Hi, it's me again, Scott. In this section, we will cover more in detail how the APIs for ad relevance and measurement of the Privacy Sandbox work and what their data flows look like on a high level. By now, you should know that the Privacy Sandbox initiative is focused on keeping people's activity private across an open and free internet. Publishers rely on ads to keep content as free and broadly available as possible, and advertisers help people discover new products and offers that they may want. We shipped new features in Chrome that enable websites to show people useful ads based on their activity with different parties without revealing the user's identity to those parties. But how does the Privacy Sandbox achieve this? The Privacy Sandbox Privacy-Preserving APIs shield the identity of users and restrict the amount of available data. There are two ways in which this is possible. The first is hiding identity. Most digital ads today rely on exchanging user identifiers between parties, which allows for easy re-identification of a user across different apps and websites. In contrast, the Privacy Sandbox platform does not provide a cross-site or cross-help user identifier. Instead, it aggregates, limits, and noises data provided to advertisers to prevent user identification. The next way we do this is by minimizing data collection. Without a user identifier to track an individual's activity across sites and apps, third parties, such as ad tech providers and data brokers, are limited in their ability to build cross-context profiles on individuals, unlike what's possible today with third-party cookies. In addition, the Privacy Sandbox limits the amount of cross-site information that can be learned about a user at a given time, which curtailes the potential for large-scale data collection that exists today. As you remember, there are three main advertising-focused APIs. We generally expect they will be most useful at different stages of the marketing funnel, as you see from top to bottom here. Topics and protected audience are known as the relevance APIs. Topics provides high-level signals of a user's interest, which may be combined with contextual signals and first-party data to select relevant ads. Protected audience supports more granular remarketing use cases, where marketers want to reach audiences who've shown interest in specific brands or products in a privacy-preserving way. Attribution reporting is the Privacy Sandbox proposal for privacy-preserving campaign measurement, providing aggregated performance reports on view-through and click-through conversions. As noted before, we expect for the privacy-enhancing advertising solutions that the Privacy Sandbox will be one of many building blocks and not a standalone solution on its own. AdTex can leverage privacy-safe signals such as first-party data and contextual, combined with machine learning to optimize their ROI for their clients. But let's dig a bit deeper to see in more detail how the APIs work and how they can meet the needs of publishers. First is topics. In a nutshell, topics enables interest-based advertising but without cross-site third-party tracking. Websites are mapped to a public list of recognizable topics. When the topics API is called on a particular website, both the API caller as well as the topics that are associated with that website are stored locally on the user's device. Each week, the user's browser runs an on-device algorithm to convert their browsing history into the top five topics for the week, with a total look-back window of three weeks. There's also a 5% chance that a random topic could be mixed in. When the user visits a publisher's website that has ad inventory available, the publisher's SSP can call the topics API and receive a limited subset of the top topics back, more specifically one topic per week, so three in total. These topics can then be used as enrichment in the bid request, in addition to first-party and contextual data that will help the DSP determine the right bid and select a relevant ad, taking all of these signals into account. It's important to note that topics is not a contextual signal about the publisher site that the user currently visits, but a course signal about potential topics of interest based on all kinds of websites recently visited. It tells you more about the user, not about the current page. Here you can see what a typical topics flow would look like in more detail from a publisher site to DSP and back. In a first step, an SSP observes and collects topics from a browser through the presence of their ad tags on a publisher site which are triggered by an ad request. This step ultimately enables the SSP to later on retrieve topics from a user's browsing history for future bid requests. So now it's later on that same SSP receives an ad request from the same browser but on a different site. This time, however, the SSP may choose to enrich the request by including the topics received from the browser based on recently visited websites like site1.com and others. To obtain bids, the SSP shares bid requests with their participating DSPs which determines its bid in part based on the value of that topic for them. Finally, the SSP scores each bid received in order to identify the winning bid and passes the winning ad to the site so that it can be shown. Next, let's talk about protected audience, formerly known as FLEJ. The API enables on-device ad auctions to serve remarketing and custom audiences again without cross-site third-party tracking. At Root, companies define interest groups, for example, people who have visited the advertiser's site and browse beach vacations. And then it structs the browser to add users to said interest group. The interest group membership is stored by the user's local browser. When the user visits another site with available ad inventory, the browser initiates an on-device ad auction to select a relevant ad that matches a user's interest group. It's important to note that this happens on top of the contextual auction, usually executed by ad servers or SSPs to see if there's any interest groups available that wants to place an even higher bid due to the user's previous engagement with the website where that interest group was created. So how does the data flow look like in more detail within protected audience? The DSB's tag code is usually present on publishers' pages when they render an ad. In the first step, the API enables the DSBs to request a browser to be joined to an interest group based on their logic and the interaction with the site. This step enables DSBs to retarget browsers based on their interest group membership on other sites. In the next phase, another site with ad inventory requests an ad from an SSP which shares a respected bid request with their participating DSBs and a notation of a protected audience auction. DSBs respond with their respected bid, including their protected audience bidding sequence. The SSP receives all bids and scores them in order to pass the winning bid to the ad request code. As top level seller, the SSP configures the protected audience auction, including signals locations and shares the winning bid from the traditional auction to be used as a floor price. The protected audience auction is initiated in a protected environment, and the SSP takes care of inviting all present interest group voters to bid and scoring their responses. Should the highest interest group bid be the winner versus the traditional auction, the respective interest group based ad will then be rendered. Lastly, the attribution reporting API gives access to different types of insights that an advertiser and ad tech provider may access via event level reports which help provide transaction level information such as when a specific ad click or view likely resulted in a conversion. And summary reports which deliver richer, more detailed conversion data such as purchase value or ROI over groups of people. Now let's see how they work. When a user sees or engages with an ad on an publisher's site, the browser will register that event. When that user later converts on the advertiser's site, the website will alert their browser that a conversion event has occurred. The browser will then match the conversion event to the initial ad, give it credit for that conversion, and schedule a measurement report. Privacy measures such as delays, noise and aggregation service are applied to deliver an anonymized report to the advertiser. As before, let's look at the flow in more detail within attribution reporting. For example, we are looking at event level reports. On a publisher's site with available ad inventory, the ad text ad tags register a new source for event level reports and link a respective source ID to an event like a view or click or impression. This is stored in the browser. Later on, a pixel or tag triggers a respective conversion event on the advertiser's site to the trigger data equally in that browser. The browser then links both the source of an ID with the trigger data and sends an event level report with a timing delay and noise to the ad tag. Hopefully you now have a better understanding of how Privacy Sandbox APIs work to enable relevant ads and to measure results. For each of the new relevance and measurement technologies, we've also ruled out new ad privacy controls in Chrome that allow people to manage how the Privacy Sandbox technologies may be used to deliver the ads they see. These controls allow users to tailor their experience by customizing what ad topics they're interested in, what relevance and measurement APIs they want enabled, and more. For example, with topics, users can view and control how their cross-site data is used to personalize ads in a more intuitive and accessible manner compared to tracking mechanisms like third party cookies. Publishers also have additional controls with the Privacy Sandbox by updating your site's permission policy. For example, a site can choose to opt out of topics calculations or can control which third parties have access to topics on your page. Lastly, if you'd like to have a better visibility of companies participating in testing of the Privacy Sandbox technologies, we recommend to check out the tester list within GitHub for each API. In these lists, you can check the role each company has in the tests, as well as their planned schedule, published results, and a contact option. These lists were created specifically to facilitate the coordination of testing between different parties of interest. I hope this session was useful to understand more in detail how the APIs work and what their expected flow will be in the ecosystem. I'll now hand it over to Andrei to tell you more about how to prepare your site. Thank you. I'm Andrei Patsev from the Neo Privacy Sandbox partnership team. My job is to help companies and organizations that rely on Chrome to deliver their products and services, and specifically right now to help them understand the implications and prepare for the changes to Chrome's handling of third-party cookies. Before we dive right in, let's do a brief recap of what we know about cookies. Very brief, I promise. It all started back in 1994 when Lumen Tully, a web browser programmer at Netscape Communications, created web cookies. They completely transformed what web pages were able to do. You could store sessions, you could sign in, shop, come back to where you were in any user journey imaginable. Magic. Cookies were so useful that over the past 30 years we've all been collectively piling up functionality that relies on them. And now we need to reimagine how web pages can continue doing all the amazing things that we love them for, but without relying on cookies quite so much. Q. Chrome's Privacy Sandbox. It's the initiative that entails the deprecation of third-party or cross-site cookies in Chrome that we're going to talk about today. Everything we talk about today is covered in more detail at good.gl cookie countdown, so make sure to check that out once we're done here to get access to all the reference materials and tooling. And once you've filled out our feedback form, you'll have full access to all the resources that I'm referencing today. First off, a reminder of what we mean by third-party cookies. Third-party or cross-site cookies are simply cookies set or sent by a different site. It doesn't matter who that site belongs to. If it's a different site, it's third-party for our purposes today. And it's these cross-site cookies that Chrome is deprecating. When is this deprecation happening? The short answer is now. Chrome has started the process gradually with the 1% of our users, and pending input from regulatory bodies like the UK's CMA, we're aiming to be done by the end of 2024. There are four main steps you need to take to prepare and we'll cover each of those in a little bit of detail. They boil down to see what's happening, see what's breaking, make the changes you need to make yourself, and ask those you're working with and relying on to make them too. Step number one, check your site or service. We have a whole video on this, so check that out separately at good.gl3bcd-audit, and I'll cover the basics here. Check your code for cookies with the same site non-attribute. These are intended for use across sites. If they are yours, why are you setting them with this attribute? If they aren't, these are your prime candidates to dive deeper into. You can also see block cookies as issues in Chrome DevTools. These versions of Chrome, these are displayed as errors. Even if you don't handle the development of your site yourself, you can pass this information on to your development team. And because we know you love extensions, we built one for you. You can find it on GitHub and directly in the Chrome Web Store as the Privacy Sandbox Analysis Tool. This is a Chrome DevTools extension and it also comes with a very handy command line interface. You can grab it at the link that we'll share with you and make sure to provide feedback. It's meant to make your cookie debugging easier, so let us know if it does and what else you'd like to see in it. Let me briefly show you some of the current capabilities that can take you quite far on the discovery and debugging part. The most straightforward way to get this extension, as I said, is the Chrome Web Store. Grab it at bit.li.pset-webstore and start receiving cookies insights immediately and directly in your browser window for any site that you're on. Then open up Chrome Developer Tools and there'll be a new tab waiting for you with richer information about the cookie dependencies of the page that you're on. Remember to enable the Chrome DevTools protocol in settings to get the full debugging capabilities and turn it back off when you're done debugging. I actually recommend using a separate install of Chrome, like a developer version like Canary, if you can for debugging so it doesn't interfere with your regular browsing. Then you can leave CDP on. You get a wealth of well-structured data about the cookies on the pages you visit. And there are nifty filtering options available so you can zoom right into areas of special interest. And if you wanted to speed up and scale up your debugging, there is the command line tool for you. It allows running the extension from the command line, both for single URLs and for sitemaps to produce aggregated reports for sets of URLs. In this case, any set of URLs can be presented as a sitemap and you can even debug several sites simultaneously. In the report, you get back the information per URL submitted. All right, clearly by now you must be very keen to verify if cookie deprecation affects your site or service. Again, we have a whole detailed video on this at good.gl-3pcd-test, so be sure to check that out. But in a nutshell, we got you. If you're watching a recording of this later, after full deprecation has been announced, you can simply open your site and crawl. For now, though, we have a flag you can use. Test your site, site by site, with and without cross-site cookies and run through some common scenarios. Account creation, login, checkout, interacting with various embeds, and so on. And if you find breakage on your site or on any other site you might be browsing, especially if the breakage on your site is not something you can fix by yourself, I'll put a link on that in a second. Please report it via this link, so we at Chrome can take a look and figure out how to deal with that. All right. Now, let's talk a little bit about the actions you and your development team can take on your own website or sites. First of all, you guessed it, we have a whole video on this at good.gl-chips. Chips stands for cookies having independent partition states. A bit of a mouthful. It is basically about adding a partitioned attribute to the cookies that your site or services sets in a cross-site setting, so any data flows remain restricted to that pair. And if your site or service are embedded or used on yet another site, that pairing would also be partitioned and no info can be shared across these partitions. Check out the link in the documentation for more implementation details and patterns. Yes, of course. We have a detailed video covering it, too. That one is at good.gl-chips. If you or your organization own and run multiple sites, you can combine them in sets within which cross-site cookies are treated as first-party and certain other APIs, like Storage Access, operate with fewer restrictions. There are three types of sets. One, cctld for sites like example.com, example.afford.de, and so on. You see examples like that on the screen. The size is unlimited for this type of set. Two, service sets for sites that are not actually indexable or intended to be directly viewed by users. This can be cdns, for example, like cdnexample.com, from which your images or videos are served. This is also unlimited in size. And finally, associated for domains whose affiliation with the set primary is clearly presented to users. A g&about page, header, or fuller. Finally, there are a few new APIs you might want to take a look at, especially if you're running not only a site, but also a service used by other sites. We don't have time to go over all of these in detail today, so please check out all the links in the description and in the information that we share with you if you find the application relevant to your service. The important thing to remember is that these are not replacements for third party cookies. They are a new generation of web technologies to take us to a new level of functionality while safeguarding user privacy. Experiment with them, try them out, combine them with each other and with other signals, and please do provide feedback and ideas. It is our web, so let's build it better together. And in that spirit, these days the majority of sites are composed of solutions provided by multiple organizations. Think of your social login buttons, your chatbots, your video and maps embeds, and the list goes on. To make sure that your sites go through the transition to post the party cookies web in top shape, you need to ensure that the products and services you're relying on are ready for it. Make a list of all the services that you're using. We talked about the tooling that can help you with that above. And start making some choices. Do you still need this service or is it redundant? If you need the service, is the provider ready to operate without unpartitioned cross-site cookies? If yes, there might be updates you need to download, install, or otherwise integrate. If not, do you want to work with them as they pivot into this transition? Or finally, do you want to consider other available options in the market? Think of these choices as due diligence. You had a list of criteria when you first selected these services, right? Well, now possible reliance on unpartitioned cookies is one criteria you can add to your due diligence list for peace of mind and a successful, sustainable and privacy forward website. Before we wrap, there's one more thing I wanted to make sure you're aware of. For limited time, you will be able to request Chrome to continue allowing third party cookie usage for your service or on your site. Be mindful that this is the last resort option where you have exhausted all the others and need extra time to find the solution. More details on that in the links that you see on the screen. Let's recap. To prepare for the upcoming or ongoing, depending on when you're watching this, deprecation of third-party cookies in Chrome, you need to audit your third-party cookie usage, test for breakage, migrate to the relevant web APIs and related solutions, analyze your cookie-based third-party service providers. With that, thank you for being with us. Please share your questions and ideas in the comments and in the GitHub repositories for the solutions that we have covered today. And now, over to Hanne, who will give you a summary of the last two sessions and the main call-to-actions for you as a publisher. Hi, it's me again, Hanne Dormester-Inch, Director of Privacy Partnerships for EMEA at Google. Now that you've heard from Scott and Andre, I want to take this opportunity to summarize what you've heard, reinforce a few key messages and encourage you to take action. As you've heard, we are experiencing a fundamental shift in how people expect online experiences to protect their privacy and businesses are under increased regulatory obligations across the globe. As a response, the Private Sandbox Initiative was created to collaboratively develop new alternative technologies for key use cases that today rely on third party cookies and cross-site identifiers. Additionally, Private Sandbox combats harmful practices like covert tracking that undermine user privacy. As of today, the Private Sandbox Initiative has developed over 20 proposals and technologies with input from several web stakeholders, such as ad tech companies, publishers, regulators and others. The main ad's APIs available on 100% of Chrome browsers and ready to test today are Topics, Protected Audiences and Attribution Reporting. They replace less private mechanisms that have been used to run key online advertising use cases and thus help to remove the need to utilize legacy technologies such as third party cookies. Ad techs are the predominant integrators of these technologies and they are already re-imagining their solutions with the help of these and other privacy-observing signals. In addition to the ad's APIs, Private Sandbox has also developed technologies such as chips, related website sets and user agent client hints, plus many more to help preserve trust and usability in the open web as well as to combat covert tracking techniques that harm user privacy. For these privacy APIs, website owners are the main integrators of the technologies. They help strengthen privacy boundaries across sites and ensure online experiences continue to work when third party cookies are deprecated in Chrome. So, we are approaching the utility testing phase of the Private Sandbox and are helping everybody play their role by making sure that ad techs continue to re-match in their services with privacy-observing signals that agencies, advertisers invest in privacy-observing solutions and finally that publishers open up inventory to validate real-life integrations enabling end-to-end testing for the ecosystem. And this is all with the goal to actively test the Private Sandbox technologies for the ecosystem. To facilitate testing across the ecosystem, Chrome has disabled cookies for 1% of Chrome browsers and is offering consistent labels across several population sizes. This enables testing in true, cookie-less environments. We expect testers to share their interactive results with the CMA by the end of June to feed into CMA's evaluation period. This will start no sooner than 1st of July and last for 60 to 120 days. Following that evaluation period and subject to addressing any remaining competition concerns by the CMA, Chrome will start fully sunset third-party cookies on 100% of browsers by the end of 2024. So, what are the three main calls to action for you as a publisher? In essence, you should be preparing, adopting and testing. So, first of all, prepare. If your site uses third-party cookies and I'm pretty sure it does, it is time to take action as we approach the deprecation of third-party cookies in Chrome. Or, did your cross-site cookie usage, utilizing our Chrome DevTools or the Private Sandbox Chrome extension? Identify cookies set by third parties, speak with your vendors to see if they have plans for the third-party cookie phase-out and review data flows within your domain portfolio. Second of all, adopt. Adopt new Private Sandbox technologies and migrate to the relevant APIs such as chips and related website sets to enable specific types of cross-site cookie use cases and access while retaining user privacy and key web experiences on your domains. Validate that your use cases are working properly and report breakages if needed. And last of all, participate in testing. We encourage you to participate in the testing of the app's APIs by publicly voicing your interest either on GitHub or to your web tech partners and opening up inventory for testing via your monetization products such as Previd. If you want to be even more involved and your products allow for it, we encourage you to update your reporting capabilities to analyse the impact of Private Sandbox APIs on your inventory.