Download edition

Revive Adserver and personal data

In order to help you, a Data Controller and/or Data Processor, in the process of becoming and staying compliant with GDPR, here is some information that we think is relevant when it comes to how the Revive Adserver software deals with Personal Data. To do that, we’ll attempt to describe in full which kinds of personal data are being handled by the software. It is likely that we will update this article in the future, to add additional information based on notes and questions from community members about the subject. An important note about plugins or modifications: If you have installed third-party plugins in your Revive Adserver installation, or if you have made modifications to the software, it might be wise to check with their vendor(s) and/or developers to find out more about how such plugins and modifications treat personal data. This article only deals with how the core Revive Adserver software deals with personal data. This article has been organized in the following sections:

  • Users
  • Advertisers and Publishers
  • Visitors
    • IP addresses
    • Geolocation
  • Cookies

Update 1: On May 28, 2018, this article has been updated to reflect two new settings what were introduced with the release of Revive Adserver v4.1.4 a few days earlier, affecting the OAID cookie and the anonymisation of IP addresses. See the respective sections below and the release notes for version 4.1.4 elsewhere. Update 2: On May 30, 2018, this article has been updated with some additional details about the various cookies that are created and maintained by the Revive Adserver software. This was based on feedback we received from community members, for example with replies to the Tweet we sent announcing the blog post that originally accompanied the publication of this page. Update 3: on November 5, 2018, this article was updated with information about some additional cookies that are created and maintained by the Revive Adserver software. This was based on feedback we received from community members. While we believe that the list of cookies on this page is now complete, it is entirely possible we missed something. Please share any feedback you have on this cookies list via the usual channels (ideally the community forums).

Users

Using the Revive Adserver software to create and manage advertising campaigns and to review the statistics of such campaigns, requires a username. For each username, a number of data points are used by the software, which could be considered personal data:

  • Username: the identifier for the individual user, used to log in on the software;
  • Password: the user’s password for logging in on the software, is stored in an encrypted form;
  • Contact name: the name of the user (may or may not be the actual name of the individual, could also be an alias or nickname);
  • Email address: the email address of the user, used primarily for sending password reset emails upon request.

For the protection of personal data, but also more generally speaking for application security, organisations operating their own Revive Adserver implementation are advised to enforce a secure password policy, for example by recommending to end users to change their passwords at regular intervals and not using the same password as used elsewhere. While a user is logged in on the software, the software maintains a ‘session’ on their behalf. The ID of that session is stored in a session cookie on the user’s own device, and is referenced in a table in the database created by the software. When the user logs out, the session ID in the database table is destroyed and the corresponding cookie in their device is removed. If the user remains inactive for a period of over 30 minutes, the session will become invalid and its stored data eventually deleted during garbage collection. When the users closes their browser without first logging out, the session cookie is deleted and thus the session ends resulting in the user also being logged out. Even though GDPR, according to some, considers a session ID to be personal data, it is a completely randomized and in itself meaningless bit of data, with just a temporary usefulness. The data stored in a session contains a reference to the user itself and no extra personal data, just temporary usage preferences. GDPR stipulates that an organisation needs to disclose the use of personal data to the data subjects involved. An organisation using Revive Adserver software thus needs to disclose to its Users:

  • Who is managing their data: the name of the organisation and the name of the person who is ultimately responsible for it;
  • What the intended use of the data is: enabling individuals to log in on the software, to stay logged in without having to enter their password at every single action, and to reset their password when needed;
  • How long the data will be stored and how the data will be protected;
  • What their rights are in relation to their personal data and who else (if any) will get their data.

Since it is most likely that Revive Adserver is one of many software applications that a user has access to when working for an organisation, it is probably better to create a single disclosure to the users about all of the organisation’s software and the Personal data usage for the organisation’s software portfolio. This disclosure can then also contain a description about how the user can exercise their rights with regard to their personal data (for example the rights to review what data is processed, to rectify any errors in it, the right to object to processing, and so on). GDPR stipulates that a Data Subject should be enabled to give consent to the Data Processing Organisation before Personal Data can be processed. However, since in this particular context the Data Subject is a user of the software and most likely an employee or associate of the organisation, such consent is probably already considered lawful processing as part of the performance of a contract (for example the Employment Agreement).

Advertisers and Publishers

