# You Can't Trust Your Tag Neither: Privacy Leaks and Potential Legal Violations within the Google Tag Manager

Gilles Mertens, Nataliia Bielova, Vincent Roca, Cristiana Santos

► To cite this version:

Gilles Mertens, Nataliia Bielova, Vincent Roca, Cristiana Santos. You Can't Trust Your Tag Neither: Privacy Leaks and Potential Legal Violations within the Google Tag Manager. EuroS&P 2025 - 10th IEEE European Symposium on Security and Privacy, Jun 2025, Venice (Ca' Foscari University), Italy. pp.1-20. [hal-05032798v2](https://hal.science/hal-05032798v2)

HAL Id: hal-05032798

https://hal.science/hal-05032798v2

Submitted on 27 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# You Can't Trust Your Tag Neither: Privacy Leaks and Potential Legal Violations within the Google Tag Manager

Gilles Mertens

Inria Centre at University
Grenoble-Alpes, France
gilles.mertens@inria.fr

Nataliia Bielova

Inria Centre at University
Côte d'Azur, France
nataliia.bielova@inria.fr

Vincent Roca

Inria Centre at University
Grenoble-Alpes, France
vincent.roca@inria.fr

Cristiana Santos

Utrecht University
The Netherlands
c.teixeirasantos@uu.nl

**Abstract**—Tag Management Systems (TMS) were developed in order to support website Publishers in installing multiple third-party JavaScript scripts (Tags) on their websites. Google has proposed its own TMS called “Google Tag Manager” (GTM) that is currently present on 52% of the top 1 million most popular websites. However, GTM has not yet been thoroughly evaluated by the academic research community. In this work, we study, for the first time, the Tags provided within the GTM system. Our methodology consists in installing Tags in isolation to analyze the types of data that Tags collect and contrast them to the legal and technical documentation, in collaboration with a legal expert. Across three studies – in-depth analysis of 6 Tags, automated analysis of 718 Tags, and analysis of Google “Consent Mode” – we discover multiple hidden data leaks, incomplete and diverging declarations, undisclosed third-parties and cookies, personal data sharing without consent and we further identify potential legal violations within EU Data Protection law.

**Index Terms**—online tracking, privacy, consent, GDPR compliance, website Publishers, Google Tag Manager, GTM

## 1. Introduction

Over the last decade, researchers have demonstrated that third-parties collect users' data with the help of third-party JavaScript scripts [1]. Since early 2010, the research field of detection and large-scale measurement of third-party Web tracking has evolved, measuring both stateful [2]–[9] and stateless tracking [10]–[14]. At the same time, policy-makers worldwide have issued new laws and regulations to protect users from such massive data collection by third-party companies. In the EU, the ePrivacy Directive (ePD) [15] and the General Data Protection Regulation (GDPR) require user consent [15]–[17]. These laws have impacted the Web privacy measurement research community, resulting in a new area of automated compliance measurement that has since emerged [18]–[23].

The main components of a website responsible for data collection are third-party JavaScript libraries, invisible to users, that are silently executed in the webpage's background and are often called "Tags" in the Web marketing industry [24]. Initially, to install a Tag on a webpage, the website Publishers, who own a website, only needed to copy and paste an external JavaScript library reference to

<figure><img src="image_2.png" /><figcaption>Figure 1. Client-side Google Tag Manager (GTM)</figcaption></figure>

the webpage's source code. However, as Publishers were installing more and more Tags, manual Tag management became challenging and, as a result, “Tag Management Systems” (TMS) were developed by the industry. TMS allow Publishers to install and configure Tags in a centralized manner without tinkering with the website source code. Once installed on a website, TMS automatically install and execute the third-party Tags selected by the Publisher.

Google developed its own TMS called “Google Tag Manager” (GTM) in 2012. According to BuiltWith [25], it is the most installed TMS on the market: it is present on 52% of the top 1 million websites and more than 60% of the top 10K. Despite its popularity, GTM has received very limited attention so far in the research community, and moreover, its compliance with the Data Protection laws, such as ePD and GDPR, has never been studied.

Figure 1 shows the GTM architecture proposed by Google that we call “Client-side GTM”<fnref n="1" /> since it loads Tags inside the user’s browser within the “GTM Web Container” JavaScript library gtm.js. GTM is a free service for website Publishers. It offers a graphical interface and supports a seamless inclusion of marketing and analytic services implemented as Tags. It is enough for a Publisher to select and properly configure desired Tags to include them in their websites. GTM benefits from a community of contributors who create Tags for

<footnote n="1">1. Google also offers “Server-side GTM” that we do not study here.</footnote>
such services, whom we call “Tag Providers”. Tags rely on the ability of browsers to communicate directly with third-party domains to set cookies and send users’ data to third-parties, whom we call “Data Recipients”.

Differently from traditional large-scale measurement approaches, where all third-party services are analyzed together, in this paper, we study the behavior of Tags in isolation to detect privacy leaks in isolation, allowing us to identify Tags that are responsible for sharing users’ data further with other third-parties. Our analysis method is inspired by previous research that analyzed the behavior of Consent Management Platforms (CMPs) in a fully controlled environment [26], [27] by installing them one-by-one and analyzing them in isolation. Our method is related to the “unitary asset testing methodology” in software development, in which assets are configured and run one at a time, in a controlled execution environment to collect artifacts generated during its execution.

Using this approach, we study Tags in a controlled environment, and we perform (1) an in-depth study of a limited number of most popular Tags, where we analyze the Tags' behavior and compare it to their documentation and dashboard; and (2) a large-scale study of 718 Tags, where we analyze network traffic to detect privacy leaks. Finally, (3) we study a consent mechanism provided by Google – “Google Consent Mode” – to comply with the legal requirements for consent from the EU GDPR and ePrivacy Directive. With this approach, we address the following questions:

**RQ1:** What types of data do Tags collect, and do these types include personal data according to EU law?

**RQ2:** Do Data Recipients disclose what data is collected by the Tags they provide, and if so, do they collect it in a compliant way?

**RQ3:** With whom Tags share users' data, and are companies receiving such data declared by the Tag Providers, as required by the GDPR?

**RQ4:** Does Google Tag collect personal data lawfully when users reject consent under Consent Mode?

To address these questions, we have set up a collaboration with a legal scholar in EU Data Protection law and we make the following contributions, where for each finding, we identified potential legal violations:

* We conduct an in-depth analysis of 6 popular Tags, and identify multiple inconsistencies between the data disclosures in the documentation and data actually sent by these Tags in the network traffic.

* We perform the first large-scale automated analysis of 718 Tags in GTM, detecting that Tags not only set cookies and send users' data to their own servers without proper disclosures, but also include other third-parties with similar practices.

* We study “Google Consent Mode” in Google Tag and discover that data is actively collected via “cookieless pings” despite being declared as passively sent and despite user's consent refusal.

## 2. Related Works and Background

GTM has become a popular tool for managing Tags on websites in recent years, however, to the best of our

knowledge, no scientific study analyzed Tag Management Systems nor GTM in particular. This section introduces related works, followed by background knowledge on GTM and legal background on EU Data Protection laws that we rely upon in this paper.

### 2.1. Related Works

We discuss online tracking studies that measured the prevalence of Google services since GTM is served from a domain owned by Google, *googletagmanager.com* [28]. We then review non-academic sources describing or analyzing GTM and research on privacy documentation. **Online tracking and prevalence of Google.** Multiple works have detected and measured third-party Web tracking at scale over the last decade, identifying Google's massive prevalence in the tracking ecosystem [2]–[9]. In 2009, Krishnamurthy and Wills [29] observed that requests to Google-owned servers happen on 60% of the websites. In 2016, Englehardt and Narayanan conducted an automated detection of stateful and stateless tracking on 1 million sites, showing that Google owned the five most prevalent third-party tracking domains, while *googletagmanager.com* was one of the top-20 third-party trackers [4, Section 5.1]. In 2020, Fouad et al. [9] confirmed again the prevalence of Google – they found the presence of tracking by Google domains on more than 85% of the websites.

**Tag management and GTM.** No academic research appears to have studied Tag management systems to date. However, several people close to AdTech circles share their experience and publish screenshots and other analyses of these tools on the web, either to help Publishers in their deployment or to point out legal or technical issues. The IT and digital marketing expert Julius Fedorovicius publishes courses and ebooks on GTM on his website *Analytics Mania* [30]. The analytics developer Simo Ahava tests and comments on new functionalities in SEO and digital marketing tools. He maintains an extensive documentation on GTM [31], and in a recent article [32], discusses GTM's limitations regarding the lack of control of the Publisher over the data collected by the Tags and problems regarding transparency for end-users. The blogger *Pixel de tracking* [33] explores surveillance issues on the web, and notably the lack of transparency of GTM [34]. Finally, a number of books cover the configuration of GTM, attempting to guide website Publishers in their use of the tool [35], [36].

**Analysis of privacy policies.** Multiple works analyzed privacy policies to compare it with actual practices of websites [37] and apps [38]. These works aimed at discovering discrepancies between the disclosure of the third-parties, types of data collected and cookies, with the actual behavior of websites. Libert [37] conducted an analysis of the top 25 trackers present on websites, and measured the readability of legal documentation, as well as whether third party trackers are disclosed in privacy policies. Andow et al. [39] focused on Android apps “leaks” by automatically comparing privacy-sensitive data flows with privacy policies disclosures and found significant evidence that privacy policies omit as well as incorrectly disclose Data Recipients and data types collected. Tahaei et al. [40] highlight that developers face difficulties understanding
privacy policies and do not always know what to include in these documents. They also state that developers may not read privacy policies and consequently may not be aware when they bear legal consequences [41], [42].

**Summary.** Most of the previous works either focus on large-scale measurement of Web tracking, or non-academics describe the functionalities and configurations of GTM and its Tags. Recent content published by industry experts identify risks for privacy. However, no work so far has neither analyzed the behavior of provided Tags, nor the disclosures of data collection in legal documentation of Tags. Moreover, there are no previous studies focusing on the “Google Consent Mode” specifically introduced by Google to facilitate consent management for GTM Tags. These are the gaps that our work aims to fill.

## 2.2. Google Tag Manager

### 2.2.1. Types of Tags in GTM.
GTM provides an environment for Website Publishers to choose, configure and include Tags in their websites (see Figure 1). Tags are in general any HTML content, and are often simply JavaScript libraries that are provided by companies or developers, whom we call “Tag Providers”. The Tags available in GTM can be put in three categories below.

**81 Natively Supported Tags** [43] are shown in the first layer of the GTM interface. These Tags are for services provided by both Google and third parties. However they do not have a clear description of their Tag Providers.

**702 Community Template Gallery Tags**, that we call “Template Gallery Tags” are available in a marketplace integrated in GTM [44]. Their source code is public and published in a GitHub repository. These Tags are provided by an independent developer or company. Such Tags implement a specific service, for example, the independent developer Simo Ahava provided 22 Tags [45], and one of them is the Facebook Pixel [46]. As a result, Tags send requests to third-party servers, and we call receivers of such requests, “Data Recipients”. Therefore, for Template Gallery Tags, Tag Providers are not necessarily the same entities as Data Recipients.

**Custom image and Custom HTML Tags** are not pre-packaged, but instead are “placeholders” that allow the Publisher to integrate any snippets of HTML as Tags. We do not study them further in this paper.

### 2.2.2. Tag installation process.
When a Publisher selects a Tag, they must first configure it. This involves creating an account on the Data Recipient's website so the server can identify the Tag and collect data. Next, the Data Recipient validates the Publisher's website before allowing the Tag to be added. The Data Recipient then provides a unique ID for each Tag and website pair, which the Publisher manually inputs into the Tag via the GTM interface to identify the source of incoming requests.

Once all Tags are selected and configured, GTM generates a unique “GTM Web Container”, which is a JavaScript library `gtm.js` that now contains all the selected Tags (see Figure 1). A small code is then generated to include in Publisher's website - this code will fetch `gtm.js` and seamlessly include all selected Tags in Publisher's website at runtime.

<table><caption>TABLE 1. GOOGLE CONSENT MODE V2 PARAMETERS FROM GOOGLE'S OFFICIAL DOCUMENTATION [49].</caption><thead><tr><td>Consent mode parameter</td><td>Description</td></tr></thead><tbody><tr><td>ad_storage</td><td>Enables storage (such as cookies) related to advertising</td></tr><tr><td>analytics_storage</td><td>Enables storage (such as cookies) related to analytics e.g., visit duration</td></tr><tr><td>adPersonalisation</td><td>Sets consent for personalized advertising</td></tr><tr><td>ad_user_data</td><td>Sets consent for sending user data related to advertising to Google</td></tr></tbody></table>

When the Data Recipient receives requests from the Tag that the Publisher installed on their website, the Data Recipient provides a specific interface that we call a “Dashboard” to represent the collected information in a unified form (see an example in Figure 5 of the Appendix).

## 2.3. Google Consent Mode v2

Google has introduced the “Consent Mode” [47] – a mechanism that allows to communicate user’s consent status to Google. Consent Mode v1, introduced in 2020, contained two consent mode parameters – `ad_storage` and `analytics_storage` [48]. This version, now called “Basic implementation”, only allowed to block tags from execution when the consent is denied by the user.

On March 4, 2024, a few days before the EU Digital Markets Act [50] came into force, Google has introduced an updated system – Consent Mode v2 – and added two additional consent mode parameters: `ad_user_data`, and `adPersonalisation` [49] (all four up-to-date consent mode parameters are shown in Table 1). This version introduced an “Advanced implementation” that allows Tags to load and run, and their behavior can be modified when consent is declined. According to Google documentation [47], Tags send “cookieless pings” that communicate the consent state and other user activity. As of now, only Tags provided by Google modify their behavior with respect to the consent given by the user [47].

## 2.4. EU Data Protection Law

The General Data Protection Regulation (GDPR) [16] applies to the processing of personal data [51] and imposes obligations on those actors who determine the data processing purposes and its means. The ePrivacy Directive (ePD) [15] provides supplementary rules to the GDPR in particular for the use of tracking technologies. Whenever any information is stored and read from the user's device, the ePD [15, Art. 5(3)] requires organizations to request user consent for certain purposes, such as advertising [52], [53] to process data. The only way to assess with certainty whether consent is required is to analyze the purpose of each tracker on a given website [54], [55].

### 2.4.1. Personal data.
Personal data is “any information relating to an identified or identifiable natural person ('data subject'). An identifiable natural person is one who can be identified, directly or indirectly [16, Art. 4(11)]. In order to determine whether a person is identifiable, account should be taken of all the means likely reasonably to be used by any actor to identify that person. Accordingly,
if certain data, alone, is not personal data, it becomes personal data as regards to someone who reasonably has the means of enabling that data to be associated with a specific person [56, para. 46]. GDPR Recital 30 asserts that online identifiers provided by their devices, such as IP addresses, can be associated to a person, thus making them identifiable. This identification does not require that all the information enabling that person to be identified should be in the hands of a single entity [57, para. 42, 43]. Processing of personal data consists of “any operation(s) performed on personal data, such as collecting, sharing, using, making available, accessing, combining” [16, Art. 4(2)].

### 2.4.2. GDPR obligations for Website Publishers.
Publishers can be held responsible and fined if they fail to comply with their obligations under the GDPR [16, Art. 28(3)(f), 32-36]. When processing personal data, website Publishers must comply with the following GDPR principles, that will guide our legal analysis: *Lawfulness*: collect personal data only with a valid legal basis (Art. 5(1)(a)); *Fairness*: avoid processing data unjustifiably detrimental, discriminatory, unexpected or misleading (Art. 5(1)(a)); *Transparency*: inform users about purposes, recipients, and legal bases when collecting data (Art. 5(1)(a), 13-14); *Security*: ensure data protection to prevent unauthorized access (Art. 5(1)(f), 32); *Data Protection by Default*: process data with the highest privacy settings by default (Art. 25(1)(2); *Accountability*: demonstrate compliance at all times with data protection principles (Art. 5(2)).

## 3. Methodology

In this section, we present our new methodology to analyze the behavior of Tags available in GTM and combine it with the analysis of Tags' legal and technical documentation. We then complement this with legal analysis to identify potential violations of the EU laws to answer our research questions from Section 1.

Our approach is to use the method of *detecting privacy leaks in isolation* for each studied Tag by installing them in a controlled environment instead than in the wild. We then analyze the network traffic collected during the Tag's execution and rely on extensive analysis of the legal and technical documentation of companies that receive data sent by the Tag in the network requests (Section 3.2).

Figure 2 gives an overview of three studies we have performed. The first study proposes an in-depth analysis of popular Tags, in the second study we automatize the process of analysis of Tags' behavior, and the third study evaluates data sent by Google Tag that implements Consent Mode v2. Our methods are further detailed in Section 3.1. We ran these studies in March-April 2024 on Google Chrome version 122, from the Flathub repository [58], using the default settings and installed on a GNU/Linux operating system (kernel 6.6.x-lts). We visited the websites from a computer connected to the Internet through an institutional network in the EU.

### 3.1. Detecting Privacy Leaks in Isolation

Prior research showed that third-party libraries are rarely interacting with only one tracking domain [4],

[9]. Instead, such libraries often include other content, thus initiating requests to multiple domains, and often enabling tracking the user. Therefore, analyzing Tags' behavior on the websites, where they are installed, may be very complex due to the presence of multiple Tags and communications with tens of servers on the same page.

To overcome this problem, we *detect privacy leaks in isolation*. This method is inspired by the previous research on analyzing the behavior of Consent Management Platforms (CMPs) in a fully controlled environment [26], [27] by installing them one-by-one on an empty website and evaluating their behaviors in isolation. Our method is also related to the “unitary asset testing methodology”in software development, when each asset (in our case, each Tag) is configured and run one at a time, in a fully controlled execution environment to collect all artifacts generated during its execution.

#### 3.1.1. Creating controlled environment.
To analyze the behavior of each Tag in isolation, we assume the role of a website Publisher, whose goal is to configure GTM and select Tags the Publisher wants to include in their website. To simulate such Publisher who sets up the GTM infrastructure, we bought a TLD+1 domain that we call *example.com* in the rest of the paper. We host *example.com* on a virtual machine we rented on a public cloud provider and located in France. We created a new Google account to create GTM Web containers to install on our own websites (Web container is needed to install Tags in GTM, see Figure 1).

For an in-depth study, we created a new Web container for each Tag to be tested and installed on a new corresponding website `<tagID>.example.com`, where `tagID` corresponds to a unique identifier of a Tag in GTM. For our automated study, we use a single website *example.com* and Web container where our automated script installs each Tag in isolation one after the other. Our in-depth and automated analyses did not use consent management solutions. We kept the default configuration for our Nginx web server, which does not set security headers such as `content-security-policy` or `Access-Control-Allow-Origin`. This allowed the website (and its tags) to send HTTP requests to any third-party domain. The source code of our website is available in the supplementary materials [59]. We used the “profiles” functionality of the browser to make every visit in a fresh environment, devoid from cookies, local storage and other technologies than maintain a state.

#### 3.1.2. Capturing network traffic.
To study the data collected and sent by Tags in both in-depth and automatic studies, we used the developer tools integrated in the Google Chrome browser during a new visit and used the export function that creates a HAR [60] report containing HTTP(S) requests and responses as well as cookies stored on our empty website. In order to have a reference point, we first install an empty Web container on our website and capture all the network traffic in a form of a HAR report. We call it *baseline traffic*. It contains HTTP(S) requests to our website (`<tagid>.example.com` for in-depth study and *example.com* for automatic study) and a request to *googletagmanager.com* loading the GTM Web container. When analyzing traffic generated by
<figure><img src="image_3.png" /><figcaption>Figure 2. High-level overview of our framework to analyze the behavior of Tags and their legal compliance.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Figure 3. Official and Unofficial Tags in GTM.</figcaption></figure>

each Tag, we filter out the baseline traffic to obtain only traffic generated by the Tag.

**3.1.3. Official and Unofficial Tags.** Sometimes, the company or developer that provides a Tag – the *Tag Provider* – is also the receiver of requests initiated by the Tag – the *Data Recipient* (Section 2.2). However, some Tags are also provided by independent developers who implement services for different Data Recipients. Consequently, in our study, we propose to separate Tags into two groups that we call “Official” and “Unofficial” (shown in Figure 3).

We consider a Tag to be Official when its Tag Provider is also a Data Recipient (but since some Tags send data to many different servers, there could be several Data Recipients); otherwise, we consider the Tag to be Unofficial.

Natively Supported Tags are provided by the companies that implement their own service, and we note that the names of these Tags contain the name of the company. We therefore assume that these Tags are provided by the companies that collect the data, meaning that Tag Providers are also Data Recipients. We consider all such Tags to be Official.

Template Gallery Tags instead require further detailed analysis. To determine who is the Tag Provider, we visit its GitHub repository associated to the Template Gallery Tag and leverage GitHub's organization verification feature [61] that certifies that a certain company is the owner of the repository. We then consider this company to be the Tag Provider. If there is no GitHub certification for

the repository, we consider such Tag to be Unofficial. However, it is not possible to know who are the Data Recipients by analyzing the publicly available information about Template Gallery Tags. We therefore analyze the traffic initiated by each Template Gallery Tags to identify whether the Tag sends requests to its Tag Provider. If yes, we conclude that the Tag Provider is also a Data Recipient, and therefore such Tag is considered Official.

## 3.2. Legal and technical documentation

Previous research on data collection disclosures focused solely on analyzing the privacy policies of websites and apps [39], [62]. Other works [20], [37] included cookie policies and terms of use. While conducting a preliminary analysis of privacy policies of Data Recipients, we found that disclosures of data types spreads across even more documents, differing among the Data Recipients, such as technical documentation. Therefore, we took a different approach than prior work, and included these documents, rather than limiting ourselves to legal documentation.

For the study of the documentation, we chose to analyze only Official Tags, when the Tag Provider is also Data Recipient. We searched for both legal and technical documentation of Data Recipient that could be available to the website Publisher who is installing the respective Tag. We collected the sources of information on the Data Recipient's website and also during the sign up process when creating an account on its website.

The set of *legal documentation* was defined together with the legal scholar, and it contains *policies* (e.g., “Privacy/Advertisement/Cookie Disclosure Policy”), *terms* (e.g., “Terms of service”, “Terms of use”, “Product terms”, “Data Processing Terms”), *agreements* (e.g., “Data sharing agreement”, “Service Agreement”, “Data Processing Agreement”) and linked *addendum* (e.g., “Data Protection Addendum”). For the Google Tag, we have studied the legal documentation of the Google Analytics that has recently been included in the Google Tag [63].
By technical documentation, we consider all other documents provided by the Data Recipient, such as technical guides, FAQs and information for developers.

We found that legal documents are often broad, covering multiple products and the Data Recipient's website. Our legal expert could not identify the relevant sections alone, so the reading was done collaboratively by the legal expert and a computer scientist. Time spent on each Tag's documentation was limited to 2 hours.

After collecting all documentation for the Tags in each study, neither the legal scholar nor the computer scientists could identify which parts specifically referred to a given Tag. This occurred for 4 out of 6 studied Tags in the in-depth study, 10 out of 11 Tags selected in the automated study, and for Google Tag in the consent mode study. We believe the lack of clarity arises because the legal documentation is company-wide, not product-specific. Additionally, terms like "visitors" are ambiguous, as they could refer to either Publishers visiting the Data Recipient's website or users visiting the Publisher's website where the Tag is installed. Related work on privacy policies [64] reports this same lack of specificity of finding data practice descriptions specific to a given website or service; they are often quite generic as they apply to a range of products of that organization or are umbrella policies.

**3.2.1. Limitations.** We have analyzed the collected documentation searching for specific disclosures, while acknowledging that the lack of specificity may impact the results presented in this paper. Our analysis of documents is also limited by one IT and one legal expert which might have introduced bias in their interpretation.

## 3.3. In-depth study of popular Tags

In our first experiment, we perform an in-depth analysis of popular Tags by installing them one-per-website, each on a dedicated domain `<tagID>.example.com`. Our goal is to study each Tag's behavior and detect privacy leaks by performing actions a typical website Publisher would perform. In this study, we manually interacted with the website, prompting the tags to collect data. We performed the following actions: moving the mouse, downloading a file, scrolling, and using the search bar on our website. We contrast and compare three sources of information available to the Publisher:

*   **Network traffic:** users' data transmitted by the Tag that we capture in the network traffic initiated by the Tag (Section 3.1);

*   **Legal and technical documentation:** information about data collected by the Data Recipient disclosed in their official privacy policies and other technical documents (Section 3.2);

*   **Dashboard:** information about data received by the Data Recipient shown to the Publisher in the Dashboard (Section 2.2).

**3.3.1. Selecting and installing popular Tags.** In order to be able to compare the behavior of a Tag to its own documentation, we decided to study only Official Tags, where the company that provides the Tag is the same as

<table><caption>TABLE 2. THE 6 TAGS SELECTED FOR IN-DEPTH STUDY. A "*" INDICATES TAGS SELECTED FROM THE TEMPLATE GALLERY, THE REST OF THE TAGS ARE NATIVELY SUPPORTED BY GOOGLE.</caption><thead><tr><td>Tag selected</td><td>Domain owner from [65]</td><td>Domain and ranking according to [14]</td></tr></thead><tbody><tr><td>Google Tag</td><td>Google LLC</td><td>google-analytics.com (1)</td></tr><tr><td>Twitter Base Pixel *</td><td>Twitter, Inc.</td><td>twitter.com (15)</td></tr><tr><td>comScore Unified Digital Measurement</td><td>comScore, Inc</td><td>scorecardresearch.com (18)</td></tr><tr><td>Quantcast Advertise</td><td>Quantcast Corporation</td><td>quantserve.com (21)</td></tr><tr><td>Hotjar Tracking Code</td><td>Hotjar Ltd</td><td>hotjar.com (27)</td></tr><tr><td>LinkedIn Insight</td><td>Microsoft Corporation</td><td> linkedin.com (46)</td></tr></tbody></table>

the company that receives the data from the Tag, that is when Tag Providers are the same as Data Recipients (Section 3.1.3). This solution allows us to study the legal and technical documentation of the Tag Provider, which would not be possible if the Tag Provider was a different entity than the company collecting the data.

In order to select the most popular Tags, we first identify the most popular third-party domains based on prior work, and then match these domains, that represent Data Recipients, to the Official Tags. We use the top 50 most prevalent third-party domains collected from Alexa top 10K in 2020 [14]. For each domain found, we use Tracker Radar [65] to identify the company who owns the domain. Out of the top 50 third-party domains in our list, we identified 30 distinct companies that own these domains. We then pick one Official Tag proposed by the company we identified. For example, for the most popular third-party domain `google-analytics.com`, we identified its owner Google and selected the "Google Tag" since it is offered by Google and comprises the Google Analytics functionality in this Tag [63]. Whenever we do not find any Tag proposed by the company behind a third-party domain (e.g.,, there is no Tag that contains "Microsoft" in a Tag's name), we search for the Tag whose name contains the domain name (we have searched for `linkedin.com` and found the Tag named "LinkedIn Insight").

We have identified that out of 30 companies that own 50 top third-party domains, only 8 companies propose Tags in GTM². We have installed each of these 8 Tags in the corresponding website `<tagID>.example.com` and tried to create an account on the website of the Data Recipient, so that its server recognizes the specific requests it will receive from this Tag and properly collect received data. However, Data Recipients often check and validate the Publisher's website before allowing the Tag to be added (Section 2.2). In our experiment, for 2 Tags – "Criteo OneTag - Official" and "LiveRamp" – our account was not validated, and we therefore proceeded with the remaining 6 Tags, shown in Table 2.

2. The top 50 most popular third-party domains with the corresponding Tags we identified are available in the Appendix, Figure 6 and in the supplemental materials [59].
**3.3.2. Dashboard of the Data Recipient.** While installing each Tag, we create an account on its Data Recipient's website to then add the Tag in its corresponding Web container. We follow instructions to configure it, and "link" the Tag to our account. Once the Tag is installed and configured on the corresponding `<tagID>.example.com` website, we visit this website and then log on to the Data Recipient's website, to see a specific interface that we call "Dashboard", which represents the collected information in a unified form (see an example in Figure 5 of the Appendix). Finally, we identify in the Dashboard the data that the Data Recipient has received when we visited the Tag's website `<tagID>.example.com`. The proof that the Data Recipient actually has registered the data types from the incoming network traffic is the demonstration of such data types in the dashboard.

**3.3.3. Network traffic analysis.** There is no specific documentation on what data is sent by Tags in the network traffic, and where exactly in the traffic it is located. We therefore first build a list of all possible data types by analyzing the legal and technical documentation as well as the dashboard for the 6 Tags. The resulting list can be found in the first column of Table 3. For each data type in the list (e.g., "screen resolution"), we detect when the value of the data type (i.e., our screen resolution) was shown in the dashboard of a given Tag. We then search for this value in the traffic initiated by the given Tag. Specifically, we search through URL parameters of the HTTP(S) requests, body of the HTTP POST requests and content of the WebSocket messages that are sent. For example, in Google Tag's dashboard, we identified that our screen resolution was collected (shown as "2560x1440"). We searched for the two values, "2560" and "1440" in the HAR file we collected on our website `googletag.example.com` where Google Tag is installed. We found a "2560x1440" value in one of the URL parameters in a request to `google-analytics.com`. When analyzing Hotjar Tracking Code Tag, we found in its dashboard that the screen resolution was also collected. However, when analyzing network traffic initiated by the Hotjar Tracking Code Tag installed on `hotjar.example.com`, we found that it sends the window width and height in two separate parameters in the JSON format sent via a WebSocket.

With our method, for each Tag, we determine a list of data types actively collected by the Tag and sent in its network traffic. The active collection of data types by Tags demonstrates that the data is intentionally sent by the Tag's script and therefore collected by Data Recipients.

Because of the observed diversity of formats and location in sending the same data type across Tags (e.g., the "screen resolution"), it is hard to unify the analysis and detection of data types uniformly among all Tags and we proceed one Tag at a time. Nevertheless, we noted that the referral URL (URL of the previously visited page), the page title and the page URL are usually sent in clear. Therefore we have opted for also detecting these three data types across all Tags uniformly by searching for these three values in clear in the outgoing requests. Whenever we find these data types in the traffic, we add them to the list of data types actively collected by the Tag.

Additionally, we record all the data types that are *passively sent by each Tag*, that is, IP address, TLS session ID, and HTTP headers that are sent with HTTP requests (user-agent header: browser name/version, device type/name, accept-language header: browser language, referrer header: page URL). Since this data is sent passively, we further consider that the Tag has indeed collected this data only if such data type appears in the dashboard, or in the legal or technical documentation, indicating that this data type was indeed collected.

**3.3.4. Limitations.** We do not analyze prevalence of tags in the wild and therefore we do not provide further statistical results about the data that the Tags collect in the wild. However, our in-depth study does demonstrate the types of data. We limited the number of Tags because it is impossible to properly install and configure them automatically (Section 3.3.1). Indeed, across the Tags we installed, the configuration processes vary a lot, dashboards present information in very different forms, and legal documentations are organized differently. Among the 6 analyzed Tags, "*comScore Unified Digital Measurement*" and "*LinkedIn Insight*" did not let us see the dashboard, either because our website did not pass a manual review (comScore), or because the Tag did not collect data from a sufficient number of visitors (LinkedIn). Tags which collaborate to collect data (e.g., one gathering the information and the other exfiltrating it) are not studied as our methodology consists in analyzing tags individually. While we studied technical documentation and included elements Tags rely upon to collect data, our website did not include all the features found on public websites (e.g., login form, or product basket) and Tags could collect more data than we observed.

## 3.4. Automated study of all available Tags

In the second study, we aim at analyzing all the Tags available in GTM. However, a proper installation and configuration of a Tag requires to set up an account on the Data Recipient's website and ensure that further setup process is complete. Our analysis of 6 popular Tags in the in-depth study showed that such processes differ significantly across Tags and therefore are hard to automatize.

**3.4.1. Automated lightweight installation and data collection.** To scale Tag analysis, we used a simplified installation process. Since automating account creation and Tag configuration on the Data Recipient's website is complex, we developed a script to automatically install Tags and fill in required fields with invalid but plausible information.

We used the GTM API to automatically install the 81 natively supported tags. However, this API does not support the installation of template gallery tags. We therefore automatically imported the 702 Template Gallery Tags from their source code, available on the associated Github repository, that is indicated in the description of each such Tag in the GTM interface. Interestingly, we found that Github source code is sometimes more recent than the code available in GTM (i.e., the Tag Provider pushed new code to Github but GTM did not update yet the Tag in the template gallery). Also, we found Tags that contain
errors – the Tag Provider pushed invalid code to Github and GTM could not update the Template Tag – and we discard such Tags from further analysis.

When adding a Tag to a GTM Web Container, its configuration fields are often validated by GTM. If any field is invalid, the GTM Web Container throws an error and the Tag is not saved. Our script initially attempts to leave all fields blank when adding the Tag. In case of errors, the script generates a string that meets the requirements of the specified error and retries to install the Tag. Examples of such errors are “value must not be empty”, “value must be a positive integer”, “value does not match the regular expression”, “length must be between x and y characters”. The code generating the configuration strings is available in the artifacts.

As a result, our script – available in the supplemental materials [59] – makes the following process for each Tag. First, it automatically installs a Tag on our empty website *example.com* by using GTM’s API [66]. Second, the script visits our website *example.com* with Puppeteer [67] version 22.6.4 to collect the HTTP requests and responses in a form of HAR [60] as well as cookies installed by the studied Tag. Finally, it closes the browser and uninstalls the Tag. Out of 81 Natively Supported Tags and 702 Template Gallery Tags, we managed to automatically install and analyze 718 Tags (that is, 74 Natively Supported and 644 Template Gallery Tags).

### 3.4.2. Network traffic analysis.
We use the *baseline traffic* we have collected by installing an empty Web container on our website *example.com* (Section 3.1.2). For each Tag, we collect the traffic in the form of HAR file [60] and cookies set during the automated visit to *example.com* where the Tag is installed. We then remove the baseline traffic in the HTTP traces to obtain only traffic generated by the Tag. Since no cookies are present in the baseline traffic, we do not apply such filtering to cookies.

We extract from the HAR file all TLD+1 contacted by the studied Tag and identify the companies that own these domains using the Tracker radar [65]. Whenever we do not find the domain, we also use the Disconnect list [68]. When we do not find a domain in neither list we consider each unidentified TLD+1 to be a different company. As a result, for each of the 718 Tags, we obtain the list of domains/companies contacted by the Tag together with the cookies that these domains install.

### 3.4.3. Legal documentation.
For Tags that contact multiple companies, we further need to check the *legal documentation* of the Tag Providers, to see whether they properly disclose the potential sharing of users’ data. In this work we only analyze the legal documentation of official Tags, for which the Tag Provider is also Data Recipient (Section 3.1.3). So we search for the legal documentation on the website of the Data Recipient, and check whether: it clearly mentions the Tag; it declares all the companies that this Tag is contacting according to our network traffic analysis; and whether third-party cookies created by the Tag are described in the legal documentation.

### 3.4.4. Limitations.
Our crawler did not interact with our website. As a result, we do not observe the behavior of Tags that are triggered by user interaction. Since we

configured Tags with placeholders instead of linking them to an account on Data Recipient’s websites, we may have missed specific Tags behavior that would happen only when Tags are configured with the proper account.

Some Tags could not be installed automatically because our script could not configure the Tag with plausible information. Here also, our testing method misses all tags that are collaborating (e.g., one gathering the information and the other exfiltrating it) as every Tag is only tested in isolation. In this experiment, observations should be considered as a lower bound of data collected by Tags.

We did not analyze the technical documentation for Tags that communicate with multiple companies, as it is typically available only after account creation, which we did not do in this study.

## 3.5. Comparative study of Tag behavior between our in-depth and automated studies

To better understand the implications of our methods, we compared the behavior of Tags common to the two studies using our two methods: in-depth and automated. To achieve this, we compared the network traffic of 6 tags using these two methods. In the automated method, only one page is visited, while the in-depth method involves two pages due to interaction. For a fair comparison, we only consider traffic from the first page in the in-depth method and compare it with the automated method. We first compare the number of successful requests by type: script downloads, GET requests (except scrips), POST requests and WebSockets opened. Then, we search for the data types identified in the in-depth setting, in the network traffic collected within the automated setting.

## 3.6. Study of Google Consent Mode v2

The Consent Mode v2 introduced by Google allows to communicate the consent decisions from the consent banner provided by the Consent Management Platform (CMP) to the Tags (Section 2.3). Consent Mode introduced four “consent parameters” (see Table 1) that can have two possible values, “granted” or “denied” [69].

The five Tags provided by Google (Section 2.3) contain checks for the values of consent mode parameters in their code, and modify their behavior based on the values of these parameters, thus providing the “Advanced Implementation” of Consent Mode v2. To analyze the consent mode, we have selected the “Google Tag” since it now contains the popular Google Analytics functionality [63].

To analyze how the Google Tag changes its behavior depending on consent provided by the user, we have set up two pages `consent.html` and `noconsent.html` on `consent-mode.example.com`. These pages contain a text, a search bar and a link to download a file. To each page, we add the code provided to CMPs to set the default value of consent variables [70] to test two settings:

* *refuse all*, where all the consent mode parameters are set to “denied” on `noconsent.html`, and

* *accept all*, where all the consent mode parameters are set to “granted” on `consent.html`.

On each of the two pages, we add the same Web container with only Google Tag installed. We then visit
each page with the clean browser profile and perform out
three actions, simulating user behavior: we download a
file, scroll to the bottom of the page, and use the search
bar with the therm "my search". For each webpage, we
collect the HAR file and cookies.

**3.6.1. Network traffic analysis.** Our in-depth analysis of Google Tag revealed that this Tag sends user information only in the URL parameters of HTTP(S) requests. During our visits on the two pages, after removing the baseline traffic, 6 HTTP requests were made by Google Tag to *google-analytics.com*. We extracted the URL parameters for each of the 6 requests and compared the types of data sent when consenting and when refusing. Whenever the Tag sets a first-party cookie via its script, we search for this cookie value in clear in the URL parameters of all 6 requests to detect when cookies are sent to Google.

**3.6.2. Legal and technical documentation.** Since Google Tag was already present in our in-depth study (Section 3.3), here we compare and contrast our findings from the network traffic for *refuse all* and *accept all* settings to both legal and technical documentation and also additionally study documentation about Consent Mode [71], [72].

**3.7. Proactive prevention of harm**

This research does not involve any human nor the
processing of personal data. Our testing websites are
not mentioned in any public sources, and thus are very
unlikely to be accessed by the general public. We visit
these websites with a clean browsing profile, thus not
revealing any personal information of the experimenter.

We study services provided by several companies by
following these services' legal and technical documenta-
tion, analyzing the network traffic on our website and
dashboards provided by the services. Our research did
not involve any written or live discussion with employees
of these companies, we only used documentation and
automated web services. In this research, we did not find
any security vulnerability. However we identified *potential
legal violations*³ under EU Data Protection law. If we did
not seize our IRB for all the reasons mentioned above, we
keep the president of our institutional IRB aware of the
present work and of discussions with these companies.

After submitting this article, we reached out to (1) all 6 companies identified in our in-depth study (see Table 3) with potential disclosure issues; (2) 9 companies whose tags transmit data to multiple third parties without disclosure (see Table 4), and (3) Google whose Tag collects data without consent (Section 4.4.1)⁴.

On November 29, 2024, we have sent 12 emails and 3
paper mail letters to companies when we did not find an
email address. As of March 4, 2025, out of 15 companies
we have received 5 responses: 3 reviewed their products,
while 2 provided more documentation and invited us to
review our findings. However, reviewing their documen-
tation did not affect the findings reported in the paper.

3. We underline the importance of using the word “potential” since only court decisions can ultimately conclude about its presence.

4. A copy of the messages we sent can be found in the Appendix.

4. Findings

We present our main findings for the three studies (see
Figure 2) and their legal consequences.

**4.1. In-depth study of six Tags**

For the six Tags we have successfully installed and
configured (see Table 2), we have further analyzed the net-
work traffic initiated by these Tags and compared the data
extracted from the traffic with the dashboard, legal and
technical documentation of the corresponding Data Re-
cipients (Section 3.3). In this process, we have answered
the research questions **RQ1** and **RQ2** and identified two
major issues: collection of personal data and insufficient
disclosures about such data collection.

Within network traffic, we searched for the data type
values found in the documentation or dashboard. Almost
all such values were found in clear text and we therefore
did not search for encoded/hashed values. Regarding the
only two values we did not find⁵: first, a referral URL
for *Linkedin Insight* was not found in clear text, while
non-understandable values changed with each experiment
repetition, and such data cannot be the referral URL; sec-
ond, out of 12 data types reported by *Quantcast Advertise*,
only screen resolution collection was not found, that may
have been encrypted. However these two cases did not
justify a further modification to our methodology.

**4.1.1. Data collected by Tags can be personal data.** In this section, we answer **RQ1** on what types of data the Tags collect and whether such data constitutes personal data. The types of data sent by the studied 6 Tags to the Data Recipients contain a variety of information, such as browser and device information, operating system properties, capturing user interaction, as well as cookies and time zones. These data types are presented in Table 3, alongside with the presence of this data in the network traffic, dashboard, technical and legal documentation. We argue that these data consists of *personal identifiable data*.

Upon a user's visit to a website embedding a Tag,
this Tag sends HTTP(S) requests to the Data Recipient's
server, and inevitably, the server is able to access the IP
address of the end user. An IP address would be personal
data if, in combination with other data, it relates to an
identified or identifiable person⁶. In order to determine
whether a person is identifiable, account should be taken
of all the means that can reasonably be used by any actor
to identify that person (Recital 26 GDPR). This means that
any actor having the means to identify a user, renders such
a user identifiable [57], [74]. Data Recipients have the
means to collect the end-user IP addresses and to combine
it with all information sent together with the IP address
by each tag and that relates to an identifiable person, such
as browser, device, operating system, user interaction,
user information and identification. This combination of
indirectly identifiable data is personal data.

5. See empty cells in "network traffic", where the corresponding cells in documentation or dashboard columns are filled in Table 3.

6. Not every IP address is by default personal data and each case should be studied by regulatory authorities. The EDPB acknowledges that an IP address could be originating from a user's router or a CGNAT grouping a number of subscribers under the same public IP address [73].
<table><caption>TABLE 3. TYPES OF DATA COLLECTED ACCORDING TO THE NETWORK TRAFFIC, DASHBOARD, TECHNICAL AND LEGAL DOCUMENTATION. NUMBERS IN THE TABLE CORRESPOND TO THE DISCLOSURE ISSUE DISCUSSED IN SECTION 4.1.2. FOR NETWORK TRAFFIC, A FILLED CELL (WITH EITHER "X" OR A NUMBER) INDICATES THAT THE DATA TYPE HAS BEEN actively collected. THE STAR "*" INDICATES THAT THE DATA IS SENT AS A PART OF THE HTTP(S) COMMUNICATION, AND THEREFORE HAS BEEN passively sent. THE "X" SIGN IN THE DASHBOARD OR DOCUMENTATION MEANS THAT THE DATA TYPE IS PRESENT. A FILLED CELL IN GRAY AREAS INDICATES THAT THE DOCUMENTATION DECLARES THIS BROAD CATEGORY OF DATA BEING SENT. "COMSCORE UDM" STANDS FOR COMSCORE UNIFIED DIGITAL MEASUREMENT.</caption><thead><tr><th rowspan="2"></th><th colspan="3">Google Tag</th><th colspan="3">Twitter Base Pixel</th><th colspan="3">Hotjar Tracking Code</th><th colspan="3">Quantcast Advertise</th><th colspan="3">comScore UDM</th><th colspan="3">LinkedIn Insight</th></tr><tr><th>network traffic</th><th>dashboard</th><th>technical doc.</th><th>network traffic</th><th>dashboard</th><th>technical doc.</th><th>network traffic</th><th>dashboard</th><th>technical doc.</th><th>network traffic</th><th>dashboard</th><th>technical doc.</th><th>network traffic</th><th>technical doc.</th><th>legal doc.</th><th>network traffic</th><th>technical doc.</th><th>legal doc.</th></tr></thead><tbody><tr><td><strong>type of data collected</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>browser</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Name and version</td><td>x</td><td>x</td><td>①</td><td>x*</td><td></td><td></td><td>x*</td><td>x</td><td></td><td>x*</td><td>x</td><td>x</td><td>x*</td><td></td><td>⑤*</td><td></td><td></td><td></td></tr><tr><td>user agent string</td><td>④</td><td>①</td><td></td><td>x*</td><td></td><td></td><td>④</td><td></td><td>④*</td><td></td><td>③</td><td>x*</td><td></td><td>⑤*</td><td>③</td><td></td><td></td><td></td></tr><tr><td>language</td><td>x</td><td>x</td><td>①</td><td>x*</td><td></td><td></td><td>④</td><td></td><td>②</td><td></td><td>④*</td><td>③</td><td>x*</td><td></td><td>⑤*</td><td></td><td></td><td></td></tr><tr><td>tls session id</td><td>x*</td><td></td><td></td><td>x*</td><td></td><td></td><td>x*</td><td></td><td></td><td>x*</td><td>③</td><td>x*</td><td></td><td>⑤*</td><td></td><td></td><td></td><td></td></tr><tr><td><strong>device</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>screen resolution</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td>x</td><td>x</td><td>x</td><td>x</td><td></td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>type (e.g., desktop, tablet, ...)</td><td>x*</td><td>x</td><td>①</td><td>x*</td><td></td><td></td><td>x*</td><td>x</td><td>x</td><td>x*</td><td>x</td><td></td><td>x*</td><td></td><td>⑤*</td><td></td><td></td><td></td></tr><tr><td>IP address</td><td>x*</td><td>①</td><td>x</td><td>x*</td><td></td><td></td><td>④*</td><td>x</td><td>x</td><td></td><td>④</td><td>③</td><td>x*</td><td></td><td>⑤*</td><td></td><td></td><td></td></tr><tr><td>city (derived from IP address)</td><td>⑤</td><td>x</td><td>③</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>④</td><td>③</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>country (derived from IP address)</td><td>⑤</td><td>x</td><td>③</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>③</td><td>③</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>operating system</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>version</td><td>⑤</td><td>x</td><td>③</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>name</td><td>⑤</td><td>x</td><td>③</td><td>x*</td><td></td><td></td><td>x*</td><td>x</td><td></td><td>④⑤*</td><td>③</td><td>x*</td><td></td><td>x*</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>user interactions</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>forms interacted with</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>form destination</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>date of visit (derived)</td><td>x</td><td>x</td><td>①</td><td></td><td>⑤</td><td>x</td><td></td><td>x</td><td>x</td><td>②</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>name of files downloaded</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>referral url (url of prev. page)</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td>②</td><td>④</td><td>①</td><td>⑤</td><td>③</td><td></td><td></td><td>③</td><td></td></tr><tr><td>page title</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>⑤</td><td>③</td><td></td><td>⑤</td><td>③</td><td></td></tr><tr><td>page Url</td><td>x</td><td>x</td><td>①</td><td>④⑤</td><td>x</td><td></td><td>x</td><td>x</td><td>②</td><td>④</td><td>①</td><td>⑤</td><td>③</td><td></td><td>⑤</td><td>③</td><td></td><td></td></tr><tr><td>search terms</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>time spent on pages</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td>x</td><td>x</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>scroling actions</td><td>x</td><td>x</td><td>①</td><td></td><td></td><td></td><td>x</td><td>x</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>keypress (not specific key)</td><td></td><td></td><td></td><td></td><td></td><td></td><td>x</td><td>x</td><td>②</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>mouse positions</td><td></td><td></td><td></td><td></td><td></td><td></td><td>x</td><td>x</td><td>②</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>mouse clicks</td><td></td><td></td><td></td><td></td><td></td><td></td><td>x</td><td>x</td><td>②</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>cookies and time zone</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>cookies</td><td>④⑤</td><td>③</td><td>④⑤</td><td>③</td><td></td><td></td><td>④</td><td>x</td><td>x</td><td>④</td><td>③</td><td></td><td></td><td>⑤</td><td></td><td></td><td></td><td></td></tr><tr><td>time zone</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>x</td><td>x</td><td>③</td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

### 4.1.2. Disclosures of collected data from Data Recipients.
We found that Data Recipients declare the data they collect in their technical documentation and/or in the legal documentation, and sometimes demonstrate in the dashboard. Table 3 summerizes our findings, organized by five types of mismatches between the data sent in network traffic, dashboard and documentation. Our findings demonstrate that Publishers who need to know what data types are collected, must read and understand all the documentation before installing the Tag on their website, to know what data is shared with the Data Recipients. In the rest of this section, we answer the research question RQ2 whether Tags disclose what data they collect in a compliant way. As mentioned in Section 3.2 we analyzed, both legal and technical documentation to understand where and how Data Recipients disclose what data is collected by their Tags. We present our findings, labeled by numbers, such as ②, that can be found in Table 3, each highlighted in a different color.

① **Legal documentation is general but technical documentation mentions specific data types.** Unspecified and general data is disclosed in the legal documentation while technical documentation is specific. Google Tag seems to use this as a general strategy, since most of data it sends is mentioned in a general manner in the legal documentation, while technical documents list specific data types. Quantcast Advertise Tag does not seem to employ a general strategy, it discloses device and user interactions categories in the legal documentation (such as “information about your interactions with the content”), while its technical documentation lists specific data types, such as screen resolution, referral URL and page URL).

② **Technical documentation is general but legal documentation mentions specific data types.** We also identified a disclosure problem opposite to issue ①, that is specific to Hotjar Tracking Code Tag. It actively collects the language, referral and page URL, keypresses and mouse positions and clicks, and derives the date of the visit. All these specific data types are mentioned in the legal documentation, while the technical documentation only mentions at a general level that browser information is collected.

③ **Data types are declared in either legal or technical documents, but not in both.** We observed that data collected is disclosed only in legal or technical documentation, affecting all six Tags studied. Collected data is disclosed in the technical documentation but absent in the legal one for Google Tag regarding derived city and country, and version and name of the operating system. Conversely, Hotjar declares country and OS in
legal documentation but not in the technical one.

④ Some Data Recipients do not show collected data in the dashboard. By analyzing the dashboards of four Tags – where the dashboards were accessible<fnref n="7" /> – we found that, for all Tags, some data sent in the traffic is not shown to the Publisher on their respective dashboard. These four Tags set cookies. For example, Google Tag and Hotjar Tracking Code Tags set first-party cookies, and Twitter Base Pixel and Quantcast Advertise Tags set third-party cookies – however, no cookie-related information is shown in the Data Recipient's dashboards.

⑤ Data is sent in network traffic but not declared in legal documentation. Five out of the six studied Tags send specific data types that are not disclosed in the legal documentation. Google Tag passively sends the IP address of the user, as stated in the legal documentation. Additionally, Google Tag seems to derive the city and the country from the user's IP address, and while these data types are shown in the dashboard and mentioned in the technical documentation, such derived information is not mentioned in the legal documentation. From the network requests of the Twitter Base Pixel Tag, Twitter derives the date of visit and shows it in the dashboard, but does not declare it in any documentation. This Tag also does not disclose the collection of third-party cookies. comScore Unified Digital Measurement and LinkedIn Insight Tags send the page title and website URL and mention it in technical, but not in legal documentation.

### 4.1.3. Consequences for Publishers.
Publishers need to read both legal and technical documentation to understand data collection practices associated with the Tags they include, however none of these documentations is complete ①, ②, ③. Moreover, previous works assert that legal documentation is difficult for non-lawyers to understand, and that developers have insufficient knowledge of privacy policies [40]–[42]. An alternative solution could be to use the dashboards, but we question their value and purpose ④, since Publishers cannot depend on these as a transparency resource because certain data is collected, but never shown on the dashboard. Alternatively, Publishers could take on the burden of conducting their own data traffic analysis. However, such traffic analysis shows that the disclosure of data types in the legal documentation is not enough for Publishers to understand what data is, in effect, collected by the Tags they use ⑤. As a result, Publishers may struggle to determine the types of collected data, and whether data is being derived or passively sent. This fact denotes omissions between the actual data flow and the legal documentation (also known in the literature as flow-to-policy omissions [75]). Additionally, performing traffic analysis presents another challenge, as it requires technical expertise of network principles and specific tools, that is at odds with the overall approach of GTM aimed at an easy integration of third-party Tags.

### 4.1.4. Compliance Consequences.
Data Recipients shift the burden onto Publishers to understand their own data collection practices through the tags they build. In particular, Publishers need to understand how legal and technical

<figure><img src="image_5.png" /><figcaption>Figure 4. Tags that contact three or more third-party companies. Blue color highlights the number of companies receiving a request initiated by the Tag; red - the number of companies receiving the page URL; green - the number of companies setting third-party cookies.</figcaption></figure>

documentation align with each other, as well as with the actual data being collected and what is displayed on the dashboard. If Publishers are not able to understand the documentation and/or the traffic analysis, they are not able to disclose in their privacy policies the data they collect and send to Data Recipients. The absence of such data disclosure infringes the *Transparency principle*. This principle demands that Data Controller(s) must declare the categories of personal data they process, alongside purposes, recipients, risks and consequences for processing personal data ( [16, Art. 14(1)(d)], Recital 39) [76, para. 40] [77, para. 74]). Consequently, end-users cannot exercise their own individual rights (e.g., access, rectification) on the data they share, which infringes the *Fairness principle* (Arts. 5(1)(a), 15-22 of the GDPR) [78].

## 4.2. Automated study of all available Tags

While automatically analyzing traffic generated by 718 Tags, we identified multiple instances of data sharing with third-parties, addressing research question **RQ3**.

### 4.2.1. Tags send requests to multiple third-parties.

Our analysis of traffic generated by 718 Tags shows that 352 (49%) Tags send at least one request to a server⁸. Moreover, 68 of such Tags communicate with multiple third-party domains, indicating that users' data is potentially shared with other companies than the main Data Recipient associated to the Tag. Since some companies own multiple domains, we matched domains with companies (Section 3.4.2) and identified 49 Tags that send data to multiple companies. Moreover, out of these 49 Tags, 47 send the visited page URL in the HTTP "Referer" header to multiple companies and 9 Tags set third-party cookies.

Figure 4 focuses on the top 13 Tags (out of 49) that contact three or more companies, most of them also share the visited page URL and 6 Tags contact multiple companies that themselves set third-party cookies. For instance, Criteo OneTag sends requests to 26 third-party companies, 10 of which also set third-party cookies. This finding shows that Publishers need to be aware not only of the data shared by Tags with their own Data Recipients, but also about data shared and cookies set by other companies. We therefore further analyze disclosures of the Data Recipients associated to such Tags.

8. Tags are likely not sending as many requests as they would have sent if properly configured. See limitations in Section 3.4.4.

<footnote n="7">7. comScore Unified Digital Measurement and LinkedIn Insight Tags did not allow us to see the dashboard, see Section 3.3.4.</footnote>
<table><caption>TABLE 4. TAGS SENDING REQUESTS TO MULTIPLE THIRD-PARTIES. "IP," SIGNIFIES FIRST-PARTY AND "3P.", THIRD-PARTY COOKIES.</caption><thead><tr><th>Tag</th><th>Provider</th><th># companies receiving requests</th><th># undeclared companies</th><th>type of cookies</th><th>declared cookies set by the Tag</th><th># other companies setting cookies</th><th>max. cookie duration (in days)</th></tr></thead><tbody><tr><td>Criteo One Tag</td><td>Criteo SA</td><td>26</td><td>3</td><td>3p.</td><td>no</td><td>9</td><td>400</td></tr><tr><td>Perfect Audience Pixel</td><td>Sharpspring</td><td>6</td><td>4</td><td>3p.</td><td>no</td><td>1</td><td>400</td></tr><tr><td>Message Mate</td><td>Owner Listens</td><td>4</td><td>1</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>FirstImpression.io Integration Tag</td><td>AppendAd</td><td>3</td><td>0</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Shareaholic</td><td>Shareaholic</td><td>3</td><td>2</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>AWIN Conversion</td><td>Awin AG</td><td>2</td><td>1</td><td>1p.</td><td>no</td><td>-</td><td>365</td></tr><tr><td>Ternair Marketing Cloud Clicks Tracking</td><td>Ternair</td><td>2</td><td>0</td><td>1p.</td><td>no</td><td>-</td><td>400</td></tr><tr><td>Amplitude Analytics Legacy</td><td>Amplitude</td><td>2</td><td>1</td><td>1p.</td><td>no</td><td>-</td><td>365</td></tr><tr><td>Faslet's Size Me Up</td><td>Faslet</td><td>2</td><td>1</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Sprig Tag</td><td>Sprig</td><td>2</td><td>1</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Infoset</td><td>Infoset</td><td>2</td><td>1</td><td>1p.</td><td>yes</td><td>-</td><td>400</td></tr></tbody></table>

**4.2.2. Tags Providers do not always disclose the companies contacted by the Tag.** From the 49 Tags that send requests to multiple companies, we identified 11 official Tags (see details in Section 3.1.3) and analyzed their legal documentation together with our legal co-author. Interestingly, we found only one Tag – Ternair Marketing – that explicitly mentions a Tag in its legal documentation. Table 4 summarizes our findings. Only 3 out of 11 Tags disclose all companies contacted by the Tag. For instance, Perfect Audience Tag sends requests to 6 companies, and 4 of them are not disclosed, namely *OpenX Technologies Inc.* (openx.net), *Magnite, Inc.* (rubiconproject.com), *Twitter, Inc.* (twitter.com) and *Verizon Media* (yahoo.com).

**4.2.3. Tags set cookies without declaring them.** We found that 6 out of 11 Tags set first and third-party cookies, but only Infoset Tag specifies which cookies are set and mentions their purposes in the legal documentation<fnref n="9" />. Other Tags do not disclose specific cookies and their purposes, using phrasing such as "[t]hrough cookies placed on your browser or device, we may collect information" [79] or "may store and access data on your device or browser, including by setting new cookies" [80].

**4.2.4. When Tags contact multiple third-parties, some of them set cookies without disclosure.** Additionally to setting their own cookies, Tags also send requests to other companies, some of which also set cookies. Out of the 49 such Tags, 9 set third-party cookies. Out of 11 Official Tags we have analyzed, 2 include requests to other

companies that set their own cookies. For example, Criteo One Tag includes requests to 26 companies, and 9 of these companies set 21 different cookies<fnref n="10" />. This finding shows that Publishers need to be aware that Tags can create and share cookies not only with their own Data Recipients, but also with other companies.

**4.2.5. Compliance Consequences for Publishers due to lack of disclosures.** When a Publisher installs a Tag that fails to disclose all contacted third-party recipients, they are unaware of these entities, raising significant legal implications. This lack of disclosure hinders compliance with the *Transparency principle* that requires informing users about data recipients and their rights [16, Art. 14(1)(e), Recital 63], [77] [81, para. 26]. It also obstructs compliance with the *Security principle* mandating technical and organizational measures to prevent unauthorized disclosure of personal data [16, Arts. 5(1)(f), 32].

Furthermore, both Tags and multiple third-party companies set first- and third-party cookies without being disclosed in the legal documentation (Sections 4.2.3 and 4.2.4). To determine whether a (first or third-party) cookie requires the legal basis of consent, *purpose, duration and context* need to be analyzed [54], [55]. Since the purpose is never mentioned in the legal documentation, we analyze duration and context. *Duration* of at least one cookie set by each Tag is 365-400 days and in 2 out of 6 tags, *third-party cookies* are set (see Table 4). Consent is required for such cookies. Since the Publisher is unaware that certain tags/companies set such cookies, they cannot request the necessary consent from users for those cookies, which results in a violation of the *Lawfulness principle*.

**4.2.6. Compliance consequences for Publishers regarding personal data.** Differently from the in-depth study, here we do not extensively investigate all Tags' documentation nor dashboard, and hence we do not analyze what data types are collected actively. However, when tags send requests to their own Data Recipients and to third-parties, the user's IP address and other browser- and OS-related data is *passively sent*. Similar to our reasoning in in-depth study, we argue that data sent by Tags is potentially *personal data* since Publishers and Data Recipients may have the means that are reasonably likely to identify end-users. They have access to the IP address and can combine it with additional identifiable data (Section 4.1.1).

## 4.3. Comparative analysis

We compared the behavior of the 6 Tags analyzed in the in-depth study, against their behavior in our automated analysis (Section 3.5).

Table 5 shows the types of requests made by the 6 tags during the two experiments. We observe that the *Google Tag* remained completely inactive in the automated study. The *Hotjar Tracking Code* and *Twitter Base Pixel* Tags still downloaded scripts as in the in-depth study but did not make any other request. Only two Tags (i.e., *LinkedIn Insight* and *Quantcast Advertise*) behave the same regarding the number of scripts downloaded and requests sent. In spite of our efforts in reasonably configuring the Tags

<footnote n="9">9. Such documentation is available in the supplemental materials [59]</footnote>

<footnote n="10">10. See Table 7 in the Appendix listing all such cookies.</footnote>
<table><caption>TABLE 5. NUMBER OF REQUESTS PER TYPE MADE BY TAGS IN THE IN-DEPTH AND AUTOMATED ANALYSIS. LIMITATIONS OF THE AUTOMATED ANALYSIS ARE HIGHLIGHTED IN RED.</caption><thead><tr><th rowspan="2"></th><th colspan="2">Google Tag</th><th colspan="2">Twitter Base Pixel</th><th colspan="2">Hotjar tracking Code</th><th colspan="2">Quantcast Advertise</th><th colspan="2">LinkedIn Insight</th></tr><tr><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th></tr></thead><tbody><tr><td>Script</td><td>1</td><td>0</td><td>1</td><td>1</td><td>2</td><td>1</td><td>2</td><td>2</td><td>1</td><td>1</td></tr><tr><td>GET</td><td>0</td><td>0</td><td>2</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>POST</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td></tr><tr><td>WebSocket</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr></tbody></table>

(Section 3.4), the *comScore Unified Digital Measurement Tag* could not be installed in our automated method.

Table 6 further compares the data types collected during the two studies. *Google Tag* loads its script in the in-depth study and therefore sends multiple types of data only within the in-depth study (shown in red color). *Hotjar Tracking Code* loads only one script and therefore passive data is sent. However, it does not load the second script responsible for the *WebSocket* and the active collection of data. *Twitter Base Pixel* Tags only sends “passive data” (i.e., data sent as part of the HTTP communication, highlighted with the “*” in the “network traffic” columns in Table 6) and cookies when downloading scripts, but do not send any other type of data. The *LinkedIn Insight* and *Quantcast Advertise* Tags send the same data types.

## 4.4. Google Consent Mode v2

We study Google Tag under Google Consent Mode v2 and analyze whether it collects personal data lawfully, thus answering **RQ4**. We examine whether Google Tag disclosures correspond to the data collected during traffic analysis and explore the related compliance issues.

Google consent mode v2 technical documentation mentions that Google Tag can run and will send “*cookieless pings*” even when users decline consent. It further declares that “[t]he data collected in the cookieless ping is used for behavioral and conversion modeling, to fill the gaps in your data” [71] and that it is used by Google AI to model the behavior of users who did not consent “at times when it is not possible to observe the path between ad interactions and conversions” [72].

Regarding the data collected by such pings, the documentation says that “[c]ookieless pings, as part of regular HTTP browser communication, may include the following information: user agent, screen resolution, IP address.” [82]. Moreover, the documentation says that when consent mode parameter `analytics_storage` is denied, “cookieless pings” are sent, but “[n]o Analytics cookies are set, accessed, or read from the device”. Our experiment confirmed that under the *refuse all* condition (where all consent parameters are denied), no cookies are indeed set or sent by the Google Tag. However, we have found several types of data sent by cookieless pings that lead to potential legal violations, described below.

### 4.4.1. Data is actively collected via “cookieless pings”, but declared in the documentation as passively collected.
In our experiment, we compared the URL parameters of all six requests<fnref n="11" /> initiated by Google Tag under two consent choices: *accept all* and *refuse all* (Section 3.6). We found that the URL parameters under these two consent choices contain the same data, meaning that the Google Tag *actively collects* user language, screen resolution, computer architecture, user agent string, operating system and its version, complete URL of the visited webpage, search keywords on the visited webpage and sends it to the Google server. Differently from Google’s documentation that entails that data is *passively sent*, our results demonstrate that *data is actively collected* by Google Tag and added to the request in the URL parameters. Moreover, this data is always sent, regardless of the consent choices, since it is sent both under *accept all* and *decline all* conditions.

<table><caption>TABLE 6. COMPARISON OF DATA TYPES COLLECTED BY THE TAGS IN OUR TWO SETTINGS. DIFFERENCES IN DATA COLLECTED IS SHOWN IN RED. THE PRESENCE OF A STAR “*” INDICATES THAT THIS DATA TYPE IS SENT AS PART OF THE HTTP(S) COMMUNICATION.</caption><thead><tr><th rowspan="2">type of data collected</th><th colspan="2">Google Tag</th><th colspan="2">Twitter Base Pixel</th><th colspan="2">Hotjar Tracking Code</th><th colspan="2">Quantcast Advertise</th><th colspan="2">LinkedIn Insight</th></tr><tr><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th><th>in-depth</th><th>automated</th></tr></thead><tbody><tr><td><strong>browser</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Name and version</td><td>X</td><td></td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td>user agent string</td><td>X</td><td></td><td>X*</td><td>X*</td><td>X</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td>language</td><td>X</td><td></td><td>X*</td><td>X*</td><td>X</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td>tls session id</td><td>X*</td><td></td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td><strong>device</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>screen resolution</td><td>X</td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>type (e.g., desktop, tablet)</td><td>X*</td><td></td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td>IP address</td><td>X*</td><td></td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td><strong>operating system</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>version</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>name</td><td>X</td><td></td><td>X*</td><td>X*</td><td>X*</td><td>X*</td><td>X</td><td>X*</td><td>X*</td><td>X*</td></tr><tr><td><strong>user interactions</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>forms interacted with</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>form destination</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>name of files downloaded</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>referral (url of prev. page)</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>page title</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>X</td><td>X</td></tr><tr><td>page Url</td><td>X</td><td></td><td>X</td><td></td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>search terms</td><td>X</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>time spent on pages</td><td>X</td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>scroling actions</td><td>X</td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>keypress (no specific key)</td><td></td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>mouse positions</td><td></td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>mouse clicks</td><td></td><td></td><td></td><td></td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td><strong>cookies and time zone</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>cookies</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>time zone</td><td></td><td></td><td></td><td></td><td></td><td></td><td>X</td><td>X</td><td></td><td></td></tr></tbody></table>

### 4.4.2. Cookieless pings are declared to be anonymized upon user consent refusal.
Google claims that the data collected in cookieless pings is “anonymized and non-identifiable Google Analytics events.” [71]. Our experiment confirms that within cookieless pings, the `cid` parameter, instead of containing the value of the `_ga` cookie (that is created when the user consents), contains a value randomly generated by the Google Tag on every web page visited and used instead.

### 4.4.3. Compliance consequences for Publishers due to lack of disclosures.
Google Analytics server receives several types of user data even if users reject consent, as mentioned in Section 4.4.1 and Table 9. In combination with these data types, it receives the IP address of the

<footnote n="11">11. Example Table 9, full requests in supplemental materials [59]</footnote>
user which is actively collected by the Google Tag and added to the request in the URL parameters. Following the arguments presented in Section 4.1.1, we argue that the data collected by Google Analytics might be qualified as personal data. Moreover, when users reject consent for the (ad_storage and analytics_storage) variables, Google Analytics may collect and process personal data *without* a legal basis, thereby infringing the *Lawfulness* principle. We further claim the processing of personal data for behavioral and conversion modeling [72] could possibly infringe the *Fairness principle* as users do not anticipate their data being collected after refusing consent.

Although Google claims that cookieless pings are anonymized and non-identifiable Google Analytics events [71], we argue users can still be indirectly identifiable by combining the data mentioned in Section 4.4.1 with the user's IP address. Consequently, the claimed anonymization measure fails to meet the *Data Protection by Default principle*, as it does not adequately ensure that personal data is not processed by default [16, Art. 24(2)].

Google Tag facilitates personal data transfers to Google LLC in the U.S. However, several regulators have deemed EU-U.S. data transfers to Google Analytics illegal because the required contractual, organizational, and technical measures are insufficient to prevent access by U.S. intelligence services [83], [84]. Consequently, transferring unique identifiers, IP addresses, browser data, and metadata to Google LLC undermines the level of protection of personal data (Art. 44) and violates the *Lawfulness and Security principles*.

## 4.5. Implications for Publishers

**Data collected through Tags can be personal data.** This paper argues that end-users can possibly be *identifiable* since both Publishers and Data Recipients may have the means that are likely reasonably to be used to identify them through the combination of an IP address and several other data types, observed to be collected across the three studies (Sections 4.1.1, 4.2.6, 4.4.3).

**Disclosures in the documentation of data collected and data recipients are not sufficient.** Across our studies, we found that Data Recipients *do not* declare in their documentation: the Tag it refers to (Section 3.2); data recipients (Section 4.2.2); cookies used by the Tag (Section 4.2.3); and declare data types in various places (Section 4.1.2).

**Network traffic analysis is insufficient to detect derived and passive data collection.** We found that Data Recipients store certain data which is either *derived* from other types of data or *passively sent* (Table 3). For e.g., Google Tag technical documentation states that the city and country are derived from the user's IP address (Section 4.1). Such example shows that Data Recipients collect and store more data types than what directly appears in the network traffic. Therefore, analyzing network traffic alone is insufficient to identify all the data types being collected. Solely relying on disclosures is also inefficient.

**Legal implications for Publishers.** Data Recipients often place the burden onto the Publisher to understand their data collection practices. This implication might not be immediately clear to the Publisher because disclosures are often incomplete. The practice of insufficient disclosures across Tags makes it hard for the Publisher to comply with

*transparency* obligations. However, the lack of knowledge about the processing of personal data through Tags does not excuse the Publisher's *accountability* obligations [85]. Publishers must legitimize personal data processing with a legal basis, such as consent, when storing or reading identifiers like IP addresses, cookies, or other trackers from users' devices to comply with the *Lawfulness principle*.

## 4.6. Implications for Tag Providers

**Tag Providers that are Data Recipients (official Tags).** We found that certain official Tags send data to other companies without declaring it in the documentation (Section 4.2.1); some set cookies without specifying them in documentation (Section 4.2.3), while others list data types collected in different places (Section 4.1), complicating Publisher's GDPR compliance. Attributing legal responsibility for these issues to Data Recipients is non-trivial. This is especially the case for Google Tag that leaks data even when users reject consent, resulting in the unlawful transfer of data to the US (Section 4.4.3). We contend that these actors cannot exonerate themselves of responsibility and shift it onto Publishers that include their Tags. Conversely, Publishers have a part of responsibility if they choose non-compliant Tags [86]. Hence, the responsibility of non-compliant Tags could potentially be shared between Data Recipients and Publishers, but we leave this discussion to future work.

**Tag Providers that are not Data Recipients (unofficial Tags).** In the GTM configuration interface, each Template Gallery Tag is listed by name (e.g., "Facebook Pixel") along with its Tag Provider (e.g., Simo Ahava [46]). However, when the Tag Provider is an unofficial entity and not a Data Recipient, it becomes harder to determine responsibility and data collection disclosure obligations.

## 5. Conclusion

This work is the first to study the Tags within the Google Tag Manager, their behavior and the data types they collect through three studies, including a first automated large-scale study of 718 Tags. We discovered multiple hidden data leaks, unclear documentation, undisclosed third-parties and personal data sharing without consent, and provided a legal analysis and derived compliance issues for our findings. Our results demonstrate compliance implications for Publishers, the most critical being that disclosures in Tags documentation are incomplete and diverging. This fact introduces an important burden for Publishers to understand the data collection practices of each specific Tag and all third-parties it includes, leaving Publishers struggling to meet their legal obligations.

## Acknowledgment

This work has been supported by the ANR 22-PECY-0002 IPoP (Interdisciplinary Project on Privacy) project of the Cybersecurity PEPR, the TULIP project of the ANR MRSEI program 2023, and the Inria International Chair funding. The authors would like to thank Michael Toth, former Inria PhD student, and Javiera Bermudez Alegria, from Universidad de Chile, who contributed to the initial work, and all the anonymous reviewers for helping us improve this paper.
## References

[1] N. Nikiforakis, L. Invernizzi, A. Kapravelos, S. Van Acker, W. Joosen, C. Kruegel, F. Piessens, and G. Vigna, "You are what you include: large-scale evaluation of remote javascript inclusions," in *Proceedings of the 2012 ACM conference on Computer and communications security*, (Raleigh North Carolina USA), pp. 736–747, ACM, Oct. 2012.

[2] F. Roesner, T. Kohno, and D. Wetherall, "Detecting and defending against third-party tracking on the web," in *Proceedings of the 9th USENIX Symposium on Networked Systems Design and Implementation*, NSDI 2012, pp. 155–168, 2012.

[3] A. Lerner, A. K. Simpson, T. Kohno, and F. Roesner, "Internet jones and the raiders of the lost trackers: An archaeological study of web tracking from 1996 to 2016," in *25th USENIX Security Symposium (USENIX Security 16)*, USENIX Association, 2016.

[4] S. Englehardt and A. Narayanan, "Online tracking: A 1-million-site measurement and analysis," in *Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security* (E. R. Weippl, S. Katzenbeisser, C. Kruegel, A. C. Myers, and S. Halevi, eds.), pp. 1388–1401, ACM, 2016.

[5] M. A. Bashir, S. Arshad, W. Robertson, and C. Wilson, "Tracing Information Flows Between Ad Exchanges Using Retargeted Ads," in *Proceedings of the 25th USENIX Security Symposium*, (Austin, TX), August 2016.

[6] Z. Yu, S. Macbeth, K. Modi, and J. M. Pujol, "Tracking the trackers," in *International Conference on World Wide Web, WWW*, pp. 121–132, 2016.

[7] M. A. Bashir and C. Wilson, "Diffusion of User Tracking Data in the Online Advertising Ecosystem," in *Proceedings on Privacy Enhancing Technologies (PETS 2018)*, 2018.

[8] C. Iordanou, G. Smaragdakis, I. Poese, and N. Laoutaris, "Tracing cross border web tracking," in *ACM Internet Measurement Conference (IMC)*, 2018.

[9] I. Fouad, N. Bielova, A. Legout, and N. Sarafijanovic-Djukic, "Missed by Filter Lists: Detecting Unknown Third-Party Trackers with Invisible Pixels," in *Proceedings on Privacy Enhancing Technologies (PoPETS)*, vol. 2020, pp. 499–518, 2020. Published online: 08 May 2020, https://doi.org/10.2478/popets-2020-0038.

[10] G. Acar, M. Juárez, N. Nikiforakis, C. Díaz, S. F. Gürses, F. Piessens, and B. Preneel, "Fpdetective: dusting the web for fingerprinters," in *2013 ACM SIGSAC Conference on Computer and Communications Security (CCS'13)*, pp. 1129–1140, 2013.

[11] G. Acar, C. Eubank, S. Englehardt, M. Juárez, A. Narayanan, and C. Díaz, "The web never forgets: Persistent tracking mechanisms in the wild," in *Proceedings of the ACM SIGSAC Conference on Computer and Communications Security*, pp. 674–689, 2014.

[12] P. Laperdrix, N. Bielova, B. Baudry, and G. Avoine, "Browser fingerprinting: A survey," *ACM Transactions on the Web (TWEB)*, vol. 14, no. 2, pp. 8:1–8:33, 2020.

[13] P. N. Bahrami, U. Iqbal, and Z. Shafiq, "Fp-radar: Longitudinal measurement and early detection of browser fingerprinting," in *Proceedings on Privacy Enhancing Technologies (PoPETS)*, vol. 2022, pp. 557–577, 2022.

[14] I. Fouad, C. Santos, A. Legout, and N. Bielova, "My cookie is a phoenix: detection, measurement, and lawfulness of cookie respawning with browser fingerprinting," *Proceedings on Privacy Enhancing Technologies (PoPETS)*, vol. 2022, pp. 79–98, 2022. https://petsymposium.org/popets/2022/popets-2022-0063.pdf.

[15] "Directive 2009/136/EC of the European Parliament and of the Council of 25 November 2009," 2009. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32009L0136, accessed on 2019.10.31.

[16] "Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance)," 2016. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32016R0679.

[17] C. Santos, N. Bielova, and C. Matte, "Are cookie banners indeed compliant with the law? deciphering EU legal requirements on consent and technical means to verify compliance of cookie banners," *Technology and Regulation (TechReg)*, pp. 91–135, 2020.

[18] C. Matte, N. Bielova, and C. Santos, "Do cookie banners respect my choice? measuring legal compliance of banners from iab europe's transparency and consent framework," in *IEEE Symposium on Security and Privacy (IEEE S&P)*, 2020.

[19] I. Sanchez-Rola, M. Dell'Amico, P. Kotzias, D. Balzarotti, L. Bilge, P.-A. Vervier, and I. Santos, "Can I opt out yet?: GDPR and the global illusion of cookie control," in *Asia Conference on Computer and Communications Security (AsiaCCS'19)*, 2019.

[20] M. Degeling, C. Utz, C. Lentzsch, H. Hosseini, F. Schaub, and T. Holz, "We Value Your Privacy ... Now Take Some Cookies: Measuring the GDPR's Impact on Web Privacy," in *Network and Distributed Systems Security Symposium*, 2019.

[21] T. Urban, D. Tatang, M. Degeling, T. Holz, and N. Pohlmann, "Measuring the impact of the gdpr on data sharing in ad networks," in *Proceedings of the 15th ACM Asia Conference on Computer and Communications Security*, p. 222–235, 2020.

[22] M. Nouwens, I. Liccardi, M. Veale, D. Karger, and L. Kagal, "Dark Patterns after the GDPR: Scraping Consent Pop-ups and Demonstrating their Influence," in *ACM Conference on Human Factors in Computing Systems (CHI)*, 2020.

[23] Z. Liu, U. Iqbal, and N. Saxena, "Opted out, yet tracked: Are regulations enough to protect your privacy?," *Proceedings on Privacy Enhancing Technologies*, vol. 2024, pp. 280–299, 2024.

[24] Google, "Tag platform overview." https://developers.google.com/tag-platform/devguides (Consulted on June 12th 2023).

[25] BuiltWith® Pty Ltd, "Google Tag Manager Usage Statistics." https://trends.builtwith.com/widgets/Google-Tag-Manager (Consulted on March 26th 2025).

[26] M. Toth, N. Bielova, and V. Roca, "On dark patterns and manipulation of website publishers by CMPs," *Proceedings on Privacy Enhancing Technologies*, vol. 2022, pp. 478–497, July 2022.

[27] C. Santos, M. Nouwens, M. Toth, N. Bielova, and V. Roca, "Consent management platforms under the gdpr: processors and/or controllers?," in *Annual Privacy Forum (APF)*, 2021.

[28] I. Fouad, C. Santos, and P. Laperdrix, "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web," in *24th Privacy Enhancing Technologies Symposium (PETS 2024)*, vol. 2024, 2024.

[29] B. Krishnamurthy and C. E. Wills, "Privacy diffusion on the web: a longitudinal perspective," in *Proceedings of the 18th International Conference on World Wide Web, WWW 2009, Madrid, Spain, April 20-24, 2009* (J. Quemada, G. León, Y. S. Maarek, and W. Nejdl, eds.), pp. 541–550, ACM, 2009.

[30] Julius Fedorovicius, "Analytics Mania – Google Tag Manager and Google Analytics Blog." https://www.analyticsmania.com/ (Consulted on 24 Feb 2023).

[31] Simo Ahava, "Tags / Google Tag Manager." https://www.simoahava.com/tags/google-tag-manager/ (Consulted on 22 Feb 2023).

[32] Simo Ahava, "Agency, Transparency, And Control: Unsolved Problems With Server-side Tagging," Oct 2022. https://www.simoahava.com/analytics/agency-transparency-control-unsolved-problems-server-side-tagging/ (Consulted on 24 Feb 2023).

[33] "Pixel de tracking – Notes sur l'extension du domaine de la surveillance (personal website)." https://www.pixeldetracking.com/ (Consulted on 22 Feb 2023).

[34] P. de Tracking, "Google Tag Manager, the new anti-adblock weapon," Nov 2020. https://chromium.woolys.com/f/HTML-Google-Tag-Manager-the-new-anti-adblock-weapon.html (English translated version).

[35] J. Weber, *Practical Google Analytics and Google Tag Manager for Developers*. USA: Apress, 1st ed., 2015.

[36] R. Chardonneau, *Google Tag Manager – Optimisez Le Tracking De Votre Site Web*. FRA: Éditions ENI, 2015.
[37] T. Libert, "An Automated Approach to Auditing Disclosure of Third-Party Data Collection in Website Privacy Policies," in *Proceedings of the 2018 World Wide Web Conference*, WWW '18, (Republic and Canton of Geneva, CHE), pp. 207–216, International World Wide Web Conferences Steering Committee, Apr. 2018.

[38] N. Samarin, S. Kothari, Z. Siyed, O. Bjorkman, R. Yuan, P. Wi-jesekera, N. Alomar, J. Fischer, C. Hoofnagle, and S. Egelman, "Lessons in VCR Repair: Compliance of Android App Developers with the California Consumer Privacy Act (CCPA)," *Proceedings on Privacy Enhancing Technologies*, vol. 2023, no. 3, pp. 103–121, 2023.

[39] B. Andow, S. Y. Mahmud, J. Whitaker, W. Enck, B. Reaves, K. Singh, and S. Egelman, "Actions Speak Louder than Words: {Entity-Sensitive} Privacy Policy and Data Flow Analysis with {PoliCheck}," in *Proceedings of the USENIX Conference on Security Symposium*, pp. 985–1002, 2020.

[40] M. Tahaei, K. Vaniea, and N. Saphra, "Understanding privacy-related questions on stack overflow," in *Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems*, CHI '20, (New York, NY, USA), p. 1–14, Association for Computing Machinery, 2020.

[41] M. Tahaei, K. Vaniea, and A. Rashid, "Embedding privacy into design through software developers: Challenges and solutions," *IEEE Security & Privacy*, vol. 21, no. 1, pp. 49–57, 2023.

[42] M. Tahaei, T. Li, and K. Vaniea, "Understanding privacy-related advice on stack overflow," in *Proceedings on Privacy Enhancing Technologies*, pp. 1–18, 2022.

[43] Google, "Supported tags." https://support.google.com/tagmanager/answer/6106924 (Consulted on April the 17th 2024).

[44] Google, "Submit a template to the Community Template Gallery." https://developers.google.com/tag-platform/tag-manager/templates gallery (Consulted on June 28th 2023).

[45] Simo Ahava, "Custom Templates for Google Tag Manager." https://www.simoahava.com/custom-templates/ (Consulted on July 23, 2024).

[46] Simo Ahava, "Facebook Pixel - Custom Tag Template." https://www.simoahava.com/custom-templates/facebook-pixel/ (Consulted on October 2, 2024).

[47] Google, "About consent mode," 2024. https://support.google.com/google-ads/answer/10000067?hl=en, accessed on October 8, 2024.

[48] Google, "[ga4] consent types - analytics help," 2023. https://web.archive.org/web/20230602151919/https://support.google.com/analytics/answer/12334711, updated on June 2, 2023 and accessed via WayBack machine on 25 June 2024.

[49] Google, "[ga4] consent types - analytics help," 2024. https://support.google.com/analytics/answer/12334711, accessed on 25 June 2024. This URL was last updated on March 4, 2024, according to the WayBack machine snapshot accessible at https://web.archive.org/web/20240304180858/https://support.google.com/analytics/answer/12334711.

[50] E. Parliament and C. of the European Union, "Digital markets act - regulation (eu) 2022/1925 of the european parliament and of the council of 14 september 2022 on contestable and fair markets in the digital sector and amending directives (eu) 2019/1937 and (eu) 2020/1828 (digital markets act) (text with eea relevance)," 2022.

[51] European Data Protection Board, "Opinion 4/2007 on the concept of personal data (WP 136), adopted on 20.06.2007," 2007. https://ec.europa.eu/justice/article-29/documentation/opinionrecommendation/files/2007/wp136_en.pdf.

[52] E. D. P. B. (EDPB), "Working document 02/2013 providing guidance on obtaining consent for cookies, adopted on 2 october 2013." Available at https://www.pdpjournals.com/docs/88135.pdf, 2013.

[53] E. D. P. B. (EDPB), "Opinion 03/2013 on purpose limitation (wp 203)." Available at https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2013/wp203_en.pdf, 2013.

[54] E. D. P. B. (EDPB), "Opinion 04/2012 on Cookie Consent Exemption (WP 194)," 2012.

[55] I. Fouad, C. Santos, F. Al Kassar, N. Bielova, and S. Calzavara, "On Compliance of Cookie Purposes with the Purpose Specification Principle," in *Proc. International Workshop on Privacy Engineering (IWPE)*, 2020.

[56] C. of Justice of the European Union, "C-319/22 Scania case," Court of Justice of the European Union ECLI:EU:C:2023:837, Court of Justice of the European Union, 2023.

[57] C. of Justice of the European Union, "Case 582/14 – Patrick Breyer v Germany," Tech. Rep. ECLI:EU:C:2016:779, Court of Justice of the European Union, 2016.

[58] "Google Chrome Web Browser." https://flathub.org/apps/com.google.Crome.

[59] "Supplementary Materials." https://gitlab.inria.fr/web-smartphone-privacy/Google-Tag-Manager-Hidden-Data-Leaks-and-its-Potential-Violations-under-EU-Data-Protection-Law.

[60] W3C, "HTTP Archive (HAR) format." 2012. https://w3c.github.io/web-performance/specs/HAR/Overview.html (Consulted on March 26th 2024).

[61] GitHub, Inc., "Verifying or approving a domain for your organization." https://docs.github.com/en/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization (Consulted on October 30th 2023).

[62] B. Andow, S. Y. Mahmud, W. Wang, J. Whitaker, W. Enck, B. Reaves, K. Singh, and T. Xie, "Policylint: investigating internal privacy policy contradictions on Google play," in *Proceedings of the 28th USENIX Conference on Security Symposium*, SEC'19, (USA), pp. 585–602, USENIX Association, Aug. 2019.

[63] Google, "Announcement: Google tag and Tag Manager." https://support.google.com/tagmanager/answer/13543899 (Consulted on October 8th 2024).

[64] I. Wagner, "Privacy policies across the ages: Content of privacy policies 1996–2021," *ACM Trans. Priv. Secur.*, vol. 26, may 2023.

[65] DuckDuckGo, "DuckDuckGo Tracker Radar," 2020. https://github.com/duckduckgo/tracker-radar (Consulted on October 25th 2024).

[66] Google, "Google Tag Manager API - Overview." https://developers.google.com/tag-platform/tag-manager/api/v2 (Consulted on February 19th 2024).

[67] Google, "Puppeteer." https://pptr.dev/ (Consulted on March 26th 2024).

[68] Disconnect, "Disconnect," 2014. https://disconnect.me/trackerprotection (Consulted on October 25th 2024).

[69] Google, "Manage consent settings (web)." https://developers.google.com/tag-platform/security/guides/consent, accessed on June 24, 2024, WayBack machine version available at https://web.archive.org/web/20240624050926/https://developers.google.com/tag-platform/security/guides/consent?consentmode=advanced#tag-manager_1.

[70] Google, "Set up consent mode on websites." https://developers.google.com/tag-platform/security/guides/consent?consentmode=advanced#implementation_example (Consulted on April 17th 2024).

[71] Google, "Consent mode reference." https://support.google.com/analytics/answer/13802165 (Consulted on April 17th 2024).

[72] Google, "About consent mode modeling." https://support.google.com/google-ads/answer/10548233, accessed on June 3, 2024, and accessible via WayBack machine at https://web.archive.org/web/20240603092658/https://support.google.com/google-ads/answer/10548233.

[73] E. D. P. B. (EDPB), "Guidelines 2/2023 on technical scope of art. 5(3) of eprivacy directive.," 2024. https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf accessed on 17 October 2024.

[74] European Data Protection Board, "Opinion 4/2007 on the concept of personal data," 2007.
[75] B. Andow, S. Y. Mahmud, J. Whitaker, W. Enck, B. Reaves, K. Singh, and S. Egelman, "Actions speak louder than words: Entity-Sensitive privacy policy and data flow analysis with PoliCheck," in *29th USENIX Security Symposium (USENIX Security 20)*, pp. 985–1002, USENIX Association, Aug. 2020.

[76] European Court of Justice, "Case C-61/19 Orange România SA, ECLI:EU:C:2020:158," 2020. https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX%3A62019CC0061.

[77] C. of Justice of the European Union, "Judgment in case c-673/17 bundesverband der verbraucherzentralen und verbraucherverbände – verbraucherzentrale bundesverband ev v planet49 gmbh," 2019.

[78] UK DPA (ICO), "A guide to the data protection principles," 2023. https://ico.org.uk/media/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles-0-0.pdf (Consulted on February xxth 2024).

[79] "Privacy policy of Sharp Spring Website." https://sharpspring.com/ads/privacy/.

[80] "Privacy policy of Criteo Website." https://www.criteo.com/privacy/.

[81] European Court of Justice, "Case C-154/21, ECLI:EU:C:2023:3," 2023. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62021CJ0154.

[82] Google, "Consent mode on websites and mobile apps." https://support.google.com/analytics/answer/9976101, accessed on June 22, 2024, accessible via WayBack machine at https://web.archive.org/web/20240622212451/https://support.google.com/analytics/answer/9976101.

[83] "Decision [...] [...] ordering the company [...] to comply," 2020. https://www.cnil.fr/sites/cnil/files/atoms/files/decision_ordering_to_comply_anonymised_-_google_analytics.pdf.

[84] "Data protection complaint." https://noyb.eu/sites/default/files/2022-01/E-DSB%20-%20Google%20Analytics_EN_bk.pdf.

[85] European Court of Justice, "Google Spain vs Agencia Española de Protección de Datos (AEPD), Mario Costeja González (Google Spain) Case C-131/12, ECLI:EU:C:2014:317," 2014.

[86] European Court of Justice, "Nacionalinis visuomenès sveikatos centras Case C-683/21, ECLI:EU:C:2023:949," 2023.

# Appendix

## 1. Data Availability

Artifacts associated with this paper are available in a repository [59]. We provide the network traces used for our in-depth and automatic analysis and for the consent mode case study. We also provide the scripts to automate the collection the network traces with the explanation on how to configure and use them. The scripts to analyze the data produced are also provided. For our in-depth study, we provide a copy of the documentation used to determine data types that the companies declare to collect.

## 2. Cookies set by the Tags

Tables 7 and 8 list the cookies observed when studying Criteo OneTag and Perfect Audience Pixel within the automated study.

## 3. Responsible disclosure notifications

### 3.1. Disclosure issue. Dear Madam or Sir,

We are contacting you because you are listed in the imprint of the following service as the responsible party of company.

<table><caption>TABLE 7. COOKIES SET WHEN "CRITEO ONE TAG" TAG WAS INSTALLED ON OUR EMPTY EXPERIMENTAL WEBSITE.</caption><thead><tr><td>cookie name</td><td>cookie domain</td><td>duration (days)</td></tr></thead><tbody><tr><td>uid</td><td>.criteo.com</td><td>390</td></tr><tr><td>ayl politics</td><td>.omnitagis.com</td><td>30</td></tr><tr><td>CMID</td><td>.casalemedia.com</td><td>365</td></tr><tr><td>CMPS</td><td>.casalemedia.com</td><td>90</td></tr><tr><td>CMPRO</td><td>.casalemedia.com</td><td>90</td></tr><tr><td>receive cookie-deprecation</td><td>.adnxs.com</td><td>400</td></tr><tr><td>visitor-id</td><td>.media.net</td><td>365</td></tr><tr><td>data-c-ts</td><td>.media.net</td><td>30</td></tr><tr><td>data-c</td><td>.media.net</td><td>30</td></tr><tr><td>mv_tokens</td><td>exchange.mediavine.com</td><td>14</td></tr><tr><td>mv_tokens_eu-v1</td><td>exchange.mediavine.com</td><td>14</td></tr><tr><td>am_tokens</td><td>exchange.mediavine.com</td><td>14</td></tr><tr><td>am_tokens_eu-v1</td><td>exchange.mediavine.com</td><td>14</td></tr><tr><td>criteo</td><td>exchange.mediavine.com</td><td>14</td></tr><tr><td>demdex</td><td>.demdex.net</td><td>180</td></tr><tr><td>opt_out</td><td>.postrelease.com</td><td>365</td></tr><tr><td>dpm</td><td>.dpm.demdex.net</td><td>180</td></tr><tr><td>C</td><td>.adform.net</td><td>31</td></tr><tr><td>uid</td><td>.adform.net</td><td>60</td></tr><tr><td>tvid</td><td>.tremorhub.com</td><td>365</td></tr><tr><td>tv_UICR</td><td>.tremorhub.com</td><td>30</td></tr></tbody></table>

<table><caption>TABLE 8. COOKIES SET BY THE "PERFECT AUDIENCE PIXEL" TAG.</caption><thead><tr><td>cookie name</td><td>cookie domain</td><td>duration (days)</td></tr></thead><tbody><tr><td>pa_uid</td><td>.prfct.co</td><td>400</td></tr><tr><td>pa_twitter_ts</td><td>.prfct.co</td><td>400</td></tr><tr><td>pa_yahoo_ts</td><td>.prfct.co</td><td>400</td></tr><tr><td>pa_openx_ts</td><td>.prfct.co</td><td>400</td></tr><tr><td>pa_rubicon_ts</td><td>.prfct.co</td><td>400</td></tr><tr><td>pa_google_ts</td><td>.prfct.co</td><td>400</td></tr><tr><td>personalization_id</td><td>.twitter.com</td><td>400</td></tr></tbody></table>

During our research project, we identified practices regarding your Tag "Tag" that might not fully comply with the EU data protection law.

We analysed the Google Tag Manager platform, alongside the Tags provided through it. We found that the Tag "Tag" that you provide: i) collects data types without fully disclosing them in your legal documentation; and/or ii) sends data to third-parties without fully disclosing them in your legal documentation. Providing such a Tag without proper disclosure of data collected practices nor of the third-parties potentially infringes the law.

