Are you looking to build your own ad server? As a publisher, you’ll need to understand GDPR regulations and ensure compliance for your advertisers and European Union (EU) users.
If you’re not familiar with the GDPR and its implications, we recommend reading our GDPR and Ad Tech article, as it covers many of the legal details and terms you’ll need to know.
This article will present six GDPR considerations for your building process, including how to manage personally identifiable information (PII), how to retain and store data, and how to plan for ongoing risk assessments.
Please note: This article is for informational purposes only. Please seek legal counsel to determine how the GDPR affects your business.
The GDPR regulates the handling of personally identifiable information (PII) for all EU residents that use your web applications, mobile apps, and desktop software.
PII is complicated, and you likely collect/store more than you realize. For example, the User Agent string of a web browser can be combined with other data to identify an individual user. Location data for the same user is also considered PII: who else would go from your home address to your work address?
Under the GDPR, PII includes, but is not limited to:
The GDPR prohibits using this data in automated decision making (including ad serving) and unsafe storage and leakage of PII.
So without EU user consent, you cannot:
Below lists some common ways ad servers use PII - and which you should review if you do:
|Use a cookie ID or unique user ID for purpose of profiling and user-level targeting||Yes, if attributable to an individual|
|Use IDs to track impressions, clicks, conversions, or other engagement metrics||Yes|
|Use IDs to regulate ad delivery using frequency capping||Yes, as ad views and time stamps on cookies can be tied to specific users|
|Send IP Address or GPS data to a location lookup tool||Yes, if you are not truncating the IP Address (like zeroing out the last octet)|
|Store user agent string / location data in a database for purpose of ad delivery, targeting, or storage||Yes||Send any PII to a downstream ad partner||Yes. Any transfer of personal data is subject to strict GDPR rules and may require additional legal documentation.|
If you’re fielding programmatic requests, you’ll need to send multiple OpenRTB fields downstream. Be sure to read the IAB spec on GDPR first.
That said, we don’t expect OpenRTB to ultimately be permissible (court rulings will decide this in the coming years), as the GDPR requires you to inform users what vendors will see the data. Even if you collect consent for sending their PII to, say, Rubicon Project’s ad exchange, you would also need to collect consent to share the user’s PII with all the demand side platforms (DSPs), ad networks, and data providers that Rubicon is integrated with.
Given how programmatic advertising works, this is not feasible - and if even one company sees that PII who was not mentioned at time of getting consent, you could be held liable to pay the penalty.
You’ll first need a way to collect consent. There are plenty of IAB-certified third-party consent management platforms. You could also build your own CMP using internal code or open-source code from AppNexus or Axel Springer.
It should be noted that most CMP implementations are not actually compliant under GDPR, so you should work with your legal team to set up the tools in a compliant manner.
Additionally, the GDPR specifies multiple data rights the customer has - including the right to delete their data, the right to see what data you have on them, and the right to rectify it. This means you need a way to store this information tied to a user and easily access/modify it if they request it. (The GDPR does allow you to store PII for the purpose of tracking consent).
Your ad server will also need to reference this database in real time, so you can determine who can or cannot have cookies dropped for each ad request - without slowing down your site.
You will also need to address how you store and back up data.
All old data - personal identifiable information (PII) or otherwise - will need to be flushed regularly. Most data breaches are due to old database backups, log files, and even former employee files.
Also, per the GDPR’s right of access, you must be able to tell a EU user all of the information you have for them - so retrieving all of that data from your logs will prove daunting.
User data will also need to be stored in a way that allows quick retrieval upon request and prompt removal upon requests to be forgotten. As noted previously, we recommend a first-party database.
We recommend transforming your data before logging and storing
For example, transform user agent data into high-level form factor data and geolocation data into lower-resolution forms like city, region, and country. This keeps you from inadvertently stepping on EU users' data rights, including the right to be forgotten and right to access, and it can help you avoid court fees and legal hassles.
Kevel's historic stance on data privacy and security - and the EFF Do Not Track standard - made this easier for our GDPR compliance. You should work with your legal counsel to develop a data retention policy that meets your unique needs.
Obviously you’ll need to identify a user’s location in real-time - likely using IP Address, GPS data, or the country they registered an account with - and as needed run it through a reputable location lookup service or database to identify country.
Your CMP tool should then prompt consent for anybody in the EU. This includes the United Kingdom, as the GDPR will continue to apply to the UK through the Brexit implementation period (scheduled to end December 31, 2020); the UK will likely adopt a similar law starting in 2021. We also recommended including Switzerland, as it has similar data privacy laws.
You may want to play it safe by treating all incoming requests as GDPR-regulated and prompt consent for all users. Kevel allows customers to implement GDPR-compliant features for both EU and global users.
Once your server is built, it must be maintained. GDPR compliance requires continuous risk assessment and a vigilant response to data breaches. Depending on your core processing activities, you may also be required to appoint a Data Protection Officer (DPO).
As a publisher, you’ll need to conduct regular, recurring risk and vulnerability analyses of your ad platform. We recommend both automated and human-powered analyses to ensure accuracy.
You’ll also need a breach notification plan, as you’re required to notify EU users within 72 hours of a breach - and you’re held liable whether or not you were aware of the breach.
You may want to additionally obtain PrivacyShield certification to ensure you meet EU data transfer laws. The PrivacyShield framework was designed by the U.S. Department of Commerce and the European Commission to give companies a mechanism for transferring European data to U.S. companies. This certification is not required by the GDPR but it can demonstrate your due diligence in case of a lawsuit.
There are few steps here.
Two, you’ll want a separate Cookie List page that provides transparency about the cookie names you drop, as well as their lifespan.
You’ll need a separate DPA for every service to which you transfer your users’ data, including:
If you’d prefer to have just one DPA, Kevel can help you build your platform and manage these agreements for you!
As you can see, building a GDPR-compliant ad server is complicated! We hope we’ve taken some of the guesswork out of your planning process.
The GDPR has been enforced since May 2018 and continues to evolve with EU court rulings on its interpretation and implementation. To remain GDPR-compliant, you’ll need to follow the legal proceedings from EU member countries and update your ad technology accordingly.
Larry is a Principal Product Manager who works at Kevel, a suite of APIs that make it easy to build custom ad servers.