How Revive Adserver is affected by blocking of third party cookies
Introduction
In the previous articles in this series, we started by explaining what third-party cookies are, next we discussed at a high level how the Revive Adserver software uses third-party cookies, and then we discussed why some people are concerned about third-party cookies.
This article explains what the effect on the Revive Adserver software is, when browsers no longer allow the creation of third party cookies.
The developers of Google Chrome have announced that they’re phasing out support for third-party cookies in their browser, although the deadline for the complete phase-out has been shifted several times.
In this article, we’ll have a closer look at the way the Revive Adserver software is impacted when third-party cookies no longer work in a browser. We’ll go over each of the types of cookies that exist in the context of Revive Adserver, what their purpose is, and what the effect on the end-user experience and the ad server functionality is if that cookie type gets blocked.
The names of the cookies start with either OA or OX, which refers to OpenAds and OpenX respectively. These are the names that were used in the past for the software that is now known as Revive Adserver.
We’re going to discuss all the cookies grouped by functionality, more specifically the cookies used for frequency capping of campaigns and banners, for frequency capping of zones, for delivery blocking, for conversion tracking, and for miscellaneous other purposes.
Please note that what follows is not intended to be a detailed technical description of how every type of cookie works in the code. To keep this article understandable and relatively brief, we’ve simplified the description a bit, so that we can keep this accessible to as many readers as possible.
Frequency capping for campaigns and banners
In order to perform frequency capping for campaigns and banners, the Revive Adserver software uses 4 different types of cookies:
OACAP:
these cookies are used to store the data for frequency capping of a banner. These are permanent cookies.
OACCAP:
these cookies are used to store the data for frequency capping of a campaign. These are permanent cookies.
OASCAP:
these cookies are also used to store the data for frequency capping of a banner, but only for an individual browser session. They are deleted as soon as the browser is closed or the duration of a session expires.
OASCCAP:
these cookies are also used to store the data for frequency capping of a campaign, but only for an individual browser session. They are deleted as soon as the browser is closed or the duration of a session expires.
The purpose of the cookies used for frequency capping is to limit how frequently a specific banner, or all the banners of a campaign, can be displayed, for example at most once per 15 minutes.
Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to respect the frequency restrictions that have been defined for campaigns and/or banners. As a result, the Revive Adserver software won’t display banners that have frequency capping defined (either directly or at the campaign level). This is because it has been designed to be conservative when cookies can’t be created for whatever reason.
Frequency capping for zones
In order to perform frequency capping for zones, the Revive Adserver software uses 2 different types of cookies:
OAZCAP:
these cookies are used to store the data for frequency capping of a zone. These are permanent cookies.
OASZCAP:
these cookies are used to store the data for frequency capping of a zone, but only for an individual session. They are deleted as soon as the browser is closed or the duration of a session expires.
The purpose of these cookies for zone frequency capping is to limit how frequently a zone can be displayed, for example at most once per 15 minutes or only on the first view in a session. This feature can be used, for example, to expose a high impact zone (like one that is very large at the top of a site’s page design) less frequently in order to improve the visitor experience.
Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to respect the frequency restrictions that have been defined for zones. As a result, the Revive Adserver software won’t display any banners in zones that have frequency capping defined. This is because it has been designed to be conservative when cookies can’t be created for whatever reason.
Delivery blocking
In order to prevent the delivery of a banner more than once on a single page, or even the delivery of another banner from the same campaign on a single page, the Revive Adserver software uses 2 different types of cookies:
OABLOCK:
these cookies are used to store the data that a specific banner has been displayed on a page
OACBLOCK:
these cookies are used to store the data that a banner from a specific campaign has already been displayed on a page.
OABLOCK and OACBLOCK are permanent cookies, but they expire automatically after 30 days.
Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to respect the defined blocking rules for banners or entire campaigns on a single page, meaning that a banner could appear multiple times on a page. Visitors will be able to notice this change, banners that showed up only once on a single page can now appear multiple times on that same page.
If the web developer uses the ‘asynchronous javascript’ invocation code in order to display the ads on the page(s), delivery blocking will still work even without third party cookies, because this type of invocation code performs the ad selection process for all zones in a single process, without the need for cookies.
Conversion tracking
In order to perform conversion tracking, the Revive Adserver software uses 2 types of cookies, for 2 types of conversion attribution respectively:
OXLIA:
these cookies are used to store the timestamp of the last time a particular banner was viewed. LIA stands for Last Impression Attribution.
OXLCA:
these cookies are used to store the timestamp of the last time a particular banner was clicked. LCA stands for Last Click Attribution.
The purpose of these cookies is to determine if a “conversion” can be attributed to either the last time a banner was viewed or the last time a banner was clicked. At the time of the conversion event, the Revive Adserver software will look for the relevant cookies and the timestamp recorded in them. If the timestamp is within the duration of the conversion window that was defined, the conversion is considered to have occurred and it is marked to be attributed to the specific banner.
If the campaign that the banner is part of does not make use of conversion tracking, these types cookies will not be created. But if they are created, both OXLIA and OXLCA are permanent cookies, meaning that they will not be removed when the browser is closed. However, they do expire if they’re not updated for a period of 1 year.
If the campaign that the banner is part of does not make use of conversion tracking, these types cookies will not be created. But if they are created, both OXLIA and OXLCA are permanent cookies, meaning that they will not be removed when the browser is closed. However, they do expire if they’re not updated for a period of 1 year.
Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to store the timestamps for the last impression and/or the last click on a banner, and as a result the ad server will be entirely unable to perform conversion tracking. Visitors will not notice any difference in their interaction with the ad server, this will only have an effect on the conversion statistics.
Miscellaneous uses
OAGEO
This cookie stores the geographic location of the visitor’s device. The location is determined by taking the IP address of the incoming request and performing a lookup in the MaxMind GeoIP2 or GeoLite2 data files. This will return location indicators like country and city.
The purpose of this is to be able to use the location that’s established during the first interaction between the ad server and the visitor in subsequent interactions. This improves the loading speed for the visitor and it reduces the burden on the ad server by preventing lookups on every single interaction.
OAGEO is a session cookie, meaning it is deleted when closing the browser.
Once browsers start blocking the creation of third party cookies, the ad server will no longer be able to store the established location in the OAGEO cookie, and as such it will have to perform the lookup on every single interaction. From a functional perspective, this won’t make a difference to the end user experience, but it does come with the disadvantage of increased loading times on subsequent visits and with increased load on the ad server. It is unlikely that visitors will notice this change, but it might have a measurable impact on overall page loading speeds.
OAID
This cookie doesn’t have any specific purpose in the core Revive Adserver software at this time. In fact, since version 4.1.4 of May 2018, this cookie is given the value 01000111010001000101000001010010 for any and all visitors. This is the binary representation of the acronym GDPR. The cookie has been left in place in the code in order to avoid unintended consequences of completely removing it, for example for third party plugins that might still be using this cookie.
From the perspective of the Revive Adserver software itself, blocking of the OAID cookie by browsers will not have any impact (negative nor positive) on the system. Visitors will not notice any difference in their interaction with the ad server.
OXBLC
The Revive Adserver software can be configured to ignore multiple clicks on a specific banner in a specific zone. The click will still work and the visitor will be redirected to the landing page, but it simply won’t be counted. This setting was introduced in 2008 when it was noticed that visitors had a habit of double clicking banners because that is what they were used to on their desktop operating system like Windows. This setting is disabled by default.
These cookies are used to store the timestamp of the last time a particular banner in a particular zone was clicked. If the next click occurs within the timeframe for ignoring click-counting, the click will not be logged before redirecting the visitor.
Once browsers start blocking third party cookies, the ad server will no longer be able to record the timestamp of a click, and therefore it won’t be able anymore to respect the setting to not count multiple clicks within the specified time. Visitors will not notice any difference in their interaction with the ad server, this will only have an effect on the statistics.
Conclusion
As described above, the impact of blocking third party cookies in the Revive Adserver software is significant. This affects all installations where the ad server is on a domain that’s separate from the domain of the website where the ads are being displayed, which is a very common practice for reasons of performance and scalability. It’s also a very common way of displaying ads from a single ad server system to a group of websites owned and operated by one or more companies.
Looking at the functional description of the uses of cookies, we feel that it is reasonable to say that these use cases for cookies are benign and do not violate the privacy of site visitors. The Revive Adserver software is technically incapable of the practice of “following people around across the entire world wide web” that many people dislike, a practice that has been widely adopted by big companies like Google and Facebook. It is ironic that Google has now decided to start banning third party cookies for exactly this reason. Independent and harmless applications like Revive Adserver suffer from this move.
What’s next in this series?
In the next article in this series, we plan to discuss how we can partially address the impact of reduced functionality by the blocking of third party cookies by browser developers.
Articles in this Series:
What are Third Party Cookies?
This article explains what a cookie is, and what the difference is between a first-party cookie and a third-party cookie.
How does Revive Adserver use Cookies?
This article describes how first party and third party cookies are being used by the Revive Adserver software.
Why are some people concerned about 3rd party cookies?
We discuss the extensive use of cookies for retargeting, causing them to be labeled harmful by some people.
How is Revive Adserver affected by blocking third-party cookies?
We look at the effect on the Revive Adserver software, when browsers no longer allow the creation of third party cookies.