We believe there is a potential violation of Article 14(1)(d,e) and Recital 39 of the GDPR, as Data controller(s) must declare the categories of personal data they process, alongside purposes, recipients, risks and consequences for processing personal data. Such an infringement may be punishable by a fine in accordance with Article 83 GDPR.

The supervisory authorities can impose fines in case of violations of data protection law. These fines must be effective, proportionate and dissuasive in each individual case (cf. Art. 83 (1) GDPR). In the event of infringements of the principles governing processing pursuant to Article 14 (information obligations), fines of up to 20 million euros or, in the case of a company, up to 4% of the total annual worldwide turnover achieved in the previous financial year, whichever is the higher, may be imposed (Art. 83 para. 5(b) GDPR).

For full details about our findings and potential legal
violations, please refer to the sections 4.1 and 4.2 of
our paper available here: https://arxiv.org/pdf/2312.08806
Should you need further information or have any other
questions, please do not hesitate to contact us using the
same email address.

Sincerely,
Cristiana Santos
Utrecht University School of Law
Email address: c.teixeirasantos@uu.nl

**3.2. Consent mode issue.** Dear Madam or Sir,

We are contacting you because you are listed in the
imprint of the following service as the responsible party
of Google. During our research project, we identified
practices regarding your Tag "Google Tag" that might not
fully comply with the EU data protection law.

