While no one can yet predict the exact makeup of the post-cookie shakedown, it’s worth getting to grips with some of the options that are likely to be in the mix, says Phil Huxford, head of partnership development at real-time advertising and infrastructure company IPONWEB…
Recent YouGov research commissioned by data company Fifty-Five found that only 24 percent of marketers were developing post-cookie plans for targeting potential customers.
There are many potential reasons for this hesitancy, not least Google moving the date for the final depreciation of the third-party cookie back to late 2023 (from an initial timeline of early 2022). There is also the complexity and uncertainty of finding an effective but privacy-compliant replacement for a tool on which advertisers have relied for many years.
And a further obstacle came at the end of November, as the Information Commissioner’s Office (ICO) warned against new solutions that “seek to continue ‘business as usual’” – a blow that could see several products currently in development head straight for the cutting room floor.
But while there is no obvious path to take at the moment, marketers can do a good amount of homework to ensure they know what the foundations of their post-cookie strategy should – and shouldn’t – look like.
Identifiers (IDs): deterministic versus probabilistic
You can roughly divide IDs other than third-party cookies into two categories: deterministic and probabilistic.
Deterministic solutions are directly tied to a specific user. An email address is the most common example, usually gathered with consent during the sign-in process: the email address is encoded to make this privacy-compliant, but still targetable. However, such solutions depend on first-party audiences registering on the publisher or advertiser site, so how broadly an ID can be used is limited in proportion to the scale of the users agreeing to authenticate.
The issue of scale is partially tackled by probabilistic IDs, although this is still challenged by publisher ID adoption. Probabilistic IDs use various user device oriented touchpoints (screen size, device type, OS, etc) to infer an approximate device identity, rather than a direct, granular ID of a single person. However, it’s not hard to see that data inconsistency is a risk, as well as it being difficult to identify the same user across different devices. Longevity also needs to be weighed up because fingerprinting, already disallowed by Google and Apple, is a core component in a number of these solutions.
ID-based options operate across publishers, browsers and devices, but while they are widely presented as an alternative to third-party cookies, users are still identified through some other data asset.
Browser-based options
Google’s Privacy Sandbox is the framework proposed by the tech giant. The intention is to protect users’ privacy when they are online, while also enabling advertisers to reach their target audience and measure the effectiveness of doing so. It comprises of various solutions, including FLoC (Federated Learning of Cohorts), TURTLEDOVE (Two Uncorrelated Requests, Then Locally Executed Decision on Victory) and FLEDGE (First Locally Executed Decision over Groups Experiment).
FLoC is one of the submissions getting plenty of attention. It uses the browser to track the content a user is consuming, then sorts these users (via machine learning) into similar cohorts based on their interests. The groups are large enough to maintain anonymity while still enabling media buyers to reach their target audiences. The case against FLoC is whether it is compliant with current privacy law, particularly in Europe. There are also hints that Google will change its categorisation from cohort to topic, but this is yet to be confirmed.
While FLoC is focused on targeting groups of users based on browsing activity, TURTLEDOVE is based on actions undertaken by the user on a specific advertiser site, ie: it is a retargeting tool.
FLEDGE sees the activity relating to ad auctions take place at the browser and device level, rather than at the ad server level. The aim is to limit the amount of data in ad systems and bidstreams, thereby making it difficult to build user profiles, which in turn protects privacy.
Other adtech players have also entered the browser-based fray, including Criteo with SPARROW, MAGNITE with PARROT and Microsoft with PARAKEET.
First-party focus
In the general upheaval caused by the demise of the cookie that is challenging the way digital advertisers have always reached people online, a key point is often overlooked. Third-party cookies are disappearing, but a peek in the cookie jar will show that first-party cookies are still very much present.
First-party cookies are derived from first-party data – which, with user permission, publishers are at liberty to collect from their owned and operated sites. Brands and advertisers may also have their own data gathered from their own sources. Private marketplaces (PMPs) and data clean rooms allow audiences to be shared and segmented in a way that is safe and compliant.
However, there is a caveat with this approach: when publishers rely solely on their first-party data, buyers potentially miss out on benefits such as the reporting intelligence afforded by the cross-publisher framework of alternative IDs, which enable things like cross-site frequency capping and measurement.
Testing times
As things stand today, there really isn’t a general consensus about how the post-cookie landscape will shake out. Rather, the belief is that it will probably be a mixture of some of the above and incorporate other options too, such as contextual advertising.
But even without a clear path ahead, gaining knowledge and insight on current thinking is paramount if marketers are to maintain the functionality offered by the third party cookie. At the same time, the current stay-of-execution provides a good opportunity to trial and test out the various alternative options as they continue to evolve.
Phil Huxford
Head of Partnership Development
IPONWEB
.png)
.png)
Cropped.png)
.png)
Cropped.png)
(1)Cropped.png)
_2.png)
