GDPR: Serving and flagging non-personalized ads to users in the EU using Google DFP

In response to GDPR, EU publishers (or any publisher with EU traffic) will be asking for the user’s consent before utilizing their data to personalize their ad experience through ad targeting starting May 25th 2018. For those publishers using Google’s DoubleClick ad server, Google announced some new API’s to pass user’s consent (whether yes or no) to the ad server.

If you want the full details, you can read Google’s detailed documentation on their Publisher help site titled “Ads personalization settings in Google’s publisher ad tags“.

GPT / googletag

If you’re using Google’s GPT tag, passing the user’s consent is set as follows:

googletag.pubads().setRequestNonPersonalizedAds(1); // 1=Yes, 0=No

To ensure ads aren’t triggered before consent (if that’s your strategy), make sure you’re disabling GPT’s initial load (this may be already set if you run header bidding):


AdSense or Ad Exchange

If you’re using AdSense or Ad Exchange tags, configure the following setting:

(adsbygoogle=window.adsbygoogle||[]).requestNonPersonalizedAds = 1;

To pause ad requests before user’s consent, set the following config:

(adsbygoogle=window.adsbygoogle||[]).pauseAdRequests = 1;

I believe after May 25th, Google will not trigger ads by default if pauseAdRequests isn’t set to 0, so make sure you set pauseAdRequests=0 if you intend to trigger ads by default for your site to run AdSense or Ad Exchange tags.

Fighting against malvertising with truly native ad exchanges

Ad exchanges today rely on so many third party vendors and middle men and that essentially removes a lot of control from underneath them leaving them exposed to vulnerabilities and quality issues. The rise of native ad exchanges, whether it’s for web or mobile apps, is definitely helping in the fight for better ads and against malvertisement (ad popups, mobile redirects, etc) and the way it’s achieving that is by enabling the exchange to fully own the advertiser’s creative.

That being said, it seems it’s hard for the digital advertisement industry to completely move away from the legacy mentality of standard banner advertisement formats that has been tarnishing the modern web for decades.

The internet has changed a lot since the 90s, can we please stop using those historic banner ad formats?

When internet publishers around the globe start taking the user more seriously and begin listening to their frustrations, that’s when they start thinking as a brand and not seeing their products and services from a revenue-first lens. That’s where native advertising shines. Native web advertising is a way that solves the current ad user experience problem, that’s aiding the usage of ad-blockers, as well as helps eliminate “bad ads”.

The native ad exchange simply provides the meta-data around a creative and it’s up to the publisher to present it to the user in a way that adheres to the exchange’s ad policies. Within the meta-data lives the creative assets that includes the title, image, description, video, etc. It’s then up to the publisher to combine that data to a creative template that either they have put together or provided by the exchange as a default template.

The end result is a custom and unique ad experience that fits and flows well with the publisher’s website layout and design.

With that unique experience comes a slew of benefits, but most importantly it achieves the following:

Removes banner blindness

Users have grown custom to the look and feel of the current web’s standard banner ads where they are consciously or subconsciously ignoring them as they navigate and surf the web. With truly native ads, users are offered unique ad experiences that follows the website’s design guidelines that attracts and/or engages the user’s attention.

Eliminates dozens of middle men and third party vendors

A typical web banner ad will load anywhere between 20 to 100+ external files (images, JavaScript, html, etc) usually through several “hops” or redirects within other exchanges, DSPs and advertisers. Most of those assets aren’t thoroughly quality controlled to fit within IAB’s standards and therefore leads to ad latencies, extensive bandwidth usage, and an overall bad user experience. With truly native ads, the exchange is only serving ad creative meta-data in the form of text across the channel and that’s a lot more responsive and efficient for publishers and users.

Today, we see the growth of native web advertising as a promising and positive sign thanks to many exchanges that have adopted the technology and have been promoting it for years such as Facebook, TripleLift, Sharethrough, AppNexus, Criteo, and Google’s Ad Exchange just to name a few.

Is server-to-server (S2S) the universal “header” bidding solution for publishers?

When header bidding was introduced to the web publishing industry, it did truly add so much value that ranges from ad latency to user and bid transparency. It opened up part of the black box in the digital advertising ecosystem that was much appreciated and greatly welcomed by publishers. But what about publishers that don’t just have a web presence but also an app in the Apple Store and/or the Google Play store? Is there an opportunity where publishers can monetize their content across multiple platforms without needing to onboard dozens of ad-tech solutions that are platform specific?

When Server-To-Server (S2S) bidding was introduced to publishers, I got excited for the opportunity that will finally bypass several layers of restrictions and limitations of web browsers when attempting to involve many bidders in the client side auction. Publishers will be able to communicate from a single API call through their web servers to multiple SSPs (supply side platforms) without impacting user experience, page load times and adding a hefty amount of JavaScript to their pages. And in return, the response from that API call includes the highest bids for each ad unit involved. How amazing is that? Unfortunately that setup comes with several caveats.

Low user match rate

By moving SSPs from client-side to server side, they won’t be able to gain access to their cookies and other data that further identifies the user or their interests in their systems. Without that user-matching cookie SSPs and advertisers will have less data to go by when bidding and thus lead to an inefficient bid due to insufficient data. Whether the ad call is being made from the web or a mobile app, the user match rates will always be lower than with client-side bidding until the internet comes around and potentially offers a universal user identification platform without actually identifying the user.

SSP JavaScript Libraries

