Support for Chrome Changes and 3rd Party Cookies

Major changes to Chrome Cookies

Google Chrome has recently changed how cookies can be set and tracked across their browser. Changes were enabled for Chrome version 80 (currently behind a feature flag) and have direct implications across all platforms running on chrome, including Exchange, SSP, etc.

The major changes regarding user tracking are

  • All cookies and ad tags must be secure
  • The correct meta-data setting should be “SameSite=None”

Secure Ad tags

All ad tags must be secure. Ad tags calling from non-secure ad sources will not be able to send the cookies, therefore sellers should change all non-secure ad tags to secure.

Example: Video SSP non-secure ad tag is rendered secure with the addition of an ‘s’ after the http.

https://ads.adaptv.advertising.com/a/h/DfcEVqB9s2yqgaWTWGri83uaW+qZ2JOO2evZM2Q1OOjaZhKk9wDYmlF8JUqjL_RRoOt0lqLFswM=?cb=[CACHE_BREAKER]&gdpr=[GDPR]&gdpr_consent=[GDPR_CONSENT]

 

Example: Marketplace (MP) non-secure ad tag is rendered secure with the addition of an ‘s’ after the http.

<script language="javascript"><!--

document.write('<scr'+'ipt language="javascript1.1"

src="https://adserver.adtech.advertising.com/addyn/3.0/9599.1/5002584/0/0/ADTECH;loc=100;target=_blank;misc='+new Date().getTime()+'"></scri'+'pt>');

//-->

</script>

 

Example: SSP (1M) non-secure API request is rendered secure with the addition of an ‘s’ after the http and adding the request parameter ‘secure=1’.

https://ads.nexage.com/adServe?dcn=dcn_value&pos=position_value&secure=1

 

Example: SSP (1M) non-secure ad tag is rendered secure with the addition of an ‘s’ after the http, changing the script source and adding the secure parameter ,"secure": "1".

<script src="https://ads.nexage.com/js/admax/admax_api_https.js"></script>

<script>

var suid = getSuid();

var admax_vars = {

"dcn": "dcn_value" /* Your publisher ID */

,"pos": "position_value" /* Position name */

,"secure": "1"

};

if (suid) admax_vars["u(id)"]=suid;

admaxAd(admax_vars);

</script>

 

Example: SSP Header Bidding non-secure PI request is rendered secure with the addition of an ‘s’ after the http and the secure request parameter ‘secure=1’.

https://ads.nexage.com/bidRequest?dcn=dcn_value&pos=position_value&cmd=bid&secure=1

 

SameSite Metadata

Chrome has made changes in the way 1st and 3rd party cookies are handled.

From the Chrome website:

“We are making a number of upcoming changes to Chrome to enable these features, starting with modifying how cookies work so that developers need to explicitly specify which cookies are allowed to work across websites — and could be used to track users.”

This will require appropriate changes at SSP and Exchange ends to ensure that the user can be tracked across the web.

Scope

The changes affect both desktop and mobile web users on Chrome and Chrome-based browsers, globally.

Behavior Pre and Post v80

In previous versions of the Chrome browser all cookies were extracted (under advertising.com domain) and sent back to the Exchange regardless of the connection (secure or non-secure) or cookie type.

Post v80 cookies can only be fetched for secure ad requests, which requires simple changes as mentioned above. It includes all ad tag, header bidding and S2S based traffic.

What Needs to be Done?

To continue monetizing without impact, Yahoo requests that publishers secure all ad tags by changing current unsecured ad tags to secure ones (see Secure Ad tags above).

  • Begin this process now, don’t delay. It will take time for Yahoo servers to see and update cookies from all of your users before the February 4, 2019 release date.
  • Publishers who neglect to change non-secure ad tags to secure ad tags will see a measurable decline in revenue due to the inability to match and target users on third-party sites.

If you host your own technology or work with other ad technology vendors, we recommend reaching out to your partners to ensure they are taking the necessary steps.