This post was most recently updated on January 20th, 2020
(Updated for January 1st, 2020)
The GDPR and CCPA are privacy laws enacted in the last few years that massively affect the advertising and publishing industries.
The GDPR requires data processors to meet certain requirements in handling user data, including requesting affirmative, unambiguous consent for anything not expressly permitted in the regulations. Modern advertising and web analytics are not expressly permitted by the regulations, so consent must be obtained from users before using such technology. GDPR went into effect on May 25, 2018. The GDPR applies to users from both the EU (European Union) as well as the EEA (European Economic Area).
The CCPA is a very similar privacy law that went into effect on January 1, 2020 covering both California users as well as data processors with a presence in California. Although there are differences between the CCPA and GDPR, most of the general idea is the same. There are numerous disclosure and data handling requirements.
In both cases, the advertising industry has huddled largely around the IAB consent framework to provide standardized functions for vendors to see if consent has been obtained on their behalf.
Not sure how to navigate user consent and be compliant with GDPR? We can help you set up our CMP and ensure your website is gathering user consent properly. Sign up to MonetizeMore and find out how our ad engineers can help.
The CCPA doesn’t have the same weighty restrictions on affirmative and express consent, but does require that data processors provide numerous disclosures, as well as a link to block the sale of a user’s personal information.
Publishers outside the EU/EEA and California usually don’t expose themselves to enforceable judgments inside those jurisdictions, but advertising partners who do have a legal presence in the EU/EEA and California (Google, AppNexus, Index, OpenX, etc) will still be liable. As a result, all major demand sources require compliance with GDPR and CCPA via contract.
At a minimum, failure to comply results in suspensions and bans on advertising accounts, and blacklisting on SSPs and DSPs. At worst, publishers who do not comply also face paying the legal fees for the vendors they have contracts with if those vendors get fined.
In other words, even if you’re outside both California and the EU/EEA, you still need a compliant tool to manage consent and the popup. If you run any technology by Google, Facebook, OpenX, or most other advertising technology vendors, it doesn’t matter whether you’re outside the EU/EEA or California. Both the GDPR and CCPA still apply to you.
Not effectively for GDPR. There are a few vendors who have started to experiment with advertising solutions that do not require user consent. We are considering integrating them into our technology where they would have a meaningful revenue impact. However, user tracking for ad personalization is no longer lawful for EU users without user consent under the GDPR, so users get very limited ads that are very likely to be irrelevant to the user. As a result, revenue is drastically reduced. These consent-free ad technologies have ranged from 70-95% loss of revenue for no-consent advertising.
This happens for multiple reasons:
For CCPA, there are options to restrict data processing with most major demand sources, including Google. However, the burden is on the publisher to cut out those who don’t.
A consent management platform (CMP) is a system that manages a consent popup, collecting and tracking who consented, and for which vendors they consented to allowing data collection. The CMP provides disclosures, as well as an avenue for users to exercise rights under the GDPR like data deletion.
Furthermore, not running an IAB compliant CMP can and does increase discrepancies and clawbacks.
According to Google’s webinar and Q&A on GDPR, the answer is a resounding no. NPA was built long before GDPR and for different reasons. NPA is not GDPR compliant and cannot be used instead of a CMP.
PubGuru DataGuard is our directly integrated CMP. With PubGuru DataGuard, all users are checked for being in EU/EEA countries and California.
You can see a working PubGuru DataGuard Demo here.
For GDPR and users in the EU/EEA, the PubGuru DataGuard consent popup requires consent to continue and roadblocks the user until consent is obtained. Because there are so many entities advertising in the industry and their current technology does not support blindly purchasing impressions without any sort of user tracking, consent is required for virtually all advertisers. Industry consensus supports the idea that receiving ads is a valid “price of access” to the publisher’s web properties. Additionally, most sites simply do not function properly without tracking technologies. And finally, the regulations require consent from the user to even be allowed to store cookies that would suppress the popup on future pageviews, so the regulation ironically forces any popup behavior to fire on every single pageview, effectively nagging users to consent until they do.
For CCPA and users in California, the requirements on consent are significantly lighter. The popup does not roadblock the user or ads and is much less intrusive. The popup only shows up to 5 times in a 24 hour period, can be affirmatively consented to by the user (lasts 390 days), and hides when the user scrolls away from it.
All consent data is stored on replicated storage on Amazon Web Services. Further, once a user has consented, the extent of their consent (vendors, features, purposes) is also stored on their own device for faster consent processing.
There are two models for managing consent.
The first is the assumptive model, used by Google, all vendors participating through Google technologies, and numerous others not using Google. This model is assumptive in that it is presumed by convention that a publisher does not load a downstream technology without having obtained consent on behalf of that technology. Google maintains their own vendor list for this, so that publishers can make sure their CMP includes all Google partners who might load in the ad stack. This is enforced largely through contracts, allowing for account termination at a minimum, and passing massive liability onto the publisher in the worst case.
The second model is the IAB model. The IAB model uses a standardized set of functions that others can call to determine whether consent has been obtained on their behalf. The IAB also includes numerous registered vendors on their global vendor list (the GVL), as well as those vendors features and purposes for data processing and collection.
Yes. The problem we found in talking to publishers was that implementing the framework at the publisher level is too complicated for far too many publishers. Every publisher wants a much simpler tool that manages the entire geolocation, consent management, and popup process, automatically firing ads and analytics when consent is obtained or not required.
The GDPR does not require this. The GDPR only requires that individuals have the right and ability to revoke consent, not the ability to do it for any or all vendors en masse. Any CMP claiming that they do this is either exaggerating or being misinterpreted. This is because there is no standardized mechanism or protocol that allows a user to reach out from a single interface to all vendors previously consented, and mass revoke or modify that consent.
The same applies to the CCPA. There’s no requirement in the law for a mass opt-out, and no protocol for such mass opt-out.
At most, a CMP can only delete the active consent token, requiring consent on future data collection and processing, while leaving existing data which has been associated with this user out in the wild. Every major web browser, even on mobile, supports this functionality directly from the browser. The issue with deleting the active consent token is that it’s the identifier bound to a particular user. If the user deletes this token, there’s no way for them to reach out to vendors to revoke consent as they won’t know what their consent identifier was.
Consent is not simply about having a popup or some sort of passive toolbar. Numerous things are happening under the hood. To satisfy all requirements, the publisher’s developers must do at least all of the following:
In short, your popup must meet numerous requirements that most publishers simply aren’t interested in implementing.
Funtionality will be limited, and the risk and liability is catastrophic to your company. You’re risking account bans and severe liability from demand sources and/or regulators in the EU/EEA and California. More specifically:
In short, not running a CMP is not a viable option for advertising supported publishers.
There are multiple sources of confusion around this.
First off, if you’re not testing from EU/EEA, you’re likely seeing the publisher’s privacy popup that is not designed for GDPR compliance and doesn’t load in EU/EEA. This is complicated more by the fact that multiple popup management services are now using heuristics for geolocation rather than just IP address. You can’t just use a VPN for a European IP address. It’s not that simple anymore.
Second, running any sort of personalized ads service (which is virtually all of the market) requires affirmative consent before loading any of that tracking technology in EU/EEA. Publishers who are using passive consent for EU/EEA traffic cannot load such ads prior to consent. If you do load ads before consent, you’re violating the GDPR and risking massive liability, suspensions of your ad accounts, significantly increased discrepancies, and more issues. This means popups for EU/EEA should be very aggressive in obtaining consent, so that you can run ads as close to your normal experience as possible.
Third, passive but conspicuous consent is allowed for CCPA. This means for California traffic, the passive bar at the top or bottom of the screen that allows ads to load before consent is still likely okay. The disclosures must still comply with the CCPA though.
Discrepancy has continued to rise for EU/EEA and California traffic for publishers not running an IAB compliant CMP because the downstream vendors execute the IAB standard consent functions and they don’t exist. When the functions are not found, no consent token is accessible, the vendors do not load any of their tech, and you get a discrepant impression or a clawback.
Yes. You cannot control whether users share your links on social media, or whether users reach you from search engines from EU/EEA countries or California. Any successful publisher will get non-negligible amounts of traffic from the EU/EEA or California.
Even if you’re solely acquiring LATAM traffic through audience acquisition channels that don’t easily allow for sharing links (e.g. SnapChat), upstream vendors can’t see that, and cannot determine ahead of time whether there is consent. They check the functions and when they fail, the vendor doesn’t load.
The IAB CMP spec still provides consent data and the standardized consent functions, even for traffic outside the EU/EEA and California. If you don’t have these functions implemented, you will see increased discrepancy and clawbacks as more and more vendors require them.
Yes, our publishers are welcome to use any CMP that (1) is compliant with the IAB framework and also (2) includes Google’s vendor list. The IAB GVL does not include all vendor’s on Google’s vendor list. PubGuru DataGuard combines the IAB GVL with Google’s vendor list, as well as our internally sourced list.
Additionally, our ad technology works fine with other IAB compliant CMPs. The only limitation is that implementation is more complicated. Increasingly, more and more parts of our technology will not load properly or at all if a valid IAB consent token is not accessible.
PubGuru DataGuard is completely free and included at no cost for all PubGuru and MonetizeMore publishers. Setup is also a snap as DataGuard is integrated directly with our technology. We realize publishers want to get back to publishing, not worry about data compliance.
We have developed a proprietary algorithm that geolocates users in multiple stages. The first stages identify the incredible majority of users who are outside the EU/EEA and California, as well as most users inside the EU/EEA. This means most users will get no additional latency. The last stage of geolocation is only fired if all others fail, and checks the user’s location via IP address using traditional API methods that may take longer, usually 50-200ms, depending on the user’s internet connection speed. Revenue impact for users outside the EU/EEA and California is zero for most publishers using DataGuard.
By default, our consent cookie lasts 390 days, as advised by the IAB and numerous other major advertising and publishing industry companies.
Our consent form requests the user to confirm they’re above the age of 16 or have consent from a parent or legal guardian. There is no meaningful and reasonably accurate technological way to definitively confirm a user’s age because it’s trivial to use another identity. Even alcohol and pornographic sites are relegated to simply asking the user.
To force simulations, append the following GET params to the URL of your test page:
The logo shown in our PubGuru DataGuard Demo is just a placeholder to show you what can be done. You can and should set your own site logo. Our logo is never shown to end users except in this demo. Other than the consent disclosure for our analytics with the rest of the data vendors, there is no mention of PubGuru in the production popup. PubGuru / MonetizeMore is a B2B company, and we want your brand to continue being top-of-mind with your own users.
Our adops will set your logo URL in the publisher console for each one of your domains. If no logo is set, the space collapses and shows nothing.
Our adops will set your GTM and GA IDs in the publisher console for each one of your domains.
Because users are still hitting the publisher’s webserver, the publisher must make their own data storage GDPR/ePrivacy compliant without consent, or the publisher must add an entry into our popup for the publisher and the publisher’s data uses. Publishers cannot set cookies that track users before consent is acquired. If the publisher is logging user IP addresses, one technique that can be used to mask IP addresses even before obtaining consent is to mask the last octet. For example, if the IP address is 18.104.22.1680, the address would get masked to 123.45.67.x.
We’ve heard from publishers confused about masking or encrypting IP addresses after they talked to some vendors about available technologies to manage this. When a vendor masks IP addresses, they’re only doing it for their own technology. They’re not masking IP addresses for the publisher or other third parties that the user’s browser requests. The only way to do this is through a proxy tunnel which prevents the user from accessing the publisher’s servers directly, and forces traffic through the proxy instead. Most publishers do not want to expose their traffic through a third party like this.
Having trouble understanding GDPR or CCPA? We can help you setup our CMP to ensure your website is complying with GDPR and CCPA and gathering user consent properly. Sign up to MonetizeMore and find out how our ad engineers can help.
Here’s the course that 300+ pubs used to scale their ad revenue.