1. Introduction
2. Background
1. What is the Transparency & Consent Framework?
2. What are purpose specific consents?
3. Selecting vendors
4. Encoding and decoding TCF strings
5. Study methodology
3. Results from automated and large scale tests
1. Tens of thousands of ad requests erroneously claim that the GDPR does not apply to citizens in the EU
2. Advertiser finds millions of their ad impressions were mis-labeled as exempt from GDPR
4. Results from semi-manual tests with partial user consent
1. German user visits wsj.com
2. French user visits lemonde.fr and lexpress.fr
5. Conclusion
1. Caveats & limitations
2. Discussion
3. Take-away points
6. Appendix - Additional results from semi-manual tests with partial user consents

Introduction

For the last several years, cookie and consent banners have bombarded European citizens on seemingly every website. These consent banners present visitors a multitude of options to select from, including lists of hundreds of data brokers and ad tech vendors that have an interest in processing a consumer's personal data. The ad tech industry body IAB Europe has devised a tech framework, called the Transparency Consent Framework (TCF), to store and encode user's specific consent decisions. It is responsible for most of the “consent pop-ups” that appear on the screens of 470 million European’s devices every day.

Adalytics asked a simple question - what happens if a user only provides partial consent? What happens if someone takes the time to actually read all the cookie options, and only consents to basic ads from one ad tech vendor? Or, what happens when a person explicitly disallows personalization and behavioral profiling? Have the hundreds of ad tech companies set up their servers and systems to correctly modulate their behavior when a user says: "I don't consent to this vendor processing my information"?

Previous studies had examined what happens before a user provides consent, or if a user rejects all consent options. This study applied a new methodology: have an EU user apply partial consent (and disallow legitimate interests) to one or two specific ad tech companies, and then monitor what happens after the user has saved their choices. This approach allows one to distinguish between consent configuration errors made by the publisher or consent management platform (CMP), versus configuration errors made by the ad tech vendors who are receiving the user’s consent signals.

Observational studies conducted by several EU citizens from Belgian, German, French, and Italian IP addresses suggest that several ad tech vendors, both large and small, continue to build personalised profiles on EU citizens, even when a consumer has explicitly objected to a vendor processing their data for targeted ads.

Some of the larger companies observed which appear to engage in this practice include:

• Experian
• Amazon
• Google
• Trade Desk
• ID5 Identity Platform
• Nielsen
• Media Math
• Yahoo
• Criteo
• Pubmatic
• Index Exchange

It occurs on major websites including Euronews, The Wall Street Journal, Reuters, Welt, Corriere, Le Monde, and other important websites, though in some sense, these patterns are outside of the publisher’s direct control.

These findings suggest that while the IAB Europe’s TCF framework is intended to give consumers transparency and choice over their data processing, it is in fact not being properly implemented and deployed by many ad tech companies.

One senior advertising agency executive who Adalytics showed these results to was concerned about “a risk and liability we're just not willing to take for ourselves or on behalf of our clients.” 

Background

What is the Transparency & Consent Framework?

The European General Data Protection Regulation (GDPR) prohibits the processing or use of personal data unless one has a “lawful basis”. Where “special category data” that could reveal ethnicity, health, politics, etc., are used, the law requires that explicit consent must be obtained. When relying on consent, it generally has to be purpose specific and informed. An ad tech trade group, the Interactive Advertising Bureau (IAB) Europe, developed the Transparency & Consent Framework (TCF) to help stakeholders manage the complexity of GDPR compliance.

The TCF is a set of standards and software tools that take a user's inputs, such as clicks on a cookie banner, convert them into an encoded string, and transmit that string to servers or APIs that can then modulate their behavior in response to what type of consent a user has provided.

For example, a EU resident can visit the website of reuters.com, wherein they will see the following consent banner from OneTrust appear.

The user can select a number of options - for example, they can decide to allow “basic ads” and “personalised ads”. The user can also choose which ad tech companies they give consent to. For example, the user can give permission to Google and Amazon, but not Yahoo and Linkedin. 

After finalizing their choices, the user clicks “Save,” and the Javascript on the reuters.com website will create a TCF string with the following value: “CPRUXqbPRUXqbAcABBENB5CgAEAAAAAAACiQGMwAgF5gMZAAAAAA.aAAAAAAAAAA”

This string represents the user’s choices. The user can verify the contents of this string by visiting a website such as consentstringdecoder.com or iabtcf.com.

This TCF string is then transmitted to various servers and APIs, such as Google’s ad-serving domain, doubleclick.net, to indicate what the user has given consent to.

What are purpose specific consents?

The IAB Europe and TCF define 10 purpose specific consents (and a related set of legitimate interests):

1. Purpose # 1 - Store and/or access information on a device
2. Purpose # 2 - Select basic ads
3. Purpose # 3 - Create a personalised ads profile
4. Purpose # 4 - Select personalised ads
5. Purpose # 5 - Create a personalised content profile
6. Purpose # 6 - Select personalised content
7. Purpose # 7 - Measure ad performance
8. Purpose # 8 - Measure content performance
9. Purpose # 9 - Apply market research to generate audience insights
10. Purpose # 10 - Develop and improve products

These ten purposes represent “defined purposes for processing of data, including users’ personal data” and for which “the user is given choice, i.e., to consent or to object depending on the Legal Basis for the processing.”

Consent Management Platforms (CMPs), such as Cookiebot, Quantcast, or Iubenda, “must only generate a positive consent Signal on the basis of a clear affirmative action taken by a user that unambiguously signifies that user’s agreement on the basis of appropriate information in accordance with the law.”

The IAB Europe’s documentation on the TCF has several helpful explanations on what each Purpose entails. Purpose #1 is needed to allow a vendor to store cookies on a user’s browser. Purpose #2 allows “Basic Ads” to be shown to a user, but it does not allow a vendor to “create a personalised ads profile”; some ad tech experts refer to these as “contextual ads”, rather than micro-targeted or personalised ads.

Purpose #3 “Create a personalised ads profile” allows an ad tech vendor or data broker to:

• Collect information about a user, including a user's activity, interests, visits to sites or apps, demographic information, or location, to create or edit a user profile for use in personalised advertising.
• Combine this information with other information previously collected, including from across websites and apps, to create or edit a user profile for use in personalised advertising.

Purpose # 4 “Select personalised ads”, allows a vendor to “Select personalised ads based on a user profile or other historical user data”. 

Purpose #7 “Measure ad performance”, allows ad tech vendors to measure ad viewability, clickthroughs, conversions, brand safety, and to determine ad attribution and sales lift. The TCF documentation about Purpose #7 states that, “Data collected and/or processed for ad measurement must not be used to improve individual profile or segment data for other purposes”

Most Consent Management Platforms allow a consumer to pick and choose specific consent purposes. For example, a user can choose to only consent to Purpose #2 “Basic ads”, whilst disallowing personalised ads or creating a personal ads profile about the user.

Selecting vendors

