How does Revive Adserver use third party cookies?
Introduction
In the first article in our series on cookies, we explained what a cookie is, followed by an explanation of the difference between first party cookies and third party cookies.
This article follows up with a more detailed look at how the Revive Adserver software uses both types of cookies.
Revive Adserver uses cookies in 2 areas
The Revive Adserver software has 2 major components:
- The ad management user interface (also often referred to as the admin UI)
- The ad delivery scripts
Each of them uses cookies, but each in a different way. In some cases, the cookies are by definition first party, and in other cases, depending on how the ad server is implemented on a website, the cookies are third party.
First party cookies in the Revive Adserver admin UI
There is literally just a single cookie involved in the admin UI. This cookie is used to record a session ID, and therefore it’s aptly named “sessionID”. It ensures that once a user logs in, and continues to work in the UI, they won’t have to provide their username and password every time they navigate to the next page.
The session ID in itself is just a random value, completely meaningless, unique, and different for every new session. The same user can be logged in on multiple devices, and they’ll have a different session ID on each of the devices. The value of the session ID refers to a row in a table in the Revive Adserver database, and the details of the user’s session (like the timestamp of their last activity) are stored there.
When the user logs out, the session ID is discarded, and the corresponding row in the database for the “old” session ID is also deleted. Then a new session ID is generated and stored in the same cookie, but since there is no corresponding database row (because the user is not logged in), it won’t let them access the user interface beyond the login form.
In addition, this sessionID is stored in a “session cookie” which means it expires and gets deleted at the end of the user’s session, for example when they close their browser or shut down their computer. When a user logs in and then doesn’t interact with Revive Adserver for a prolonged period of time, the session becomes inactive and the user will have to log in again (resulting in a new session ID as well).
And finally, it’s a first-party cookie, so it is not affected by the demise of 3rd party cookies. This particular cookie illustrates an extremely valuable use case for cookies: storing a value (in this case the session ID) so that it is available in the next interaction with the system. This is actually precisely what cookies were designed to do in the first place.
How does Revive Adserver use third party cookies?
Let’s set the stage for our explanation:
- Let’s assume that the Revive Adserver software was installed at this URL: “www.adserver.com”.
- Let’s also assume that the Revive Adserver system is being used to display ads on a website with a different domain, for example “www.website.com”.
- In this scenario, when you visit the website, and the website contains ads from the ad server, your web browser is dealing with two related but technically separate systems, the website and the ad server.
Here is what happens while the ads are being retrieved and displayed:
- When people visit the site, their browser receives the content from www.website.com. That’s the primary system their browser interacts with.
- As part of the content of the site, their web browser will also receive one or more javascript code snippets for the actual ads, and these code snippets reference the ad server URL at www.adserver.com. So that’s a secondary system their browser is also interacting with.
- From the perspective of the browser, and the site it is interacting with, the ads are coming from an external source, so that’s why it’s called a third party.
- If the ad server tries to create a cookie, that cookie is technically associated with that external third party source, and therefore the cookie is also referred to as a third party cookie.
A practical example of the benefits of a third party cookie
We’d like to give a practical example of how the Revive Adserver software makes very good use of third party cookies. The software has a feature called geotargeting. It can be used by the ad server to determine if an ad should or should not be displayed for a site visitor, on the basis of their geographic location
Let’s imagine that the aforementioned website is operating in North America, so the United States and Canada. One of their advertisers is a supermarket chain operating in Canada, which doesn’t have many reasons to display its ads to site viewers from the US. Geotargeting involves looking up the estimated geographical location of the site viewer in a large lookup table where the location assigned to groups of IP addresses is available.
The outcome is a country code, and only if the country code is CA the ad will be displayed.
While this is an extremely quick process, it does take a little time and some resources to do so. And this adds up if the ad server is serving many ads to many visitors simultaneously. In order to reduce the computing overhead of such lookups, the ad server can store the country code it found, in a cookie on the user’s device.
In the setup we described earlier, where the website is on one domain, and the ad server is on another domain, that cookie containing the country code is technically a third party cookie.
If geotargeting is used again later, perhaps for another advertiser, the visitor’s country code is already available in that cookie, so it won’t have to be looked up again. This saves the ad server some valuable time, which in turn improves the overall experience for the site viewer as well. Everybody wins!
Why is third-party cookie blocking a problem?
Once browsers start blocking the creation of these third party cookies, Revive Adserver won’t be able to store the country code it found for a particular visitor, and so it will need to perform the very same lookup of the IP address for every single interaction of that IP address with the ad server.
The outcome is still the same, the ads can and will be targeted to people from the intended geographical locations. It’s just a less efficient process, increasing the costs of operating the ad server, and reducing the speed of rendering the ads on the site. Nobody wins anything, and in fact everybody loses something.
Final thoughts
This is just one example of how Revive Adserver uses third party cookies in a way that’s both entirely harmless and perfectly useful.
There are other, similar use cases where bits of information are stored in cookies in order to make the ad server work more efficiently and faster for the site visitor.
In the next article in this series, we’ll dive into the question of why some people are concerned about third party cookies, sparking the movement to get rid of them. We’ll also highlight how some companies are making good use of these concerns for their own benefit.
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.