When an advertiser or publisher is created in the software, there are fields for the name and e-mail address of the relevant contact. If you decide to enter the real name and e-mail address of an individual representing the advertiser or publisher, this almost certainly is personal data which is governed by GDPR. This means you will have to inform the individual in advance that you are planning to process their personal data, you will have to get their consent, and so on. It could be argued, however, that there is legitimate interest for processing such personal data, since it is necessary to conduct the business relationship with the advertiser or publisher. Alternatively, as a way around having to comply with all the requirements for processing personal data, you can decide to enter the name of the business (and not a person) and a non-personal e-mail address ([email protected]). That way, no personal data is involved, and GDPR likely does not apply. In addition to the basic details about an advertiser or publisher, it is also possible to define one or more users who will be able to login on the Revive Adserver installation and review statistics (and some other functionality). The data being processed for such users is identical to the generic users described above. Keep in mind that these users are much more likely to be external to your own organisation, which means that the processing of their data is not covered by your own organisations Employment Agreement). On the other hand, since these usernames are being used to conduct a business relationship with (an individual working at) another organisation, it could be argued that a legitimate interest exists for processing personal data of this kind.

Visitors

The most common use case for Revive Adserver is displaying advertisements on websites, in apps or in video content. The individuals accessing such websites or other types of content are usually referred to as Visitors (so that we can more easily distinguish them in this text from the Users that were addressed above). The Revive Adserver software processes very little personal data about Visitors. We’ll attempt to give an overview of what is being processed and why, so that Visitors can be informed and be asked to give consent, if you think this is necessary. Below, we will distinguish between data being processed on the server on which the Revive Adserver software is installed and data being processed (i.e. stored) in cookies on the visitor’s own device.

IP Address

The IP address of the Visitor is considered to be part of their Personal data, according to most interpretations of GDPR. The Revive Adserver software does not store the IP address of a Visitor (with one exception, see below) over the course of the delivery of an advertisement. Note: With the release of version 4.1.4 on May 25, 2018, the Revive Adserver software has a new setting, enabling the anonymisation of IP addresses before they are being processed for geotargeting and conversion tracking. See the release notes for version 4.1.4 for more information on how to use this new setting and what the effect is. Note: The Revive Adserver software, by definition, runs on top of some sort of web server software like Apache or Nginx. It is possible that the web server has a logging feature enabled which does store the IP address while logging each interaction it has with a visitor. If that is the case, we recommend discussing this with the system administrator of the web server software or their vendor. As far as Revive Adserver software is concerned, logging in the web server software is not a necessity and might as well be disabled to save precious server resources such as processor or disk space.

Geotargeting

With each ad request, the Revive Adserver does receive the IP address of the Visitor, to facilitate the functionality of geotargeting. Geotargeting as a feature is not enabled by default after the installation of the Revive Adserver software is completed, since it is often not required. If you do not use Geotargeting (meaning that you haven’t specifically enabled the feature), then this section does not apply. If geotargeting is enabled, the software will use the IP address to lookup an approximation of the geographic location of the visitor. The geotargeting functionality in Revive Adserver is not extremely precise. It can attempt to establish in which country a visitor is located, and sometimes even in which city. The geographic location thus established is used to decide if specific ads should or should not be displayed. For example, a banner could be created with a delivery rule that says “only display this banner when country equals Spain”. If the user does not appear to be in Spain, the delivery mechanism in Revive Adserver will not include this banner in the set of ads it is considering for delivery. The Geotargeting feature uses data files produced by a third party, a company called MaxMind. They have developed lookup tables in which the geographic location of many IP addresses can be found. Upon completing the process of ad selection involving geotargeting the IP address and the location of the visitor are not stored anywhere on the server on which you installed by Revive Adserver by default. The location, once establish, is stored in a session cookie on the visitor’s device, however, as explained in the next paragraph. Establishing geolocation is a resource intensive process for servers. Since it is not very likely that a visitor will be in one location first and then in another location a few seconds later, the location that is established during the first interaction between the visitor and the ad server will be stored in a session cookie on the device of the visitor (if that device is set to accept cookies, that is). At the time of the next interaction with the ad server, if the session is still ongoing, the location established in the previous interaction is thus automatically included, which means it doesn’t have to be looked up again. This reduces the time needed to process subsequent ad requests, and thus improves the visitor’s experience while also reducing the load on the server. The Visitor can of course delete that cookie at any point in time. The cookie will be deleted at the end of the session (i.e. when the Visitor closes their browser). The accuracy of the geotargeting feature inside Revive Adserver can greatly vary based on the type of data file in use (e.g. free, paid, country vs city, etc.) and the actual location of the Visitor itself. If you plan to use geotargeting, or already do so, you should consider, possibly with the help of a lawyer, if the level of detail of the location being established could be seen as personal data.

