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.
1. Understand the PII you collect
The first step to building a GDPR-compliant ad platform is understanding the personally identifiable information (PII) you collect and how it’s used.
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:
- IP addresses
- User Agent strings
- Location data like lat/long and physical addresses
- Social Security numbers
- Email addresses
- Cookie IDs
- Biometric, financial, behavior, demographic data
- Mobile IDs (IDFA, AAID, etc.)
Even hashes of this data are considered PII because you can link them to an individual, so there are no workarounds for these concerns - and any fines can be as high as 20M Euros or 4% of your yearly revenue, whichever is higher.
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:
- Send full IP addresses downstream; they must be truncated
- Pass geolocation data like latitude/longitude to partners
- Store PII in internal logs, as it might be accessible and viewable to others
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.
2. Collect consent and honor the data rights
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.
Honoring user consent goes well beyond getting the initial “yes”, though. Since cookies can be deleted, you’ll need a persistent way to store who has or hasn’t consented (or you could re-prompt them each time, but that could lead to a poor user experience).
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.
3. Revisit data retention and storage
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.
One of the biggest mistakes we see companies make is storing PII in their logs. Per the data rights under the GDPR, a user can revoke consent at any time. This becomes more difficult if PII is stored in many places, including raw log files that may be hard or impossible to make changes to.
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.
Adzerk'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.
4. Identify users’ locations in real-time
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. Adzerk allows customers to implement GDPR-compliant features for both EU and global users.
5. Have a risk assessment plan in place
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.
6. Update your legal documents
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.
Finally, your ad server will also require Data Processing Agreements (DPAs) for each of your third-party vendors, as they too must prove GDPR compliance.
You’ll need a separate DPA for every service to which you transfer your users’ data, including:
- Third-party cloud hosting
- Log hosting
- Backup services
If you’d prefer to have just one DPA, Adzerk can help you build your platform and manage these agreements for you!
Ready to build a GDPR-compliant platform?
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. We’ll continue to follow the GDPR and share updates with the Ad.Product community as well.
Please click the link below to share your experiences with planning and building a GDPR-friendly ad server!
Join the Ad.Product community
Sign up for our monthly newsletter and to be notified of member-exclusive events and opportunities.
Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.