The fight against blocked cookies – What are the complexities involved and how can Ad-Tech companies overcome them?
The background of this topic is present here:
We spoke about what will happen if all browsers embrace the Safari default setting for third party cookies. To summarize, it will deeply affect the relatively small entrepreneur space: DSPs, SSPs, retargeting players, behavioural targeting players, DMPs and so on – all this because an efficient and cost effective method for user identification (cookie) would go for a toss.
Let us look at this from the perspective of retargeting with RTB. Every major RTB seller supports the cookie-matching service, a standard service available for buyers to store user data in either their RTB servers or a hosted RTB server with the seller and match this user data against a publisher user ID. https://developers.google.com/ad-exchange/rtb/cookie-guide provides a good overview of this service.
For example, in the context of Google, a retargeting buyer like Vizury fires a cookie matching pixel every time a user visits its advertiser. This pixel returns control to Vizury and passes on the Google ID of the user. So, Vizury would be able to store the following kind of table in its database (or a database hosted on Google):
With Vizury ID out of the picture because of the Safari default, Google as well as Vizury would still be able to recognize a Vizury user based on Google IDs and store Vizury User Data in their table. Hence retargeting would still be functional for Google, Yahoo and Facebook despite the Safari default.
Now, let us consider a typical third party publisher that does not own any first party properties: for example Rubicon. Rubicon would not be able to stamp / use its cookies with the Safari default on.
But what this represents is a market opportunity for Google / Facebook / Yahoo to provide a user identification service to Rubicon. This could be in the form of a dedicated system of servers that allows third party players to access user data in real time at a nominal price per call (or per user). Rubicon could then retrieve user IDs in real time through this dedicated service and use these user IDs to sell its inventory / analyse user trends and so on. This can be depicted in the following diagram:
Figure 1: Depicts the existing way of tracking users, through a cookie on the user’s browser
Figure 2: Depicts the proposed way of tracking users, through cookie matching server-server services of first party ad exchanges
Of course, there are many other ways to monetize this kind of a service, but we leave the rest to the imagination and gusto of the reader.