We analysed the Google Tag Manager platform, along-
side the Tags provided through it. We found that the
“Google Tag” that you provide collects data without user
consent. Your Tag still collects personal data through
cookieless pings without consent. Collecting user data
without consent potentially infringes the law. We believe
there is a potential violation of Art. 6(1)(a) of the GDPR.
Such an infringement may be punishable by a fine in
accordance with Art. 83 GDPR.

Supervisory authorities can impose fines in the event
of violations of data protection law. These fines must be
effective, proportionate and dissuasive in each individual
case (cf. Art. 83 (1) GDPR). In the event of infringements
of the principles governing processing pursuant to Art. 5
GDPR and Art. 6 GDPR (lawfulness of processing), fines
of up to 20 million euros or, in the case of a company, up
to 4

For full details about our findings and potential legal
violations, please refer to the section 4.3 of our paper
available here: https://arxiv.org/pdf/2312.08806
Should you need further information or have any other questions,
please do not hesitate to contact us using the same email
address.

Sincerely,
Cristiana Santos
Utrecht University School of Law
Email address: c.teixeirasantos@uu.nl
<figure><img src="image_6.png" /><figcaption>Figure 5. Dashboard of the Google Analytics service (Google Tag).</figcaption></figure>

<table><caption>TABLE 9. PARAMETERS FOUND IN THE URL PARAMETERS OR IN THE BODY OF HTTP REQUESTS TO THE HTTPS://REGION1.GOOogle-analYtics.cOm INITIATED BY THE GOOGLE TAG WHEN STUDYING GOOGLE CONSENT MODE V2 (SECTION 4.4) UNDER refuse all AND accept all CONDITIONS. THE DATA THAT IS IDENTICAL IN BOTH REQUESTS IS SHOWN IN BOLD. A FEW ADDITIONAL PARAMETERS WITH NO VALUE ARE NOT SHOWN IN THIS TABLE.</caption><thead><tr><th>Query parameters</th><th>Condition refuse all</th><th>Condition accept all</th><th>Type of data</th></tr></thead><tbody><tr><td>v</td><td>2</td><td>2</td><td></td></tr><tr><td>tid</td><td>G-XSKNFL9CWM</td><td>G-XSKNFL9CWM</td><td></td></tr><tr><td>gtm</td><td>45je43p0v9181346581za200</td><td>45je43p0v9181346581za200</td><td></td></tr><tr><td>_p</td><td>1711640211524</td><td>1711640309156</td><td></td></tr><tr><td>gcs</td><td>G100</td><td>G111</td><td></td></tr><tr><td>gcd</td><td>13p3p3p2p5</td><td>13t3t3t2t5</td><td></td></tr><tr><td>npa</td><td>1</td><td>0</td><td></td></tr><tr><td>dma_cps</td><td>-</td><td>sypham</td><td></td></tr><tr><td>dma</td><td>1</td><td>1</td><td></td></tr><tr><td>cid</td><td>1337464789.17116</td><td>1994365208.17116</td><td></td></tr><tr><td>ul</td><td>en-us</td><td>en-us</td><td>User language</td></tr><tr><td>sr</td><td>2560x1440</td><td>2560x1440</td><td>Screen resolution</td></tr><tr><td>uaa</td><td>x86</td><td>x86</td><td>Computer architecture</td></tr><tr><td>uab</td><td>64</td><td>64</td><td>Computer bitness</td></tr><tr><td>uafvl</td><td>Chromium%3B122.0.6261.94 ...</td><td>Chromium%3B122.0.6261.94 ...</td><td>User agent string</td></tr><tr><td>uamb</td><td>0</td><td>0</td><td></td></tr><tr><td>uap</td><td>Linux</td><td>Linux</td><td>Operating system</td></tr><tr><td>uapv</td><td>6.6.17</td><td>6.6.17</td><td>Operating system version</td></tr><tr><td>uaw</td><td>0</td><td>0</td><td></td></tr><tr><td>pscdl</td><td>denied</td><td>noapi</td><td></td></tr><tr><td>_s</td><td>2</td><td>2</td><td></td></tr><tr><td>sid</td><td>1711640211</td><td>1711640280</td><td></td></tr><tr><td>sct</td><td>1</td><td>1</td><td></td></tr><tr><td>seg</td><td>0</td><td>1</td><td></td></tr><tr><td>dr</td><td>https://ga4consent.example.com/consent 0000.html</td><td>https://ga4consent.example.com/consent 1111.html</td><td>Page url</td></tr><tr><td>dt</td><td>My experiment page title</td><td>My experiment page title</td><td>Page title</td></tr><tr><td>en</td><td>view_search_results</td><td>view_search_results</td><td></td></tr><tr><td>tfd</td><td>5620</td><td>5613</td><td></td></tr><tr><td>_eu</td><td>AEA</td><td>AEA</td><td></td></tr><tr><td>_et</td><td>2</td><td>1</td><td></td></tr><tr><td>ep.search_term</td><td>my%20search</td><td>my%20search</td><td>Search keyword</td></tr></tbody></table>
<table><caption>Figure 6. The Top 50 third party domains present on the top 1M websites (from [14] with the company owning the domain and corresponding Tags we identified.</caption><thead><tr><th>Rank</th><th>Third-party domains</th><th>Prevalence</th><th>Domain owner</th><th>Tag found in GTM</th><th>Tag Provider</th><th>Tag provider is the Data Recipient (domain owner)</th></tr></thead><tbody><tr><td>1</td><td>google-analytics.com</td><td>65.22%</td><td>Google LLC</td><td>Google Tag</td><td>Google LLC</td><td>yes</td></tr><tr><td>2</td><td>doubleclick.net</td><td>62.7%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>3</td><td>google.com</td><td>58.31%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>4</td><td>googletagmanager.com</td><td>49.21%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>5</td><td>google.fr</td><td>48.75%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>6</td><td>gstatic.com</td><td>41.74%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>7</td><td>fonts.googleapis.com</td><td>31.5%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>10</td><td>googlesyndication.com</td><td>20.75%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>11</td><td>googletagservices.com</td><td>19.66%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>14</td><td>googleadservices.com</td><td>11.88%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>19</td><td>jax.googleapis.com</td><td>9.31%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>29</td><td>youtube.com</td><td>7.45%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>33</td><td>2mdn.net</td><td>6.6%</td><td>Google LLC</td><td></td><td></td><td></td></tr><tr><td>8</td><td>facebook.net</td><td>30.16%</td><td>Facebook, Inc.</td><td>Facebook pixel (template gallery)</td><td>https://github.com/sahava</td><td>no</td></tr><tr><td>9</td><td>facebook.com</td><td>28.53%</td><td>Facebook, Inc.</td><td></td><td></td><td></td></tr><tr><td>12</td><td>adnxs.com</td><td>12.58%</td><td>Microsoft Corporation</td><td></td><td></td><td></td></tr><tr><td>22</td><td>bing.com</td><td>8.2%</td><td>Microsoft Corporation</td><td></td><td></td><td></td></tr><tr><td>46</td><td> linkedin.com</td><td>5.29%</td><td>Microsoft Corporation</td><td>LinkedIn Insight</td><td>Microsoft Corporation</td><td>yes</td></tr><tr><td>48</td><td>liicdn.com</td><td>4.87%</td><td>Microsoft Corporation</td><td></td><td></td><td></td></tr><tr><td>13</td><td>cloudflare.com</td><td>12.11%</td><td>Cloudflare, Inc.</td><td>Cloudflare Web Analytics (template gallery)</td><td>https://github.com/yuhui</td><td>no</td></tr><tr><td>15</td><td>twitter.com</td><td>10.5%</td><td>Twitter, Inc</td><td>Twitter Base Pixel (template gallery)</td><td>Twitter, Inc</td><td>yes</td></tr><tr><td>45</td><td>t.co</td><td>5.37%</td><td>Twitter, Inc</td><td></td><td></td><td></td></tr><tr><td>16</td><td> criteo.com</td><td>10.32%</td><td>Criteo SA</td><td>Criteo OneTag - Official</td><td>Criteo SA</td><td>yes</td></tr><tr><td>32</td><td> criteo.net</td><td>6.72%</td><td>Criteo SA</td><td></td><td></td><td></td></tr><tr><td>17</td><td>alexametrics.com</td><td>10.32%</td><td>Amazon Technologies, Inc.</td><td></td><td></td><td></td></tr><tr><td>28</td><td>amazon-adsystem.com</td><td>7.51%</td><td>Amazon Technologies, Inc.</td><td>Amazon Advertising Tag (template gallery)</td><td>https://github.com/amzn</td><td>no</td></tr><tr><td>18</td><td>scorecardresearch.com</td><td>10.1%</td><td>comScore, Inc</td><td>comScore Unified Digital Measurement</td><td>comScore, Inc</td><td>yes</td></tr><tr><td>20</td><td>adsrvr.org</td><td>9.16%</td><td>The Trade Desk Inc</td><td></td><td></td><td></td></tr><tr><td>21</td><td>quantserve.com</td><td>8.59%</td><td>Quantcast Corporation</td><td>Quantcast Advertise</td><td>Quantcast Corporation</td><td>yes</td></tr><tr><td>23</td><td>casalemedia.com</td><td>8.15%</td><td>Index Exchange, Inc.</td><td></td><td></td><td></td></tr><tr><td>24</td><td>rubiconproject.com</td><td>7.93%</td><td>Magnite, Inc.</td><td></td><td></td><td></td></tr><tr><td>25</td><td>everesttech.net</td><td>7.68%</td><td>Adobe Inc.</td><td></td><td></td><td></td></tr><tr><td>30</td><td>demdex.net</td><td>6.98%</td><td>Adobe Inc.</td><td></td><td></td><td></td></tr><tr><td>26</td><td>pubmatic.com</td><td>7.65%</td><td>PubMatic, Inc.</td><td></td><td></td><td></td></tr><tr><td>27</td><td>hotjar.com</td><td>7.58%</td><td>Hotjar Ltd</td><td>Hotjar Tracking Code</td><td>Hotjar Ltd</td><td>yes</td></tr><tr><td>31</td><td>yahoo.com</td><td>6.83%</td><td>Verizon Media</td><td>yahoo dot pixel (template gallery)</td><td>https://github.com/yahoo</td><td>no</td></tr><tr><td>34</td><td>openx.net</td><td>6.57%</td><td>OpenX Technologies Inc</td><td></td><td></td><td></td></tr><tr><td>35</td><td>jsdelivr.net</td><td>6.14%</td><td>Prospect One</td><td>jsDelivr (template gallery)</td><td>https://github.com/luratic</td><td>no</td></tr><tr><td>36</td><td>ads-twitter.com</td><td>6.14%</td><td>Twitter, Inc</td><td></td><td></td><td></td></tr><tr><td>37</td><td>newrelic.com</td><td>6.01%</td><td>New Relic</td><td></td><td></td><td></td></tr><tr><td>38</td><td>cookielaw.org</td><td>5.92%</td><td>OneTrust LLC</td><td></td><td></td><td></td></tr><tr><td>39</td><td>yandex.ru</td><td>5.87%</td><td>Yandex LLC</td><td>Yandex Metrica</td><td>https://github.com/antoniolite</td><td>no</td></tr><tr><td>40</td><td>rlcdn.com</td><td>5.85%</td><td>LiveRamp Holdings, Inc.</td><td>LiveRamp (template gallery)</td><td>LiveRamp Holdings, Inc.</td><td>yes</td></tr><tr><td>41</td><td>nr-data.net</td><td>5.82%</td><td>New Relic</td><td></td><td></td><td></td></tr><tr><td>42</td><td>baidu.com</td><td>5.6%</td><td>Baidu, Inc.</td><td></td><td></td><td></td></tr><tr><td>43</td><td>consensu.org</td><td>5.57%</td><td>IAB Europe</td><td></td><td></td><td></td></tr><tr><td>44</td><td>dnacdn.net</td><td>5.4%</td><td></td><td></td><td></td><td></td></tr><tr><td>47</td><td>onetrust.com</td><td>5.16%</td><td>OneTrust LLC</td><td></td><td></td><td></td></tr><tr><td>49</td><td>quantcount.com</td><td>4.68%</td><td>Quantcast Corporation</td><td></td><td></td><td></td></tr><tr><td>50</td><td>adform.net</td><td>4.65%</td><td>Adform A/S</td><td></td><td></td><td></td></tr></tbody></table>