The TCF framework also allows consumers to select which data brokers or ad tech companies process their information. There are approximately 791 vendors who participate in the IAB TCF system, which can be viewed here and here. This list is referred to as the IAB Europe Global Vendor List (GVL)

The vendors include the European affiliates of well-known tech companies such as Google, Amazon, and Yahoo, as well as companies headquartered in Europe, Singapore, Japan, US, Canada, and other locations.

Each ad tech vendor has a specific TCF code. For example, Google is 755, while Sizmek by Amazon is 68.

A consumer can in theory say “I only want Google and Amazon to be able to process my data”, whilst disallowing all other 789 ad tech vendors that participate in the TCF.

Encoding and decoding TCF strings

TCF strings are compressed encoding of a user’s consent inputs. You can go and generate a test consent string by visiting: https://iabtcf.com/#/encode. The same site also allows a user to decode a consent string: https://iabtcf.com/#/decode.

The authors of the 2019 Inria study on the TCF also released a browser extension that allows users to inspect their TCF consent strings on various pages.

Lastly, for developers, there is a TCF CLI tool hosted on Github that allows one to quickly parse TCF strings.

Study methodology

This study used two sets of methodologies:

• Large scale datasets from automated crawls and advertiser campaign data

• Semi-manual tests on individual publisher websites, wherein an EU user only provided consent or legitimate interest for “basic ads”, while entirely disallowing personalised ads

This study set out to determine what happens if a user only provides partial consent - meaning, they only consent to say, basic ads from Google and Amazon, but no personalised ads, no cookies, and no data processing from the other 789 ad tech vendors that participate in the TCF.

In theory, if a user clicks into a CMP modal, and selects the buttons to consent to Purpose #2 “Show basic ads”, and only consents to Google and Amazon from the vendors’ list, the CMP should generate a cookie that stores the TCF string that only represents these consents. Then, when that TCF string is transmitted to various ad tech vendors, they modulate the behavior of their servers and APIs accordingly. 

Here is one “good” example. A EU citizen based in Germany visited a popular news website, and did not provide any purpose specific consents, or give authorization to any of the hundreds of ad tech vendors on the CMP menu. When this user’s Chrome browser sent an HTTPS request to ib.adnxs.com (a domain owned by the US ad tech company AppNexus / Xandr), with instructions to exchange and sync data between AppNexus and the domain becon.krxd.net (owned by Krux, a subsidiary of American firm Salesforce), a specific TCF string was encoded in the gdpr_consent query string parameter.

The AppNexus server received this request, parsed the gdpr_consent string, and correctly understood that the user did not give consent to Purpose #3 “Create a personalised ads profile”, or to either of these two American ad tech vendors. The AppNexus server responded with an HTTP 400 error code, saying that the request “failed due to privacy signals”. 

This is a positive example - it illustrates how an ad tech vendor should ideally respond when they are sent data without the correct TCF consent signals.

