Consent Management Platforms: an FAQ for GDPR, CCPA & PubGuru DataGuard

This post was most recently updated on January 20th, 2020

(Updated for January 1st, 2020)

What are the GDPR and CCPA and how do they apply to the publishing and advertising industries?

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.

What do the GDPR and CCPA require at a minimum?

Publishers and advertising technology companies must obtain affirmative and express consent to use cookies and other personalized identifiers in advertising and website user analytics for users located in the EU/EEA. Failure to do so allows for catastrophic fines under GDPR.

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.

What if our company has no presence in the EU/EEA or California?  We don’t think the GDPR or CCPA apply to us.

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.

Are there any advertising solutions available that do not require user consent?

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:

• Targeting becomes wildly ineffective when the user cannot be tracked. Advertisers cannot target audiences by demography — for example, ads focused on products for females aged 18-35 end up as wasted impressions in front of other demographics.  Also, retargeting campaigns for users who have expressed interest in a product or service also becomes ineffective.
• Additionally, modern anti-fraud technologies rely on both cookies and browser fingerprinting that are not permitted under the regulations without consent. Brands don’t want to buy impressions where they cannot validate whether those impressions were even real.
• Between these issues, when advertisers cannot verify that their ads were in-market, and cannot even verify that the ads appeared in front of real humans, very few are interested in buying such ad inventory. With little demand for such ad inventory, ad rates collapse.

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.

What is a Consent Management Platform (CMP) and how does it solve this problem?

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.

Can we use Google’s non-personalized ads (NPA) instead of a CMP for GDPR?

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.

As a publisher, do I need a privacy policy?

Yes, all publishers must have a privacy policy. This is required by laws of numerous countries in addition to those of the EU/EEA. The privacy policy should include:

• what the publisher uses data for (usually user logins, user experience customization, personalized advertising, etc),
• contact info at the publisher for how to have a user’s data removed.
• a link to the user facing PubGuru Dataguard unified vendor list.
• for CCPA, the policy must include a link with the text “Do Not Sell My Info.”

Talk to your counsel for meeting compliance requirements with your privacy policy.

How does PubGuru DataGuard work?

PubGuru DataGuard is our directly integrated CMP.  With PubGuru DataGuard, all users are checked for being in EU/EEA countries and California.

• Users who are not in EU/EEA countries or California will not get any consent popup.  For example, a Spanish speaking user with a Spanish browser language set who is located in Latin America will not get the consent popup.  The only exception to this is when a user has an ambiguous location from browser heuristics and they cannot be geolocated by IP.  There’s no choice but to give them the consent popup, but this is extremely rare.
• Users who are in EU/EEA countries will get an active consent popup. Our popup discloses that the user’s data will be used for customizing advertising based on their interests. Digital advertising today has countless industry players, and a publisher cannot know which vendors will load before they are loaded. We list out all known major advertising partners who we’ve observed in the advertising ecosystem, including Google (for Adsense, AdX, DFP, and Analytics), MonetizeMore, header bidders, DSPs, and anti-fraud verification companies. Because advertising partners vary from pageview to pageview, or also if the publisher adds additional partners, we disclose all partners who could potentially load, rather than only the partners who definitively will load. This also means the publisher need not seek consent over and over again on different pageviews for the various partners who load.
• Users who are in California will get a smaller passive popup with the proper privacy policy links and necessary disclosures.

You can see a working PubGuru DataGuard Demo here.

What happens if the user does not consent?

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.

Where and how does DataGuard store consent data?

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.

How does DataGuard pass the consent information to all other advertisers downstream?

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.

Does PubGuru DataGuard implement the IAB Consent Framework?

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.

DataGuard doesn’t allow users to globally opt out or modify privacy settings.  Why not?

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.

We already have our own consent popup.  What’s wrong with that?

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:

