This is the second part of our blog post on the phasing out of third party cookies in Chrome. In the first part we went over the reasons that lead web browser platforms to take a more user-privacy positive approach. We also touched base on how Ad Conversion Measurement will work in a post cookie world.
In this second part, we focus on how Ad Targeting will operate (based on the information available today) after third party cookies are phased out.
2. Ad Targeting
We all know what targeting means in digital, but for those who don’t, simply put, targeting is the feature that allows us, the marketers, to show ads to specific groups of users sharing similar characteristics (gender, age range, location…), preferences (food lover, tech freak, sports fan...) and/or behaviour (visited more than 3 pages in the advertiser’s site, almost bought a product in our e-commerce store…).
Targeting is fundamental. It has changed the way marketing is understood. It has shifted marketing from mass broadcast advertising to a more smart focused Ad exposure. We have become so accustomed to targeting it's practically impossible to imagine digital advertising without it. That's why it plays such an important role in Chrome’s Privacy Sandbox project.
To target an Ad we need the user characteristics/preference/behaviour (from now on, the "data") and this data should come from somewhere. It’s very important, in terms of privacy, to distinguish between first and third party data.
First party data is information that an Advertiser, the company paying for the advertising e.g. https://glasses-shop.example/, collects and stores from users visiting their website. For example what glasses colour do they like, what range prices they can afford or even specific PII data like their email or the telephone number. This data belongs to the Advertiser and can be used for their advertising purposes only if the user has been properly informed and has accepted their terms.
Third party data is information that doesn’t belong to the Advertiser. It could belong, for example, to blog in a field relative to the advertiser e.g. https://glasses-blog.example/. The Advertiser is looking to enrich his knowledge about their blogs users or to target his own users based on this new data or just to find new users that like glasses and expand its targeted advertising reach. If the data seller properly informed the user that his data could be used for advertising purposes, the data can rightfully be shared/sold.
Both data types are legitimate, glasses-shop.example wants to sell as many glasses as possible and for that, it uses its own user data and it also buys data from glasses-blog.example to reach more potential buyers. So, why change things? What’s the problem?
Usually neither glasses-shop.example nor glasses-blog.example have their own custom made technology to collect or transact with data nor to serve Ads, they use a middleware technology provider aka the AdTech platform e.g. https://adtech.example/. There are many types of AdTech platforms, and we won't go into all the specific details, but what it’s important to understand is that the vast majority all collect and store first and third party data.
Just a handful of AdTech platforms are being used by practically all the websites that either buy or sell advertising. By doing so they gain access to many other functionalities within their websites beyond advertising. The companies that own these AdTech platforms, thanks to third party cookies, have been absorbing data attributed to unique Ids (i.e. users) everywhere.
The fact that these platforms are used on so many websites, gives them access to so much data, at scale, to a point that some can even track (almost) the full user's browsing history. Let's think about that for a moment, would you, for example, allow me, a stranger, to have full access to your last year's browsing history? I don't think so.
The proposal in Privacy Sandbox for Ad Targeting aims to change that by making the digital advertising ecosystem more sustainable and privacy-focused so all parties involved gain benefits, even the users.
2.1 Contextual and First party data targeting
There are certain types of targeting that won't be affected once third party cookies are phased out: Contextual and First party data targeting.
Contextual advertising is a form of targeted advertising that takes the words and content of websites as a deciding factor whether to show, or not, an Ad or a set of Ads. For example, if a blog post talks about football, an AdTech platform offering contextual capabilities can deduce the subject by reading the most repeated words on the post and show a football related Ad. This kind of advertising does not violate the user’s privacy as it does not use any user data. Ads are shown "per web-basis".
First party data advertising, like contextual, it is also a form of targeted advertising. The difference here is that it uses user data as a deciding factor to either show, or not, an Ad or a set of Ads. An example here would be when an advertiser uploads hashed telephone numbers or email addresses legally collected from its own website (or other channels) to, for example, Facebook or Google Ads platforms to find these (or similar) users inside those websites. This is also technically possible in-app, but let’s keep things simple. Take note that there are no privacy concerns here as the user willingly provided an email address or telephone number to the advertiser (obviously the advertiser has already informed the user that his data may be used for advertising purposes).
2.2 Interest based targeting
Interest-based targeting pretends to replace what today we understand as Audience targeting. This is closely related to the use and trading of third party user data to target Ads whilst third party cookies are still allowed in some browsers.
Today, on the browsers where third party cookies are still available, AdTech platforms collect all the user’s data and decide "per user-basis" which Ads to show based on the advertiser’s setting in the platform.
This "per user-basis" Ad placement is possible thanks to a series of code snippets living on both advertisers (sites that pay to advertise their products) and publishers (sites that sell Ad spaces) by reading unique ids stored in third party cookies that can be read across different sites.
As explained, this results in huge amounts of data (bound to unique identifiers) being collected from AdTech platforms. Giving them access to the entire track of a user's browsing history, amongst other things. So how can Chrome avoid this happening whilst preserving the ecosystem?
First off, as previously mentioned, Chrome will get rid of all the third party cookies that hold unique identifiers (users) so no party can get full visibility of a user’s browsing history. Secondly, it will limit the amount of data an AdTech platform can collect so they can no longer store (and make use of) "extra" data that doesn’t belong to them.
How are they going to do that? Like with Ad Measurement, by storing and processing all the data into the user’s browser and just disclosing the pieces of data that are strictly necessary for AdTech platforms to perform their targeting. Those required bits of data are nothing but the "interests" we want to target, which Google has since labelled as FLoCs (cohorts).
(this photo is taken from a Google’s post where Interest-based targeting is very well explained. I recommend you read it)
The browser by default, thanks to an algorithm called SimHash, will automatically categorize the user into a FLoC based on its most recent browsing history (i.e #1101) so there will be as many FLoCs/cohorts as there are similar browsing histories across all users using Chrome (Google says about thousands). Those can also change over time as new browsing patterns emerge and users can jump from one cohort group to another if their interest changes. However, a user can only be in one and only one cohort at a time. Chromium (v.89 with flags) already supports this API so you can check what cohort are you here.
Take note that with these changes, users will be grouped and identified together by cohorts Ids based on similar browsing histories instead of being identified by an AdTech cookie ID, which compromises their privacy. We have moved on from a "per user-basis" to a "per group-basis".
To clarify the FLoCs/cohorts functionality, it’s very easy to comprehend how interest targeting will work:
(this photo is taken from a Google’s post where Interest-based targeting is very well explained. I really recommend you read it)
1) An Advertiser, in this case, a shoe store, gets users (visitors) to their site. The first thing the site does once loaded is request the cohort id from the browser. As different users navigate through the site and visit different sections, add products to cart or purchase, they generate signals. These signals (think of them as a type of conversion pixel based on user actions), along with the user's cohort id, are stored on the site.
Once enough data from a cohort is aggregated, the site sends data to the AdTech platforms selected by the advertiser. For example, if a bunch of users from #4569 cohort are interested in soccer shoes, the AdTech platform will receive #4569 and "soccer shoes".
2) A Publisher, in this case, an online newspaper, is also sharing aggregated data with all the AdTech platforms they works with. So, if a bunch of users from #4569 cohort are visiting the FC Barcelona football section, the AdTech platform will receive #4569 and "FC Barcelona".
3) At this point, the AdTech platform, instead of having all browsing data associated to unique identifiers (users) under their control, they just have a cohort identifier (representing a group of users) defined by the user's browser and certain interests associated to it: #4569 => "soccer shoes" & "FC Barcelona"; nothing else.
4) So, if another user belonging to the same #4569 cohort, visits another publisher that serves ads through the same AdTech platform that has been collecting the interests and data, it will know to show the Advertisers FC Barcelona soccer shoes Ad on the Publisher's site.
Under this system, the AdTech platforms continue to be the glue that joins all the pieces together and play a key role in entire the ecosystem's economy. They carry on maintaining and aggregating the user's data, but now as a cohort or group of users. This way the power they wield over the ecosystem is reduced as less data is being fed to them.
2.3 Remarketing
Remarketing is also a form of targeted advertising that targets users that have previously visited an advertiser’s website. For example, if there are a bunch of user’s that added a pair of shoes to their cart, but eventually didn’t make a purchase, the idea is to show them remarketing Ads to pull them back and close the sale.
There are 2 main differences between Remarketing and Interest-Based targeting. First, in Remarketing, a user has to visit the advertiser’s site before a targeted Ad is shown to them, whereas in Interest-based this isn’t necessarily the case. Second, in Remarketing, the audiences (cohorts or, group of users) will normally be created by the advertiser or the advertiser’s agency through an AdTech platform whereas Interest-based audiences (cohorts or FLoCs) are given by the browser.
Remarketing is possibly the area of Googles Privacy Sandbox's toolset that is least ready for the green light as it requires approval and agreement from the heavyweight AdTech companies such as Criteo, RTB House or NextRoll and this takes time.
All the documentation from the progress made so far can be found here. The Google explanation can be a bit too technical so let’s try and outline how they plan things from a pure media perspective.
1 & 2) The most important thing here is that either advertisers, publishers or AdTech platforms will be able to create a Remarketing group that the browser will store. Much like it stores FLoCs in the Interest targeting type. Whichever party that creates the remarketing group has ownership over that group.
3) Once an interest group is created (i.e #8976) and enough users are in it (around 100 users), a user belonging to the group visits a publisher and automatically an auction is run by the browser. It’s important to understand that today’s auction process is run from server-side, the switch to the client-side, the browser, is an important step to ensure that user data stays in the browser.
You may wonder how an auction process could be executed in the browser. To understand this it’s important to know that, at a time an interest group is created, its owner sends some information to the browser:
const myGroup = {
'owner': 'www.example-dsp.com',
'name': 'womens-running-shoes',
...
'ads': [shoes_ad1, shoes_ad2, shoes_ad3],
};
navigator.joinAdInterestGroup(myGroup, 30 * kSecsPerDay);You don’t need to understand javascript, just acknowledge that the browser, at the interest group creation time gets, among other things, the group’s owner and the Ads eligible to be rendered. Groups by default last 30 days, although this can be extended.
Getting back to the auction process, once a user belonging to different interest groups visits a publisher site, the site decides which groups are eligible to participate in the auction and scores them based on the site’s (publisher) own logic. The winning group picks an Ad from the ones it already sent to the browser and the Ad gets published.
This is a very simplified explanation, but I hope it gives you some sense of how the future Remarketing in a post cookie era will look like.
Summary
Replacing third party cookies is a disruptive change to the entire web ecosystem and to the digital media industry. As with any change, it is key to get ahead of your competitors and understand what technologies you should rely on.
Privacy Sandbox isn't the only alternative to third party cookies, but it is the only one backed up by the browser (Google Chrome) that holds nearly 60% of worldwide web traffic. I wouldn't focus on any others that don't have the tech muscle to really make an impactful and sustainable change to the industry.