Conversions

In ad serving, a conversion is usually defined as a situation where a visitor of a site has interacted with an advertisement (for example seeing the ad or clicking it) and subsequently following through with some sort of action like signing up for a service, purchasing a product, or requesting a quote. During or at the end of the conversion, the fact that a conversion occurred can be recorded. This is called Conversion Tracking, and it is a feature of the Revive Adserver software (just like with most other ad servers). Generally speaking, this is done to be able to evaluate the results of an advertising campaign (“how many widgets were sold as a result of the campaign?”) or to compare between campaigns (“was the campaign with the animated banners more effective than the campaign with regular banners?”). If you do not employ conversion tracking, then this section doesn’t apply. The actual conversion generally takes place on the website or some other online environment operated by another organisation. It will almost certainly involve personal data (for example the name and address of the person who bought a product so it can be shipped to them). The other organisation needs to comply with GDPR to do that, but the organisation operating the ad server need not be involved. It might be wise to ask the other organisation if they’ve taken care of GDPR compliance, just in case. When recording the conversion, the Revive Adserver stores the IP address of the visitor who just converted. The reason is that this enables the process of deduplication. Sometimes, and almost always by accident, an individual does something like re-opening or refreshing an order confirmation, which could be interpreted as a second conversion. Deduplication can be used to automatically discard duplicate conversions that happened within a given time frame. Optionally, it is possible to record additional details about a conversion, for example the total value of the transaction (almost certainly not personal data) or the customer ID of the individual who just converted (which is definitely personal data). There is obviously a shared responsibility between the organisation operating the website where the conversion takes place and the organisation operating the ad server. First of all, one could discuss if there is actually any need to process such personal data if all that is needed is to count the number of conversions. Second of all, if it is decided that personal data is processed as part of conversion tracking, the responsibility for informing the individual and getting their consent to do so is the responsibility of the webshop, as they are the Data Controller in this particular use case. Lastly, it is the responsibility of the organisation operating the ad server to make sure that the Data Controller has consent from the individual, since they are the Data Processor.

Cookies

The Revive Adserver software uses cookies to work correctly. Here is a list of the cookies we are aware of:

  • For Users:
    • Session ID
  • For Visitors:
    • OAID: unique random identifier (permanent, expires 1 year after last update; when enabled) (see notes below)
    • OAGEO: used to cache geolocation (session, deleted when closing the browser)
    • OASCCAP, OASCAP, OACAP: used for frequency capping of campaigns, banners (session or permanent, depending on usage)
    • OASZCAP, OAZCAP: used for frequency capping for zones (session or permanent, depending on usage)
    • OACBLOCK, OABLOCK: used for blocking delivery of the same campaign, banner, on the same page (permanent, expires after 30 days)
    • OXLIA: used to store the timestamp of the last view of a banner, used for conversion tracking (permanent, expires after 1 year)
    • OXLCA: used to store the timestamp of the last click on a banner, used for conversion tracking (permanent, expires after 1 year)

It should be noted that none of these cookies are actually used to store personal data (with the possible exception of OAID and OAGEO). Most of these cookies just contain timestamps or counts. This is an attempt at a comprehensive list of all cookies, in order to help the reader determine what needs to be included in a cookie declaration.

Notes about the OAID cookie:

  • Starting with version 4.1.4, released on May 25, 2018, it is possible to disable the creation of a unique viewer ID value for each visitor, and replace it with a dummy, meaningless value that’s identical for every visitor, making it no longer a tracking cookie. It was determined that the Revive Adserver software doesn’t actually use the value in the OAID cookie in the core ad server system, but there may be third party plugins that rely on it. We recommend checking with the developer of plugins you have added after the installation. See the release notes for version 4.1.4 for more information on how to use this new setting and what the effect is.
  • If you feel that the name ‘OAID’ for this cookie introduces a risk for it to be misinterpreted, please consider reading the article about changing the name of the OAID cookie.

Continue reading about Privacy, GDRP and personal data.