• Check whether the user is EU/EEA or California first, or alternatively give the popup to all users.  Using slow IP based geolocation for all users is a significant loss on traffic outside the EU/EEA and California.
• Disclose all vendors in the ad and analytics stacks who may load because simply listing header bidding partners is insufficient.  This should include the entirety of both the IAB GVL and Google’s vendor list, as well as any additional vendors that might be unique to the publisher.
• Have proper popup language that includes all features and purposes listed in the IAB GVL and Google’s privacy statement.
• Have proper popup language that includes opt-out opportunities for the sale of user data.
• For GDPR, until the publisher has either determined the user is not EU/EEA, or the user consents, the publisher CANNOT run any cookie or tracking code, including header bidding, GAM, or GA, without risking liability or account loss.
• Track all instances of consent in GDPR and CCPA compliant data storage.
• Implement the IAB CMP framework API. This is not a single unified repository of consent; rather, it is a standardized set of public functions exposed to ad ecosystem partners that others downstream can use to check if consent has been obtained on their behalf. If the publisher does not support the IAB CMP framework when these vendors start requiring compliance, the vendor will not run their code on request, and it will be subject to discrepancies or clawbacks.
• Discuss compliance with regulatory counsel to include the specific elements of language that may be specific to the publisher. For example, sites that use languages other than English should have popups in those languages. Publishers running their own analytics and tracking (as opposed to Google Analytics, Comscore, or Quantcast) also need to update those deployments.  We are not your lawyers or insurers.  You are responsible for complying with all applicable laws.
• Finally, popup developers should run performance and conversion testing on popups using a GDPR compliant analytics tool.  Some popups have significantly higher conversion rates than others.  Some popup designs have such poor designs that others are multiple times more effective.  If the publisher is using a poor design, that can result in a 70-90% loss in EU/EEA revenue.  Running these tests also requires developing GDPR compliant psuedononymous storage — you can’t just use Google Analytics or most other analytics packages.  We know of multiple CMPs that are confirmed to not do popup testing, and we are not aware of any others besides PubGuru that do any popup testing.  We’ve tested multiple.

In short, your popup must meet numerous requirements that most publishers simply aren’t interested in implementing.

Can I just not run a CMP?

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:

• Publishers cannot use any master advertising accounts from PubGuru.  We are not an insurer, and not set up to take the liability for publishers that do not want to comply with the law.
• Publishers will not have access to PubGuru TrafficCop on EU/EEA or California traffic as the tool collects personalized data on users.
• Publishers not running an IAB compliant CMP face increased discrepancies and clawbacks, even on traffic from outside the EU/EEA and California.  This is because vendors downstream are now checking for the IAB functions implemented by the publisher’s CMP.  If the IAB functions are not available or do not return a valid consent ID (even on traffic outside the EU/EEA and California), the vendors increasingly are not loading their ad code, and labeling it as invalid traffic.  These vendors do not want the catastrophic liability either.
• Because all the largest ad tech vendors, including Google, Facebook, and Amazon, all have presence in both California and EU/EEA, publishers face permanent account suspension and termination from those vendors.  Google has already sent out violation warnings to many publishers.

In short, not running a CMP is not a viable option for advertising supported publishers.

I’ve seen other publishers running passive consent bars at the top or bottom of the screen.  Why can’t I just run something like that?

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.

We get little or no traffic from EU/EEA and California.  Should we still run a CMP?

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.

Can I run another CMP with PubGuru or MonetizeMore technology?

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.

Okay, we need a CMP.  How much does PubGuru DataGuard cost?

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.

Does PubGuru DataGuard have any advertising revenue impact for users located outside the EU/EEA and California?

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.

How long does a user’s consent token last?

By default, our consent cookie lasts 390 days, as advised by the IAB and numerous other major advertising and publishing industry companies.

What about users under the age of 16?

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.

How do I verify PubGuru DataGuard is working?

To force simulations, append the following GET params to the URL of your test page:

• append ?pg_gdpr=popup to the URL to force the active GDPR popup to show
• append ?pg_ccpa=passive to the URL to force the passive CCPA popup to show
• append ?pg_gdpr=reset-cookies to the URL to reset cookies

How do I customize the logo shown in PubGuru DataGuard?

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.

What code do I need to run Google Tag Manager or Google Analytics with PubGuru DataGuard?

Our adops will set your GTM and GA IDs in the publisher console for each one of your domains.

How should a publisher handle IP addresses?

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 123.45.67.890, 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.

By default, we include in the first entry of the consent form the publisher’s domain and business entity as well as a link to the publisher’s privacy policy if available, with a default set of data uses.

Conclusion

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.