To solve the low user match rate mentioned above, SSPs are asking for their JS library to be added to the page as a way to augment their S2S offering in an effort to improve user matching. This hybrid solution isn’t aiding the goals behind moving SSPs from client-side to server-side. Publishers will still bear the responsibility of loading JavaScript libraries for each SSP on top of the S2S connection needed to trigger the auction.

What about the ad server? Is it S2S too?

For publishers using DFP, the S2S solution isn’t including the DFP call in that environment. The DFP call is still made on the client-side after the S2S call responds back with the highest bids for each ad unit. This might not be the case for mobile apps, but it’s definitely the case for web publisher using ad server that doesn’t offer server-to-server ad serving capabilities.

Tech ownership and scalability

For publishers willing to migrate from client-side to server-side bidding, they have a few options today. One option is to use the free Prebid Server but the free offering goes through AppNexus’ servers which removes a lot of control and ownership from the publisher. Other SSPs offer S2S services similar to their header bid wrapper services, but you’re still losing a lot of control and ownership over the tech (which perhaps for many publishers isn’t a deal breaker). For publishers to truly own their S2S solution, they would essentially need to build and host their own ad server that is able to make and receive server-side API calls to all the desired SSPs. This is a challenging task since you’re essentially building your own global real-time bidding server which comes with scalability, availability, performance and other challenges which took SSPs years (if not decades) to perfect.

For many publishers today, knowing the restrictions and limitations mentioned above, they decided to run S2S in a hybrid environment: client-side header bidding that includes their highest performing bidders plus server-side bidding for the remaining participants. This is probably an interim solution until the issues above are widely resolved, especially regarding the user-cookie mismatch and tech owenrship.

Did the digital advertising industry ever think about asking the user for data in return for a reward?

With all the current news and concerns around user data privacy there is no doubt that ad-tech companies around the world are only adding more problems to the matter and not effectively tackling the issue at hand.

The methods and strategies that are used today to tackle ad-tech from a user targeting perspective likely started by mainly appeasing to the advertisers’ plethora of specifications and requirements, which eventually leaves the users in a dust storm of ad-tech junk that floods their browsers and consumes their precious mobile bandwidth.

A lot are asking “what are the users gaining from all of that tech if their data is that important to be labelled a ‘gold mine’?” I say they get nothing more than an ad delivery that leads to a bad enough user experience and campaign targeting that further promotes the use of ad blocks.

So much money wasted.

The way I see it where a lot of the discussed issues are resolved (in my opinion at least) is by getting consent from the user (across only his/her browser, device, etc) to provide machine readable data (not human readable) so that it’s encrypted and locked down in a “database” of some sort (blockchain makes sense in this case I suppose). This data will reside alongside the user’s devices, browsers, etc and not escape them. This is different from browser cookies and user web trails as it’s specific user inputted data.

From the advertisers’ side, they will provide their targeting parameters for their campaigns and it will be up to some sort of platform that matches those parameters to the user’s locally stored data. This is perhaps a very high level explanation/concept and would most likely be more complex, but the main idea is to keep the consented user data with the user.

Publishers can start promoting this platform first to ad-block users by telling them that they aren’t just supporting the site by white-listing them, but they’ll also get rewarded.

Why would the user supply data to feed this process? Mainly due to the fact that they will get rewarded and as a result their ad experience will greatly improve.  I personally think those users with ad blockers are the main audience to entice first as they are more likely to understand the pros/cons of such a technical problem. I mean, those users went above and beyond to block ads in the first place. If they know they will get rewarded and have a better ad experience, why wouldn’t they consent?

That platform would most likely require a whole new pipeline between buyer, seller and user but will dramatically improve the cost and efficiency of ad delivery and greatly reduce ad fatigue, fraud, ad blockers, and the hundreds of third-party ad-tech vendors that keep taking a cut out of the advertiser’s budget resulting in much higher eCPMs for publishers.

The key here is to get the user to supply their data and for them to know it’s stored and secured locally where it will be only used to match against existing advertiser campaigns and for that they get rewarded. There are some initiatives or discussions today around rewarding users for viewing ads, but that’s still not solving the user data targeting mess. It’s still placing the advertisers before the users to improve their campaign’s viewability.

Consumers all over the world are already used to such methods, especially with their credit cards that offer rewards in a form of either points or cash. They are already used to it and understand the value returned to them even though they are essentially giving up their purchasing trails and insights to some vendor.

Internet users have changed and they are more adaptable than ever. I totally see a future where users will be selecting their favorite brands, hobbies, sports, and more into a platform that is vendor, browser and device agnostic to improve their browsing experience and get rewarded outside the walled gardens of Facebook and Google. Could this platform become an open source initiative that gets native Windows, MacOS, iOS, and Android compatibility?

One device to power them all

I’m sure I’m not the only one thinking about this being the real solution for the multiple devices nightmare that many of us are facing nowadays. You have a smartphone, a tablet, a personal laptop, and possibly a work PC. We are basically juggling devices. Each device needs to be maintained and kept up to date and they all come with their list if headaches.

But what is the only device that is always with you at all times?

Your smartphone.

It is the answer to all of that. Today, they are powered by powerful quad core CPUs, has oodles of RAM and enough disk space to accommodate your cloud storage for personal and work related files. So why can’t your smartphone be the power house? The device that powers them all?

Simply put, I believe eventually everyone will have a single “host” device (your smartphone), that will do the job of your tablet, your laptop, your office computer and your car’s
infotainment system. Those will be nothing more of cheap dumb terminals or hubs that your smartphone will either wirelessly communicate or dock with to transfer power and data. Of course by then, some of those devices may not even exist.

One device.