In this study, EU citizens operating from German, French, Italian, and Belgian IP addresses visited various websites. These European users provided only partial consent (Purpose #2 “Basic Ads”), whilst avoiding Purpose #3 “Create a personalised ads profile” consent, and only giving consent to a limited subset of ad tech vendors. Without Purpose #3, “no user matching will take place”.

Then, the users monitor the Chrome Developer Tools’ Network and Application tabs to observe what information was being transmitted about the given user. For example, the Network tab was monitored for the presence of user data profiling by means of Cookie Syncing, wherein different domains exchange user identifiers. These network requests were recorded in the HTTP Archive format (HAR) for downstream digital forensics and review.

“ID syncing (sometimes also referred to as cookie syncing) is a common and long-standing process in the digital advertising industry that enables advertisers to link up data from multiple advertising platforms. (In other words, it helps advertisers buy ads in more than one place and on more than one service.)”

‘Some Platform Data (for example, cookie IDs, mobile advertising identifiers, ID5 IDs, and IP addresses) may identify a particular computer or device, and may be considered "personal data" or "personal information" in some jurisdictions, including the European Economic Area (see below on the meaning of "Personal Data" under the EU General Data Protection Regulation) and California. This data allows us to recognize a particular computer or device over time. We call cookie IDs, mobile advertising IDs, ID5 IDs, and other random unique identifiers "Digital Identifiers".’

Results from automated and large scale tests

Tens of thousands of ad requests erroneously claim that the GDPR does not apply to citizens in the EU

Adalytics obtained crawler data from 48,698 different publisher domains, ranging from large international news sites to small community forums and blogs. All crawl data was obtained from an EU IP address, either in Germany or in Finland. In each page visit, the crawler did not trigger any motions, clicks, or interactions; it just passively observed page load behavior.

On these 48,698 page visits, only 35,389 publishers had an HTTPS request that was sent to an ad tech vendor and contained either the ‘gdpr=0’ query string parameter, or the ‘gdpr=1’ query string parameter.

Of these, 28,941 (81.8%) contained at least one HTTPS request sent to an ad tech vendor, wherein the query string macro parameter “gdpr=” was set to “0”. According to the IAB TCF documentation and to Google’s documentation, “1 indicates that GDPR applies and 0 indicates that it does not.” Many ad tech vendors were observed processing the German and Finnish user data when “gdpr=0”, despite the crawler not having clicked on the CMP consent banner. In each of these cases, the ad tech vendor could have validated that the user was in fact in the EU by performing a simple IP address geolocation lookup. However, it appears that many take this “gdpr=0” parameter at face value, without performing any additional server-side checks, prior to sending tracking cookies or performing user data syncs.

Furthermore, many of these sites had default TCF strings configured which loaded prior to user input. Adalytics excluded the situations where a default site TCF configuration gave at least one purpose consent or legitimate interest. The study focused only on situations where the site’s default TCF string gave no permissions; an arguably reasonable default. For example, when the user visits some websites, there is a TCF string set immediately (prior to user input) that disallows all consent vendors and all legitimate interests. This TCF string is updated once the user finalizes their consent inputs on these publisher websites.

The table below shows the top domains which were observed receiving HTTPS requests when a TCF string did not provide any consent or legitimate interest. Some, but not all, of these domains were observed setting cookies or triggering user IDs syncs despite the default TCF string specifically forbidding any tracking.

For example, on laprovinciadilecco.it, the default TCF configuration disallows all purposes and legitimate interests, yet there are still unique user ID cookies being used by gum.criteo.com (owned by French ad tech company Criteo).

Advertiser finds millions of their ad impressions were mis-labeled as exempt from GDPR

To try to validate these results, Adalytics reached out to a programmatic media buyer that was in the process of conducting a mid-size digital advertising campaign. This advertiser was targeting their ads to users across the EU, UK, and Switzerland, and had their ads served a total of 111 million times. The advertiser found that the “gdpr_applies” macro was set to “0” 42.3% of the time, indicating that the ad tech company involved was claiming that the GDPR does not apply to these users.

Yet, when the advertiser checked where their 47 million ads were served by using an IP address geo-location lookup service, it found that the majority were served to users based in Spain, Croatia, Italy, France, and other EU countries. 

If ad tech companies are not checking the integrity of the “gdpr_applies” strings by performing IP address geolocation checks, they may end up misleading their advertiser clients about the relevant regulations that apply to their advertising campaigns.

Adalytics asked the advertiser how they felt about this situation, when they noted that their ad tech vendors had reported “gdpr=0” whilst many of the receiving users were clearly in the EU. The advertiser responded (in writing): 

“I would be worried about my compliance risk as an advertiser. After all, my ads were shown and regulators will think I was in breach of privacy regulations. I had trusted the network to take care of all of this, like other basic things (e.g., verifying ads.txt entries). Their lack of basic diligence puts me in jeopardy. If the exchange is not doing basic checks for something so simple, you'd wonder what else they are not doing well, or at all, to protect advertisers from fraud and other issues.”

Results from semi-manual tests with partial user consent

This section details examples of where users in various EU countries visited specific publisher websites, waited for the consent banners to load, and provided partial consent - only for basic ads, with no personalization allowed. Additional tests and case studies are available in the Appendix section at the end of the article.

German user visits wsj.com

An EU citizen with a German IP address installs Google Chrome on their desktop for the first time. This new instance of Chrome is not logged into any accounts or emails, and has no cookies or local storage.

The user visits a wsj.com article, and is shown a consent banner.

https://www.wsj.com/articles/merck-jj-covid-vaccines-ship-11639161192

Before this user has an opportunity to click on any specific consent icons or buttons, the user’s browser makes dozens of HTTP requests to third party domains, belonging to companies such as Google, Adobe, New Relic, Cxense, and The Trade Desk. 

Many of these HTTP requests contain response headers that set tracking cookies in the user’s browser. For example, an HTTP request made to match.adsrvr.org sets a cookie in the user’s browser called “TDID”; this cookie is set to expire in 365 days. The Trade Desk’s documentation explains that this is a unique identifier generated for a given user, and is designed to allow syncing user data with other ad tech companies. In this specific example, it appears that HTTPS request was designed to execute a user data sync with “Casale”, which is likely the ad tech vendor Index Exchange (which owns “casalemedia.com”). 

The phenomenon of ad tech vendors setting tracking cookies in a user’s browser before the EU citizen has had a chance to give informed consent is not a new discovery. Previous research by privacy tech firm Sourcepoint scanned 266 publisher sites across the U.K., France, and Germany between June and September. It found that on average, dozens of vendors stored cookies before obtaining user consent. Ad security firm Confiant similarly found that hundreds of thousands of ad impressions served to EU users were “tracking in an unauthorized fashion.” More recently, research by Ebiquity and Usercentric’s consent management platform Cookiebot found the vast majority (92.6%) of websites that attract tier one advertiser-spend place at least one tracker on users’ devices, prior to obtaining consent. Célestin Matte, Nataliia Bielova and Cristiana Santos published a seminal study in 2019, that showed (among other things), that 9.9% of the websites they studied “stores a positive consent before the user has made their choice in the banner. The study also found that in 5.3% of the websites they studied “cookie banner stores a positive consent in the browser even though the user has explicitly refused consent.”

For the purpose of this present study, HTTPS request and cookie setting behavior was restricted specifically after a user inputted and saved their consent choices. In other words, HTTP requests such as the one above, wherein the Trade Desk sets a tracking cookie on the user’s browser on wsj.com before the EU consumer has had an opportunity to provide consent, were specifically excluded from this analysis. This was done so that the data would not be “polluted” with ad or tracking requests that may have been erroneously triggered by a mis-configuration on the publisher’s website.

The user clicks the “Manage Settings” button the wsj.com CMP banner, and diligently only consents to one specific purpose: “Select basic ads”. The user does not provide consent for any other activity, including:

• “Store and/or access information on a device”, 

• “Create a personalised ads profile”, 

• or “Create a personalised content profile”

Next, the EU citizen clicks the “Manage settings” button for modifying their “legitimate interests”. 

The user de-selects all “Legitimate Interest” buttons, besides “Select basic ads”

Lastly, the user goes and clicks “View all providers”

The user sees that many firms have been toggled on, giving them consent by default. The user clicks on all the buttons (there are hundreds), to ensure that all toggle buttons have been de-activated to remove vendor-specific consent.

After completing this process, the user finally clicks “Save and close” to complete the full consent process on wsj.com. This results in an HTTPS request being sent to “https://cdn.privacy-mgmt.com/consent/tcfv2/consent/”

We can verify that this HTTP response correctly encodes the user’s preferences. The response contains a boolean attribute “gdprApplies: true”, which makes sense, as this user is on a German IP address. The “euconsent” string also correctly represents the user’s selections. If we copy and paste this string into either iabtcf.com/#/decode or consentstringdecoder.com/parse, we can verify that this particular string (“CPREkhYPREkhYAGABBENB5CgAEAAAEAAAAYgAAAAAAAA”) correctly represents the user’s choices. The user has only provided consent and legitimate interest to TCF Purpose #2 “Show basic ads”, and the user has not provided consent to any of the hundreds of vendors that work with the wsj.com through the TCF protocol.

TCF string “CPREkhYPREkhYAGABBENB5CgAEAAAEAAAAYgAAAAAAAA”, as parsed by https://www.consentstringdecoder.com/

After the user has completed this operation, the user’s browser stores the TCF strings in the browser Local Storage directory. 

When the user then navigates back to the wsj.com home page, the user observes HTTPS network requests that contain this specific TCF consent string. 

The user can observe GET requests being sent to numerous domains, including those owned by Google, data broker Bombora (ml314.com), American ad firm Outbrain, and Amazon.

We also see that American data broker Krux (owned by Salesforce) appears to store a unique identifier in the user’s browser cookie storage. This cookie is referred to as “_kuid_”, and “is the unique identifier of users in Salesforce Audience Studio. It is an abbreviation for Krux User ID.”

This example with wsj.com and a German IP address user shows that several ad tech vendors are sending and receiving data, and storing cookies, without consent or legitimate interest. These patterns are observed even after the user has navigated through several pages on the wsj.com website post-consent selection.

However, it does not indicate that the ad tech vendors are actively ignoring the TCF consent strings. We do not observe in this example any third party tracking cookies being set, when the ad tech vendor was specifically notified of the user’s TCF choices.

French user visits lemonde.fr and lexpress.fr

An EU citizen on a French IP address (“Pierre”) visits lemonde.fr. Pierre does not give consent for any of the cookies or purposes presented in the consent banner. His consent choices are stored as a first-party cookie called “euconsent-v2”, with the value “CPRL13GPRL13GFzABCFRBdCgAAAAAAAAAAAAAAAAAAAA”. Pierre checks iabtcf.com/#/decode, and verifies that this specific TCF string does not provide any consent or legitimate interest to any company in the TCF vendor list. However, despite this choice, Pierre observes HTTPS request being sent to id5-sync.com, which respond by setting a cookie called “id5” for 3 months, and triggering a 302 HTTP redirect to sync data with rtb-csync.smartadserver.com. This specific HTTPS request that was sent to id5-sync.com contains the previously mentioned TCF string in a query string parameter called "gdpr_consent".

The domain id5-sync.com belongs to ID5, a London-based “identity platform for the digital advertising industry”. The “ID5 Universal ID is a shared, neutral identifier that publishers, advertisers, and ad tech platforms can use to recognise users''. ID5’s Privacy Policy states that, “with respect to Collected Data that is personal data, we generally rely on consent obtained for us by the operators of the Digital Properties that use our technology”. ID5’s Privacy Policy states that the vendor uses the TCF as a means to “provide dynamic transparency and choice”, and that ID5 is “registered as a vendor with, support, and encourage our clients to use, the TCF Framework”.

The domain with which id5-sync.com was observed exchanging user IDs with was rtb-csync.smartadserver.com - owned by Smart AdServer, a French advertising technology offering ad serving and programmatic monetization solutions.

Pierre resets his browser, deletes all cookies and local storage, and creates a new Chrome profile. He then navigates to lexpress.fr. He waits for the CMP banner to load, clears his network console to have a fresh slate, and then proceeds to input his consent choices - only basic ads are allowed, only Google Advertising is consented to, and all other vendors, purposes, and legitimate interests are specifically dis-allowed. The resulting TCF string is saved to the the browser’s cookie jar and local storage as “CPRN246PRN246AHABBENB5CgAEAAAEAAAAqIF5wAQF5gXnABAXmAAAAA.aAAACAAAAAAA”.

Pierre then monitors the Network tab in his browser closely. Lexpress.fr appears to use the Javascript of Paris-based ad tech vendor Hubvisor on its pages, and trigger Prebid network calls. The Hubvisor mediated Javascript triggers an HTTPS request to tlx.3lift.com/header/auction, a domain that is owned by American supply side platform TripleLift. The ad request sent to TripleLift also contains the TCF string, in the query string parameter “cpm_cs”. Given that Pierre did not provide consent or legitimate interest to TripleLift, not even for showing basic ads, one might expect that the HTTP request would return an error code or null response.

However, that is not the case. The TripeLift server responds with an ad bid from Paris-based luxury fashion house Balenciaga.

Pierre’s TCF string shows that he only consented to basic ads (and only from Google). He is curious as to whether this ad creative that was served to his browser is indeed a “basic ad”, devoid of any tracking or measurement pixels. He takes a look at the details of the “ad” attribute that was sent in the  HTTPS response. The Balenciaga ad contains tracking and ad viewability or render pixels from TripleLift, Google, Oracle Moat, and The Trade Desk. The pixel sent from The Trade Desk also encodes Pierre’s geo-location, including his longitude, latitude, and even the temperature outside his office at the time.

Despite Pierre not consenting to tracking or measurement pixels, or precise geolocation targeting (only “Basic ads”), he can observe that the ad served by TripleLift triggers measurement HTTPS request to Google owned doubleclick.net, which receives Pierre’s TCF string in the “gdpr_consent” query string parameter. Google’s servers respond to this HTTPS request by triggering a 302 HTTPS redirect.

It is not clear why Pierre was served an ad with tracking, measurement, and viewability pixels from multiple parties, despite only consenting to basic ads exclusively from Google.

Additional tests and case studies are available in the Appendix section.

Conclusion

Caveats & limitations

Interpreting the observational data in this study requires a lot of nuance. 

We need to emphasize that consent is not always the legal basis for data processing by vendors operating in the EU. There may be other reasons, such as legitimate interest.

This study tried to account for that possibility in some ways. For example, in manual experiments, the users generally made sure to disallow legitimate interests for all purposes beyond showing basic ads.

Furthermore, consent management is a nuanced topic. This study focused exclusively on consent banners and TCF strings; however, ad tech vendors may have other means of soliciting, encoding, and recording user consent. For example, there are many vendors who do not participate in the IAB Europe’s TCF - one notable example is Facebook. Google, a participant in the TCF, also has “a temporary technical specification (called "Additional Consent Mode") intended only for use alongside IAB Europe’s Transparency & Consent Framework (TCF) v2.0 to serve as a bridge for vendors who are not yet registered on the IAB Europe Global Vendor List (GVL).” This present study did not parse any of the “addtl_consent” string (AC string), which contains a list of consented Google Ad Tech Providers that are not registered with IAB.

Some ad tech vendors, even if they participate in the TCF, have additional mechanisms to obtain user consent - for example the Digital Advertising Alliance’s “Your AdChoices”. This study did not factor in telemetry from such orthogonal consent mechanisms.

This study is not meant to be interpreted as legal guidance or even as a legal commentary. No EU GDPR expert lawyers were consulted in the interpretation and compilation of this data. This study is meant as a starting point for further discussion and analysis. One of the key assumptions of this study was that only allowing “basic ads” equates to avoiding setting tracking pixels or cookies, or performing user data syncs. It is possible that this is a false assumption - some vendors may require cookies to perform functions that are strictly related to showing basic ads.

This study was based on purely observational client side telemetry. It is quite possible that, if a server receives data for which there is no lawful consent, the server deletes or avoids storing any copies of the data. For example, some of the vendors who were observed setting tracking cookies in this study may not actually store any of the user’s data in their data tables.

This study also made a best effort attempt to differentiate strictly functional cookies and HTTP requests from those related to personalisation or tracking. Vendors’ documentation was consulted where available, but it is quite possible that there were mis-interpretations with regards to the purpose of certain cookies or HTTPS requests. Adalytics welcomes any constructive feedback from vendors or the IAB Europe that would help clarify any discrepancies about their tech.

Discussion

This empirical research study analyzed whether ad tech vendors actually honor EU users’ consent choices by using careful, deliberate consent platform inputs on a subset of publisher websites. 

This study does not encompass the full range of security hazards that arise under the TCF. It is not possible to audit what ad tech companies do “behind the scenes” because independent researchers cannot monitor whether they transfer data server to server. This study examines only the interactions that can be captured on a user’s device.

The study found that many ad impressions are erroneously labeled, mis-declaring that the GDPR does not apply to users who are located within the EU.

1. The second part of the study was restricted to a small number of publishers that appear to correctly encode a menu for user consent input, in order to isolate the ad tech platform’s role in processing user privacy consent, therefore ruling out the possibility that an error by the publisher or CMP resulted in user profiling occurring without the user’s consent. This was a necessary methodological step to be able to isolate the root cause of user profiling, and to be able to uniquely and deterministically trace the provenance of the profiling to an ad tech vendor.

In most of these experiments, the EU citizens conducting the experiments only consented to “basic ads” and/or “store cookies”. They never consented (or allowed legitimate interest) to:

• Purpose 3 - Create a personalised ads profile

• Purpose 4 - Select personalised ads

• Purpose 7 - Measure ad performance

According to the TCF Policies, this should mean that “line items dropping or targeting a pixel will not serve; no user matching will take place with demand partners”, cookie syncing should not occur, and persistent, unique user identifiers should not be created for users. 

In most of these experiments, the user consented only to a very small number of ad tech vendors to receive data about the user - usually only Google or another major ad exchange.

Yet, despite the fact that EU users:

1. only consented to basic ads with no personalization,
2. explicitly dis-allowed all ad tech vendors besides Google,
3. had their consent signals correctly stored by the publisher and CMP platform;

this study still observed many instances of ad tech vendors and data brokers creating unique user identifiers and performing user data syncs with other vendors. Given the transaction of user data without explicit consent, it does not appear that given transmission of user data are consistent with the GDPR or ePrivacy Directive, or with the IAB Europe’s own Transparency & Consent Framework.

To recap, this study observed several instances where an ad tech vendor was receiving TCF strings that stated the user was objecting to personalised ads, and that the user had not provided consent (or legitimate interest) to specific vendors, such as Linkedin, Amazon, Yahoo, AppNexus, or The Trade Desk.

Beyond the potential trade body implications, the user data flows that were empirically observed in this study raise several concerns about how much control a user actually has over their data.

If the observations and conclusions in this study are correct, it suggests that there may be several technical deficiencies in many ad tech vendor’s infrastructure, which expose them to legal and regulatory risk.

If an ad tech vendor has no record or provenance about user consent signals, and is unknowingly mixing both consent and “nonconsensual” user data, the vendor cannot prove what proportion of their data was obtained in a lawful manner. While unlikely, this could theoretically expose the ad tech vendor to the risk of a regulator asking them to wipe their entire user dataset.

Furthermore, if major brands or marketers discover that their media and ad tech partners are transacting upon illicitly obtained user data, this may reduce the advertisers’ confidence and willingness to conduct business with said ad tech vendors. Many large brands or media agencies have compliance officers, who might take issue with working with ad tech partners who are sourcing user data in a non-compliant fashion.

Adalytics reached out to a top five global agency executive for comment on how they would react when SSPs, DMPs, and/or DSPs claim to have lawfully obtained consent from consumers, but it turns out, the consumers did not provide consent.

The agency executive responded:

“Lots to unpack here. It's a huge concern for us. We strive to maintain an ethical and compliant media supply chain for our clients. When a vendor doesn't honor consent signals, that is not only damaging for the end consumer, but also to our relationship because it calls into question the trust and relationship we have with that vendor. Yes, we use contracts and other legal mechanisms to try to govern those relationships, but we don't want to expose ourselves or our clients to the legal or ethical backlash which would inevitably come from that situation. Even more so, it's unlikely the average consumer is going to blame an obscure media vendor, but rather the brand who's ad they'd be receiving. Put simply, it's a risk and liability we're just not willing to take for ourselves or on behalf of our clients.”

The final implication is a matter of consumer trust. Whilst some individuals may abhor the concept of ads in general, there are a certain subset of consumers who believe that ads are important in supporting the open web. These consumers have a difficult decision to make - how can they support media creators and journalists by allowing ads, while avoiding the negative risks associated with personal data leakage and profiling? These consumers don’t want to ban all ads - merely personalised or behavioral advertising that broadcasts their personal information to a large number of entities. 

This study has demonstrated that, in many instances, even if a consumer was to deliberately make the choice to allow “basic ads” to be shown to them, while dis-allowing tracking and creation of “personalised” profiles on them, some ad tech vendors choose to disregard those instructions and continue to profile the user. Many websites also don’t show any ads to the user, if they select only “allow basic ads”, but no “personalised” ads.

This makes it very difficult for a consumer to earnestly support a media creator or news outlet whilst preserving their own privacy. If consumers believe that their inputs are disregarded, and that the time-consuming task of specifying their consent signals is a futile form of “privacy theater”, then it may result in an increased adoption of ad blockers. This will negatively impact both the ad vendors, marketers & brands, and the publishers. A well-architected and respectful eco-system should be in all stakeholders’ rational self-interest.

Take-away points

1. Many major ad tech vendors continue to track and profile EU users, even when an EU user has explicitly objected
2. The TCF strings that were designed by IAB Europe do not appear to be honored or parsed correctly by many ad tech vendors
3. Some ad tech vendors may not be able demonstrate they obtained user data with user consent, which may expose them to contractual compliance, investor/shareholder disclosure, and regulatory risks
4. In many instances, it is impossible for users to support media creators by allowing “basic ads” whilst disallowing tracking and behavioral profiling to protect their own privacy

Appendix - Additional results from semi-manual tests with partial user consents

German user visits reuters.com

In this example, another EU citizen with a German IP address (we shall refer to them as “Charlotte”), creates a brand new Chrome instance, with no logins, cookies, local storage, or browser history. 

Charlotte proceeds to visit reuters.com. 

As soon as Charlotte opens the Reuters landing page, she is shown a cookie consent banner from OneTrust. Before Charlotte has a chance to make any consent decisions or to read the consent text, several third party domains set cookies in Charlotte’s browser.

We can observe Oracle Eloqua Marketing Automation (“eloqua.com”) sets a cookie called “ELOQUA GUID”, which Oracle’s documentation says is a “global unique identifier” to help personalize websites. Freestar (“d.pub.network”) sets a cookie called “_fsuid” with a 730.5 day expiration age; this cookie is likely a unique user identifier as well.

There are two specific examples however that merit closer scrutiny.

The first is an HTTP GET request that is sent to tapad.com. New York based Tapad “develops and markets software and services for cross-device advertising”, and was acquired by Ireland-based consumer credit reporting multi-national Experian in 2020.

In this HTTP request, we can observe that the “gdpr” parameter is set to “1” (e.g., the GDPR applies to this event), and secondly, we can see a TCF string encoded in the “gdpr_consent” parameter. It is not clear where this TCF string originates from, as Charlotte did not have time to select consent options before this request was sent to Experian’s servers. Furthermore, the data sent from Charlotte’s (German) Chrome browser is sent to the IP address 35.227.248.159, which according to ipinfo.io, is based in Mountain View, California.

Despite this TCF string not being generated through Charlotte’s action’s, let’s take a closer look at what this string actually encodes. The string value “CPRFK4KPRFK4KAcABBENB5CgAAAAAAAAACiQAAAAAAAA.YAAAAAAAAAAA”, when parsed through consentstringdecoder.com/parse, shows that no vendors have been given consent by this TCF string, and there are no purpose consents or vendor legitimate interests. 

Despite the fact that Charlotte’s TCF string does not allow for any processing of her personal data by any third party, we still see Experian setting 3-month cookies on Charlotte’s browser. Tapad’s documentation seems to indicate that the “TapAd_DID” cookie is a unique user identifier for advertising purposes. Another source says that the purpose of both the “TapAd_TS” and “TapAd_DID” are “ is to track users across devices to enable targeted advertising.”

If the purpose of these two tapad.com cookies is indeed to enable targeted advertising, this could present a distinct and unique discrepancy. Tapad and Experian were explicitly and unambiguously notified by Charlotte’s TCF string in this individual HTTP request that no consent was provided specifically for Experian, and that no vendor at all was authorized to set cookies or create a personalised ad tracking profile. Yet despite receiving a clear and direct signal, Experian’s server appears to be responding with instructions to set a unique tracking cookie on Charlotte’s browsers. It is not clear if such a phenomenon is consistent with the ePrivacy Directive, the GDPR, or with the IAB Europe’s TCF.

Secondly, we see that Charlotte’s browser was also instructed to send an HTTPS request to match.adsrvr.org/track from reuters.com. This domain is owned by American demand side platform The Trade Desk. This request also contains the exact same TCF string (which Charlotte did not generate herself) as the one sent to tapad.com. As mentioned above, this string does not provide authorization to any vendor, and it does not provide consent for either setting cookies, nor does it provide consent to create a personalized ad profile.

When the Trade Desk’s server (whose IP address 52.223.40.198, which appears to be based in Seattle, Washington), receives this HTTPS request with the given TCF string, it responds by sending back instructions to Charlotte’s browser to store two cookies - TDID and TDCPM  - for one year.

According to one source, the TDCPM cookie “cookie is used for personalised advertising”. The British Navy’s website also says the adsrvr.og TDID and TDCPM cookies are used for personalised advertising. Lastly, when analyzing the sequence of HTTP requests, Charlotte notices that the adsrvr.org request was initiated by tapad.com, a common data flow pattern observed when two vendors are exchanging data about a specific user via user data syncing.

It is not clear why The Trade Desks’ servers in Washington, when notified by the TCF string that the user specifically has neither provided consent for cookies or for personalized profiling, are still setting persistent cookies in Charlotte’s browser. It is also not clear why Experian and The Trade Desk’s servers are exchanging unique user data about Charlotte, when both parties have received a TCF string that specifically dis-allows such behavior. Lastly, it is not clear if such data flows and API behavior is consistent with the IAB Europe’s TCF.

Germany-based Charlotte finally has a chance to read the OneTrust consent banner that was provided upon visiting reuters.com. Charlotte consents only to “Select basic ads”, but objects to all other activity and purposes. Furthermore, Charlotte chooses not to provide consent to any vendor. Charlotte then clicks “Confirm My Choices”, which saves a first-party cookie called “​​eupubconsent-v2”. 

While Charlotte only consented to “Basic Ads”, one can observe dianomi.com returning various ads to serve to the user. London-based Dianomi is described as a "native ad platform for business and finance". These ads contain post-render viewability and tracking pixels, from both Dianomi and Google owned doubleclick.net.

Example ads returned from dianomi.com on reuters.com to a German IP address user, containing various post-render viewability pixels.

In this case, the HTTPS request sent to dianomi.com did not appear to contain a TCF string, in either the query string parameters, HTTP cookies, or POST body data. According to IAB Europe’s TCF vendor list, Dianomi is a member of the TCF vendor list, so it is not clear why Dianomi’s servers are serving ads when a TCF string is not present.

Belgian user visits nieuwsblad.be

An EU citizen, whom we shall refer to as “Olivia”, was on a Belgian IP address and visited a popular Belgian news website: nieuwsblad.be.

Olivia was presented with a “Privacy Management” consent banner (in Dutch) from Didomi:

Olivia specified that she does not consent (“Niet akkord”) to all purposes, except for basic ads (“Basisadvertenties selecteren”) and allowing for cookies to be stored for specific purposes presented. (“Cookies, apparaatidentificatoren of andere informatie kunnen op uw apparaat worden opgeslagen of geopend voor de doeleinden die aan u worden gepresenteerd.”)

Olivia selected a small list of ad tech vendors to which they provide consent (“Partners bekijken”). The user rejected consent to all ad tech vendors (“Blokkeren”), except for “Google Advertising Products” and “Google Analytics”.

When Olivia saved her preferences by clicking “Opslaan”, her browser stores a first-party cookie called “euconsent-v2”, with the value of “CPRF0t3PRF0t3AHABBENB4CgAMAAAEAAAAAAF5wAQF5gXnABAXmACGgAwABBDcAA.eAAACAAAAAAA”.

If we check the value of this TCF consent string on consentstringdecoder.com, we can see that this “euconsent-v2” cookie correctly encodes the Belgian user’s preferences - she has allowed basic ads (Purpose #2), cookie storage (Purpose #1), and vendor consents to Google Advertising (Vendor #755). The TCF string does not provide consent for Purposes #3 to #6 (“create a personalised ads profile” or “select personalised ads”). Olvia has not given consent to any ad tech vendor beyond Google.

After Olivia has provided consent to Google only, she checks Chrome Developer Tools for network HTTP requests. She can observe HTTPS requests sent to ib.adnxs.com, with the correct TCF string encoded in the gdpr_consent query string parameter. This domain is owned by AppNexus, also known as Xandr. The AppNexus server responds by placing a cookie called “uuid2” for 3-months.

Xandr’s documentation states that the uuid2 cookie “is matched against information – such as advertising interest segments and histories of ads shown in the browser or device – provided by clients or other third parties and stored on the Platform. This information is used by clients to select advertisements for delivery by the Platform [...] When a user opts out of having the Platform used to select ads based on online behavior, the unique value in uuid2 is deleted and replaced with the non-unique value “-1”. 

Given that Olivia objected to personalised ads and creating a personalised profile, only provided consent to Google, and the fact that these consent choices were directly included in the HTTP request to adnxs.com, it is not clear why the AppNexus server responded by setting a persistent, advertising related cookie in Olivia’s browser.

Furthermore, despite consenting to “Basic ads”, none of the ad slots present on the nieuwsblad.be page were filled.

Belgian user visits euronews.com

Another EU citizen, with a Belgian IP address (whom we shall refer to as “Nicolas”) creates a brand new Chrome installation, with no cookies, logins, or previous history. Nicolas proceeds to directly navigate his Chrome browser to euronews.com. 

Euronews.com is an interesting publisher. Firstly, it sets all sorts of 3rd party tracking cookies and initiates various user cookie syncs with many 3rd party data brokers and ad tech vendors, prior to Nicolas having had a chance to access the CMP banner. Furthermore, in many of these HTTPS requests, it appears that euronews.com has configured their Javascript to say “gdpr=0”, meaning that the GDPR does not apply to Nicolas, despite Nicolas IP address clearly being in Flanders. For example, requests are sent to Google’s tracking endpoint, cm.g.doubleclick.net/pixel, and the data is synced then with Adobe owned demdex.net.

The request sent to doubleclick.net also sets a long-lasting cookie called “IDE” in the user’s browser. According to Google’s documentation, the IDE cookie is used for long-term ad personalization and targeting.

Nicolas dutifully proceeds to clear all the cookies in his browser that were set prior to his reading the cookie consent banner on euronews.com. After he has done this, he goes in and consents only to “Show basic ads”, but does not consent to storing cookies or data on his browser. Furthermore, Nicolas only gives consent to one vendor - Google. He goes and objects to all other purposes for processing his data, and objects to all other vendors besides Google. Once he has finalized his consent choices, he saves the selections. This creates a cookie on his browser called “euconsent-v2”, whose value is the TCF string:  “CPRF7vtPRF7vtAHABBENB4CgAEAAAEAAAAAAF5wAQF5gXnABAXmAAAAA.aAAACAAAAAAA”. A quick check on consentstringdecoder.com confirms that this TCF string correctly represents Nicolas’ choices. 

Nicolas returns to his browser’s Network tab, and carefully monitors the inbound and outbound HTTPS requests being sent post-consent. Somewhat surprisingly, he sees a massive list of different ad tech vendors setting cookies, exchanging in user data syncs, and assigning unique IDs.  As there are over 1,000 HTTPS request to parse, Nicolas thinks it would be more prudent to filter the Network tab to only include requests where his TCF string is included as a query string parameter. Nicolas reasons that, since his TCF string only permits Google to serve basic ads, all the vendors and domains that receive his TCF string will promptly curtail ad tracking activity. However, it appears that may not entirely be the case.

Pubmatic, an American sell-side ad tech platform, receives HTTP requests containing the TCF string as an HTTP parameter. This request appears to trigger a User ID sync with Adxpremium.

Furthermore, this individual request also appears to trigger further User ID syncs with Taiwan-based ad vendor Appier, London-based Crimtan (ctnsnet.com), US-based TowerData (idsync.rlcdn.com), and US-based MediaMath (mathtag.com). 

Pubmatic utilizes many cookies in this request, including one called “​​PUBMDCID”. According to Pubmatic’s documentation, this cookie “This cookie stores an ID for the applicable PubMatic data center that is used to display an advertisement in the user’s browser.” Furthermore, over a dozen “KRTBCOOKIE_” and “SyncRTB” cookies are used, wherein each of these cookies appears to be used by Pubmatic to exchange user data about a given person with other ad vendors.

California-based Krush Media also receives header bidding requests containing the restricted TCF string set by Nicolas. Despite this, krushmedia.com sets a cookie called "krm_usr", which appears to contain a unique user identifier. 

Furthermore, the request sent to krushmedia.com triggers multiple user data exchanges, with ap.lijit.com (owned by Colorado-based Sovrn), cookie.lmgssp.com (owned by Luna Media Group), ib.adnxs.com (owned by AppNexus), ssc-cms.33across.com (owned by California-based 33Across), sync.go.sonobi.com (owned by Florida-based Sonobi), sync.aniview.com (owned by New York-based Aniview), krush-match.dotomi.com (owned by Chicago-based Dotomi), us.ck-ie.com (owned by Florida-based SmaryAds), and e.serverbid.com (possibly owned by Maryland-based GiftConnect).

It is not clear whether Krush Media’s setting of tracking cookies on Nicholas’s browser, as well as exchanging unique identifier data about him, is consistent with the design specifications of the TCF.

Nicolas also notices that Danish demand side platform (DSP) called Adform appears to be set cookies and data sync with other vendors, such as user-sync.adxpremium.services, despite receiving a TCF consent string that does not authorize those activities from Adform.

Danish DSP company Adform appears to engage in user data syncing, even when a TCF string encoding the user’s consent disallows Adform from doing so.

E-planning.net (which likely belongs to Argentina based Teroa, SA), was observed receiving  HTTPS requests with the proper TCF string. E-planning.net uses a cookie called simply “E”, which is set to expire in the year 2028. 

The HTML returned by ads.us.e-planning.net’s server does not appear to be consistent with the description of “basic ads” - it contains a multitude of data broker and tracking pixels used for user data syncing.

Inspecting the HTTP initiator chain shows that the return ad creative triggers many data syncs. One interesting observation is that the markup contains multiple Javascript tags from a.audrte.com, owned by London based AudienceRate Ltd. AudienceRate describes itself as an “identity hub”, which “is enabling compliant data-driven advertising via its proprietary technology.” 

Requests sent to a.audrte.com appear to contain an attribute of gdpr=0 and gdpr_consent=null. AudienceRate’s server responds to the HTTP request by setting a cookie called “arcki2_GDPR-CONSENT”, which appears to encode a new TCF string. This TCF string differs significantly from the one Nicolas originally inputted in the CMP dashboard - this new TCF string from audrte.com indicates that the user gave consent to all ten TCF purposes, all ten TCF legitimate interests, and consents to hundreds of vendors. It is not clear why AudienceRate’s tech seems to inject these new TCF string values, rather than using client-side Javascript to poll for the user’s actual TCF choices.

The newly derived, all-consenting TCF string is then used in multiple downstream HTTPS requests from Nicolas’ browser. For example, the new TCF string is used in user data HTTPS requests sent to eyeota.net (owned by Singapore based data broker Eyeota). The new TCF string (overwritten by AudienceRate) is also used in HTTPS requests sent to adform.net and to Google-owned cm.g.doubleclick.net/pixel.

It is not clear if such a pattern of overriding or injecting new TCF string values is consistent with the design specifications of the TCF. The TCF documentation on Github states that “In any case, vendors shall respect the value of gdprApplies put forth by the CMP”, and that they may check to see what the value of the user’s TCF string is by invoking the Javascript “__tcfapi” function.

Nicolas also found one positive example of an ad tech vendor who seemingly did configure their servers to properly parse TCF signals. An HTTPS GET request was sent to sync-eu.connectad.io (likely owned by Austria-based ConnectAd), with the correct TCF string encoded, and instructions to sync user data with rtb.adxpremium.services. Instead of allowing the data sync to go through, ConnectAd terminates the sync chain, and responds with a cookie that deletes the user ID and immediately expires the “uid” and “id” cookies from the user’s browser.

French user visits latribune.fr

Pierre creates a brand new Chrome instance, and visits latribune.fr. Before Pierre has had a chance to read the consent banner, his browser is immediately instructed to send HTTPS requests to a number of vendors, setting cookies from companies such as Linkedin. He clears all his cookies and local storage, and then proceeds to input his consent choices. Seeking a bit of variety this time, Pierre consents to seeing basic ads and to the storage of cookies related to the rendering of those basic ads. He gives permission to only one vendor: American supply side platform OpenX. When he finalises his consent choices, the TCF string is saved in memory and as a cookie with the value “CPRPySLPRPySLAHABBENB5CgAMAAAAAAAAqIAiwAQAigCLABACKAAAAA.eAAAAAAAAAAA”. In this scenario, Pierre’s intent is to support his favorite publisher by agreeing to see non-privacy invading ads served by OpenX, whilst withholding his data from all other vendors and trackers.

Alas, Pierre is disappointed to see that many ad tech vendors are setting cookies and syncing user IDs about him, despite his objecting to purpose consents and legitimate interests relating to creating a personalized profile.

Openx.net is observed triggering user ID syncs with numerous other parties, including Amazon, Google, DataXu, AppNexus, Beeswax (bidr.io), Adelphic Predictive Data platform (ipredictive.com), AdPilot (erne.co), Simplifi Holdings (simpli.fi), and others. For each of these vendors, they also receive an HTTP request with the TCF string that only authorizes OpenX. In the example below, one can observe Google syncing user IDs with Index Exchange, and setting the “IDE” cookie for 13 months. Google’s documentation states that this cookie is “used for these purposes to show Google ads on non-Google sites”, including “personalizing ads”.

Google observed setting 13-month tracking cookies on the French user’s computer, and syncing user IDs with Index Exchange, despite the user only consenting to basic ads from OpenX in their TCF choices.

Amazon was also observed participating in a 302 HTTP redirect chain for user ID syncing with Index Exchange, including receiving the specific TCF string.

French user visits atlantico.fr

Pierre clears his browser, and repeats the experiment, but this time, he only gives consent to Rubicon Project (Magnite) and Index Exchange (Casale Media). He observes Media Math performing user ID syncs, and Google setting the “IDE” cookie in the user’s browser again, after ID syncing with Rubicon Project. Yahoo was also observed setting a cookie called “A3” for one year, which is an ​​”ads targeting cookie for Yahoo”. 

Yahoo targeting cookie being set for 1 year, despite receiving TCF string only consenting to basic ads, no personalized profile creation, and no consent or legitimate interest for Yahoo.

When Pierre visits atlantico.fr, before he has a chance to review the consent banner, he notices his browser immediately firing a long chain of user data syncs via 302 HTTP redirects. Strangely, despite his device being located in Paris, France, many of these HTTP requests claim “gdpr=0”, e.g., that the GDPR does not apply to this user. Furthermore, many of the requests contain a “gdpr_consent=” string that does not actually encode any consent data. The user data sync chain involves over a dozen HTTPS requests, some of which go to IP addresses outside the EU. atlantico.fr uses a CMP on its website, and Pierre verifies (using Chrome Developer Tools, that the “__tcfapi” function states that “gdprApplies: true” in his browser. It is not clear why so many of these ad tech vendors, most of which participate in the IAB Europe TCF, are not independently verifying whether Pierre is in the EU or not, and are instead relying entirely on the presence of the “gdpr=0” query string parameter.

A user ID syncing chain served to a French IP user on atlantico.fr. Note many of the requests say “gdpr=0”, indicating the GDPR does not apply to this given user, or “gdpr_consent” and no value present, despite this user’s IP address being located in Paris, France. This user data exchange involves numerous ad tech vendors, including Smile Wanted Group, The Trade Desk (server IP address 15.197.193.217 in Washington), Google, MediaMath, SpotX, Adform, Adition Technologies, Adobe, and DataXu.

Pierre pauses, and clears his browser of cookies, local, and session storage. He then finishes the consent menu - he gives authorization to Google only, and allows for storing of cookies for the purposes presented to you (“Stocker et/ou accéder à des informations stockées sur un terminal”) and show basic ads (“Sélectionner des publicités standard”). Pierre does not consent to creating a personalised profile (“Créer un profil personnalisé de publicités”). After Pierre finishes selecting his choices, he clicks “Enregistrer et continuer” to save his consent decisions. This saves a TCF string “CPRPIhnPRPIynB7EGCFRB5CgAMAAAAAAAAAAF5wAQF5ghTAMABwAZ8BggDcQG5gN8AdiA7YB3IDvAIKAQpAA” to his browser.

When Pierre refreshes the page, he sees a lot of HTTPS requests being made with this TCF consent string, some of which appear to be user data syncing or setting tracking cookies.

A request sent to s.cpx.to responds by setting a cookie for 1-year called “cpSess”. This domain is owned by London-based Captify, and the “cpSess” cookie appears to be used to store and link personal information about the user. Another source says this “cookie is used as a tracking mechanism for [...] advertising companies. It helps with the delivery of targeted marketing adverts whilst users browse”.

Tracking and targeting marketing cookie set on a French IP address user’s browser from ad tech vendor Captify

TripleLift and Index Exchange were also observed using personalized advertising cookies, called “tluid” and “CMID”, respectively.

A Spanish user visits sport.es

An EU citizen with an IP address in Madrid, Spain (we shall refer to her as Isabela), installs a brand new Chrome browser instance on her desktop, and proceeds to navigate to her favorite sports website - sport.es.

Isabela notices multiple ad tech and tracking calls being made on her browser’s Chrome developer tools before she has a chance to click on any consent choices. She makes sure to clear her cookies, local storage, and network tab, and then proceeds to input her consent choices. Isabela objects to all consent purposes and legitimate interests, except for basic ads. She also only gives consent to one vendor - Rubicon Project. She finalizes and saves her choices; this yields the TCF consent string: “CPRUk5tPRUk5tAHABBENB5CgAEAAAAAAAAiQAaQAQAaAAAAJDQAYAAghuKgAwABBDcJABgACCG4iADAAEENxkAGAAIIbjoAMAAQQ3IQAYAAghuSgAwABBDcpABgACCG4.aAAAAAAAAAAA”.

Isabela notices multiple user ID syncing events and tracking cookies being set, despite those vendors receiving a notification that Isabela only wants basic ads, and no personalization or tracking. These include domains such as:

• Rfihub.com (Rocket Fuel)
• Tribalfusion.com (Exponential Interactive)
• d5-sync.com (ID5 Identify Hub)
• Socdm.com (Supership)
• W55c.net (DataXu)
• Adition.com (Adition)
• Krxd.net (Krux, owned by Salesforce)
• Mathtag.com (MediaMath)

A German user welt.de 

An EU citizen with an IP address in Frankfurt, Germany (we shall call him “Friedrich”) visits welt.de with a brand new Chrome instance. Friedrich consents to basic ads and Google, and specifically disallows all other purposes, legitimate interests, and vendors. Using Chrome Developer Tools, Friedrich verifies that the correct TCF string was stored in memory using the standard “__tcfapi” function.

First, Friedrich notices an HTTPS request sent to dsp.adfarm1.adition.com, with the TCF string encoded. This HTTPS request sets a tracking cookie called “UserID1”, and then triggers a user data sync with odr.mookie1.com. Adition.com is likely owned by ADITION technologies AG, a Düsseldorf, Germany based ad tech vendor which describes itself as a “provider of high-quality media technology solutions for automated, data-based digital marketing.”

mookie1.com is owned by Media Innovation Group, whose website somewhat mysteriously says “The Media Innovation Group is no longer operational.” It is not clear why Adition is setting tracking cookies on a user’s browser after the user has objected to tracking, and has not provided any consent or legitimate interest to Adition. It is also not clear why Adition appears to be user data syncing with a vendor that is no longer in operation, despite not having received consent to do so.

An Italian user visits gazzeta.it

An EU citizen on an Italian IP address (we shall refer to him as “Stefano”) creates a new Chrome browser, and then visits gazzeta.it. He clears all cookies and local storage that were prior to his clicking on the consent banner. He then only allows basic ads, and consents to Rubicon Project, Index Exchange, and OpenX.

Despite this, Stefano observes HTTPS requests sent to a number of ad related domains. One of these is a request to doubleclick.net, Google’s ad serving domain, with the personalized tracking cookie “IDE”. In this case, the request to the Google API does not contain the encoded TCF string.