A circular puzzle of Google Analytics bar chart logomark.

GA4 Guide Chapter 10: Managing User Privacy in GA4

Cory Underwood
CIPT, CIPP/US, Analytics Engineer
Sep 13, 2022

Data privacy is a growing concern for businesses of all sizes. The world saw the enforcement of Europe’s General Data Protection Regulation begin in 2018, and a mere two years later, we saw the arrival of California’s Consumer Privacy Act. As we approach 2023, we see an additional five state laws pending enforcement. Each of these regulations alters what data may be collected and what processes are required for collection and use.

Data privacy’s complexities aren’t confined to regulation. New technology changes such as Apple’s Intelligent Tracking Prevention, or Mozilla’s Enhanced Tracking Protection alter what data can be collected and tinker with what used to be stable cookie durations, causing downstream effects on all manner of reporting.

Google Analytics 4 seeks to address these concerns with a number of controls for the data affected by technology changes, while also allowing organizations to comply with the various regulatory requirements they may be subject to.



Google’s stance on data collection has been evolving in recent years and has begun to shift. At the 2021 Google Marketing Live conference, Vidhya Srinivasan, VP/GM of Advertising at Google, said the following:

The principles we outlined to drive our measurement roadmap are based on shifting consumer expectations and ecosystem paradigms. Bottom line: The future is consented. It’s modeled. It’s first-party. So that’s what we’re using as our guide for the next gen of our products and solutions.

That mindset is reflected in the changes Google has made to GA4. They’ve developed technologies such as Consent Mode, and built deep integrations to Google Signals and data modeling features into GA4 to account for the loss of signal caused by technology or consent choices.


Depending on the region a website is operating in, additional agreements to the default Terms of Service may be recommended or required, such as the Data Processing Agreement.

Data Processing Agreement
For example, under account settings, you will find details on the Data Processing Agreement.

Data Processing Agreement

This agreement should be reviewed by a website operator’s legal counsel. It specifies the relationship between the Analytics account holder and Google in regard to data processor and data controller designations used by Europe’s General Data Protection Regulation and California’s Consumer Privacy Act. As such, the acceptance of these terms and conditions may be required by law in certain jurisdictions. In addition to accepting the terms, a website has to specify the information that would be provided to a data protection authority. This includes specific details, including the legal entities involved and the primary contact information for the analytics account, such as Name, Email Address, Mailing Address, and Role.

Note: Several States are slated to begin enforcing data privacy laws in 2023. Even if the use cases in the Data Processing Agreement do not apply to you now, you’re encouraged to review the terms periodically as they apply to your website’s specific scenario.

User Data Collection Acknowledgement
Google Analytics 4 administrators are also required to acknowledge they have properly disclosed and have consent to collect user data.

User Data Collection Acknowledgement


This new privacy-first world forces a revaluation of what has come before. Recent changes to regulation and even Google’s default Terms of Service have forced brands to review what their website may already have in place, such as an existing Privacy Policy.

General Requirements
By default, without the optional features, using Google Analytics comes with various requirements, such as disclosing to the end user the use of GA and how it collects and processes data. The exact details of what should be included in the privacy policy are split between two links: Google’s support page and advice on “Safeguarding your data.” Combined, the pages highlight the requirements for a website’s privacy policy, including (but not limited to):

  • Which cookies and identifiers Google Analytics uses
  • Information on the Data Processing Agreement
  • The data collected by Google Analytics
  • International Data Transfers
  • What the data is used for
  • Who has access to the data under specific scenarios
  • Data retention practices
  • User Deletion information
  • User-level Data Access and Portability
  • Advertising personalization information
  • Data privacy and security compliance information

In addition to the above, specific regulations may require more information than what is presented above, and Google’s Terms of Use are in addition to whatever may be required under the law.

Advertising Requirements
Use of certain features of Google Analytics (such as Google Signals and Interest Based Advertising) may require additional disclosures and requirements. Google makes these clear in the Policy requirements for Google Analytics Advertising Features support page. Notably, this requires sites to abide by the following:

This means you will not identify users or facilitate the merging of personally identifiable information with additional information collected through any Google advertising product or feature unless you have robust notice of, and the user’s prior affirmative (i.e., opt-in) consent to, that identification or merger, and are using a Google Analytics feature that expressly supports such identification or merger. Irrespective of users’ consent, you must not attempt to disaggregate data that Google reports in aggregate. Source

You are also required to disclose which advertising features have been enabled, which identifiers are used, and how visitors can opt out.

It is recommended that users discuss the required updates with their legal team, as the Privacy Policy is used by data protection authorities as the baseline against which to judge the site behavior.

For example, if you do not properly declare sharing of data with Google Analytics, you may be in legal violation in some regions. It is strongly recommended that the stated behavior in the Privacy Policy reflects the actions a site takes, as misalignment increases legal risk in multiple regions.



To best explain GA privacy-related legal risks in Europe, some context is required. Let’s rewind the clock a few years to understand the current state of things.

Back in May 2018, Europe began enforcing GDPR (General Data Protection Regulation). This expansive set of rules for the governance of personal data forced a number of changes on the Internet, particularly in regard to international data transfers (such as those common to GA data processing).

In response to this, the United States and Europe reached an agreement known as the Privacy Shield, which would enable international data transfers between the European Union and the United States to continue.

Not everyone agreed with that state of affairs, however, and a non-profit organization challenged the agreement in court. In the summer of 2020, the Court of Justice of the European Union ultimately agreed with the challenger, citing overly-broad United States surveillance laws to nullify the agreement. As a result, the United States lost its data-adequacy designation, which changed the requirements involved for international data transfers under the GDPR. The court left open whether Standard Contractual Clauses (SCCs) were sufficient to transfer in light of this change.

In response to the nullified agreement, the non-profit NOYB (None of Your Business) filed 101 GDPR complaints with multiple data protection authorities in multiple countries. Google Analytics was listed in several of these complaints as partaking in unlawful data transfer under GDPR. They argued that SCCs were insufficient to allow for data transfer to a country lacking a data adequacy designation.

Google, for its part, argued that the Terms of Use users had agreed to SCCs, which allowed the international data transfer to take place, and that it had technical and organizational mitigation measures in place to ensure data privacy.

Beginning in January 2021, these complaints started to be resolved. Data Protection Authorities in Austria, France, Italy, and Denmark ultimately concluded that in light of the United States surveillance laws, SCCs were insufficient to ensure data privacy when data had been transferred to the United States. They further argued that while Google had mitigation measures in place, it could still be compelled by the United States government to turn over data. As a result, it was found to be unable to offer an equivalent level of data protection as the GDPR requires.

As such, websites subject to GDPR that use Google Analytics are likely in violation of GDPR and may be subject to enforcement action, particularly in the countries which have already issued adverse decisions. France, for example, argued that French websites should immediately cease use of the client-side integration of Google Analytics, but left the door open for a possible proxy implementation (via a Proxy Gateway, see sidebar).

The use of a proxy service dramatically increases the complexity of using Google Analytics 4. France has multiple requirements for what it must do, and how it must be hosted.

As such, websites subject to GDPR that use Google Analytics are likely in violation of GDPR (particularly in the countries which have already issued adverse decisions) until a new data privacy agreement is in place between the United States and Europe. Although GDPR violations are known to come with heavy fines, no companies have paid fines for using Google Analytics in Europe to date.

Because this is effectively a state-level dispute between the European Union and the United States, there is nothing Google can do to address this. However, following the fallout of the Data Protection Authorities issuing judgments that impact US businesses, the United States moved to reach an agreement “in principle” between the two regions in what is known as the Trans-Atlanic Data Privacy Framework. Should the agreement ultimately be reached, data flows between the two regions could legally resume.

This announcement prompted the non-profit NYOB to write an open letter in response. The letter states that depending on the final text of the agreement and what changes the United States may make, they may challenge the agreement in court.


This depends on your technical architecture involved, the settings of features which may be enabled in Google Analytics, how your Consent Banners work, and what specific data you may be capturing. We strongly recommend reviewing concerns with legal counsel to determine risk and any response, should one be needed, depending on your specific scenarios.

Data Collection in Europe
Google now requires data collection from the European Union to be in alignment with the EU User Consent Policy. This policy requires a website to legally obtain valid consent regarding cookie use or other local storage (where legally required) and that they have consent for the collection, sharing, and use of personal data for ad personalization. Websites are also required to retain records of consent given by end-users and provide users with instructions for how they can revoke consent.

Lastly, analytics data collection is not considered a “legitimate interest” by the various data protection authorities of Europe, and explicit user consent is required for analytics data collection in the majority of cases. So websites operating in Europe are required by both law and policy to obtain consent prior to sending data to Google Analytics.

Data Processing Location
If a website uses Content Security Policies, it will be required to add allowance for the following connections to ensure that the outbound network calls can reach the new data center collection points.

  • *.google-analytics.com
  • *.analytics.google.com

Here’s a brief overview of what effect disabling a feature for a region has:

Google Signals Data – Google Signals is disabled by default. However, modeling data is a key feature of Google Analytics 4, and disabling it once enabled has the following effects:

  • Loss of Cross-Platform reporting
  • Loss of Remarketing Lists based on Analytics Data
  • Loss of Advertising Reporting Features
  • Loss of Demographics and Interests reports
  • Remarketing is disabled for affected regions
  • Cross-Device and Engaged-view conversions modeling volume is significantly reduced
  • Downstream conversion modeling and reporting in linked Google Ads accounts is reduced.

Location and Device Data – Location and Device data is enabled by default. Turning off location data will remove the following from reporting:

  • City
  • Latitude (of city)
  • Longitude (of city)
  • Browser minor version
  • Browser User-Agent string
  • Device brand
  • Device model
  • Device name
  • Operating system minor version
  • Platform minor version
  • Screen resolution

Historical data is not affected; this is a forward-only change.

Note: While these controls are welcomed, they do not, on their own, make Google Analytics compliant with GDPR. They do, however, assist in data minimization efforts (i.e., they collect fewer data).



By enabling Google Signals, you enhance a number of features in Google Analytics for users who have left Ads Personalization enabled in their Google Account. Note that Ads Personalization being enabled is the default setting, which means, unless the user has specifically turned it off, it will be enabled.


Remarketing audiences that are created and pushed to other platforms can serve ads in Cross-Device eligible remarketing campaigns. Analytics creates separate custom models for ecommerce transactions and goal completions based on the cross-device conversion data from users who are signed in to Google accounts with Ads Personalization enabled.

Note: This feature is required to populate audiences to send downstream to Youtube.

Advertising Reporting
Analytics will collect additional data about users who have left Ads Personalization enabled.

Demographic and Interest Reports
Analytics will collect additional data about users who have left Ads Personalization enabled.

Cross-Device Support
Based on aggregated data from users who have Ads Personalization enabled, Analytics will model behavior for your whole user base across device types. This data is user-based, rather than session-based and does not require User-ID enabled views.


Cross-Device activity includes the following Google Signals data when logged into a Google Account.

  • iOS devices (for iOS13 and below)
  • Android Devices
  • Google Chrome (Chromebooks)
  • Google Chrome (Web browser)
  • Other Web Browsers
  • Client apps that require a Google Account
  • Other apps that require a Google Account

However, for data to be included for your property, your property requires a monthly average of 500 users per day.


Google Signals data is persisted for 26 months or a specified duration, whichever is shorter.


Google Signals data can not be:

  • Exported via BigQuery
  • Used in Dashboards
  • Used in Custom Reporting
  • Used in Custom Tables
  • Used in User-ID Views
  • Used in Segments related to Cross-Device Reports

Additionally, when enabled:

  • Cross-Device reports do not display intraday data
  • Data is not accessible via the Reporting API
  • Data is not available in Data Studio
  • Data is not available in Smart Lists.


Activation of the feature may, in some cases, result in an increase in regulatory compliance efforts. For example, according to the forthcoming state laws slated for 2023, enabling Google Signals and changing Google Analytics to be part of the targeted advertising tool chain may alter consent requirements prior to data collection. This may affect a site’s consent management and related integration efforts for organizations subject to the regulation.

Users may not be aware that being logged into Google (directly or indirectly via Chrome / Android) may alter what advertising they are shown. Users do have the power to adjust these settings, but it’s likely that most users are unaware that this is possible.

Data collected is not shared with Google (for their purposes) unless you have linked Products via the Analytics Admin Panel, or have enabled Data Sharing settings in the configuration. An organization will be prompted to review their data sharing settings as part of the enablement of Google Signals.

As user-level data is not shared with the organization, the organization can not provide what data may have been shared as part of a Data Subject Access Request. The organization remains limited to what is available in the BigQuery export. Users can see what data may have been used in their own Google Account profile.

Before you activate Google Signals, we recommend consulting with legal counsel for your specific scenarios to ensure that no additional legal risk is incurred by activating Google Signals.


At the time of publishing, Google Signals can not be enabled for GA4 deployed via Server-Side Google Tag Manager installations. If you intend to use Google Signals data for GA4 reporting features, then GA4 must be deployed via a client-side integration.


Consent Mode is a feature developed by Google to enhance data collection and data modeling in scenarios where the placement of cookies may be undesired due to regulatory requirements. The setting is often adjusted in the tag management platform (such as Google Tag Manager).


How Consent Mode modifies data collection for Google Analytics 4 varies depending on which configuration mode it executes in.

Default Configuration
By default, consent options are assumed to be granted. This means everything works “normally” as if no consent framework was in place. Note, that depending on the regulation you are subject to, the default may be the opposite of what you want. Analytics cookies are written and read, and the full default data collection hit (and related cookies) are sent to Google for processing.

Analytics Storage – Denied
If a user, via a consent platform, denies consent, Google will continue to receive beacon pings when analytics_storage is denied unless ‘Additional Checks’ is enabled (see below). These pings (for consent status pings, conversion pings, and Google Analytics pings) will include the following information:

  • Timestamp
  • User Agent (web only)
  • Referrer
  • The current consent state
  • A random number on each page load
  • Information on the consent platform used by the site owner
  • An indication of whether the current page or a prior page in the user’s navigation on the site included ad-click information in the URL (e.g., GCLID / DCLID)

Additionally, Analytics Behavior is modified as follows.


  • Analytics cookies may not be written or read
  • Beacons will not include cookies, but will still be sent to Google Analytics. GA4 may use these beacons for data modeling (depending on the reporting identity selected in the propertyconfiguration)

Mobile Apps:

  • Events without device or user IDs will be collected. GA4 may use these beacons for data modeling (depending on the reporting identity selected in the property configuration).

Additional Checks Behavior
If the analytics tag has Additional Checks enabled for analytics_storage, then no network traffic will be sent when analytics_storage is denied. This means the data will not be captured for modeling purposes and total data loss will occur because the tag will never fire.

Privacy Concerns
Depending on the regulations in question, It’s possible some courts or authorities may determine that even the minimized data collected when storage is restricted is unlawful to collect without explicit consent of the user. It’s up to the deploying website to determine if Consent Mode is viable, given the specific regulatory requirements they may be subject to.


In recent years, thanks to various privacy laws , consumers have gained a number of rights to what they can do with their data. These rights vary by law, but commonly consumers have rights to know what data is collected, the limits on or purpose of the data collected, and the conditions that, when met, can lead to their data being deleted, to name a few. Collectively, a consumer exercising these rights is referred to as having created a Data Subject Access Request, or DSAR, for short.

Commonly, when an organization receives a DSAR, they are required to respond to that request in a specific period as defined by law. As part of a DSAR request, an organization may be required to provide data from GA4 or delete data from GA4, as required by the request and law in question. You should consult with your legal counsel to determine what data may be disclosed/deleted upon fulfillment of a DSAR.

Warning: Data Deletion is not reversible.


Deleting data from GA4 has a number of considerations that need to be accounted for.

To use GA4’s Data Deletion feature, you require editor-level access to the property. Data Deletion requests can be executed by following the directions on the support page. This feature can enable you to:

  • Delete all parameters on all events
  • Delete all registered parameters on selected events
  • Delete selected parameters on all events
  • Delete selected registered parameters on selected events
  • Delete selected user properties.

It should be noted that there is a considerable time delay in the processing of these requests, which may present challenges under various regulatory circumstances. Data deletion can take between 7 and 63 days to fully process. You’ll want to ensure that you begin the process early enough that you satisfy legal requirements for how quickly the deletion must take place.

Deletion Impact on Attribution
Deletions may cause attribution changes. For example, if the user elects to delete data that contains campaign information, then it won’t be available for attribution. In this scenario, if the user later decides to purchase, the attribution for the conversion will likely be ‘Direct’.

Consent Mode Considerations
If you are also leveraging Consent Mode for data collection (as outlined above), you will need to add seven days to the end date of the deletion request to account for Consent Mode’s data modeling. This will ensure the data slated for deletion is also removed from behavioral models that were trained on data sets containing the data to be deleted.

Sub Property Concerns
Data deleted from the source property will also be deleted from the subproperties. However, if data is deleted at the subproperty level, it is only deleted from the subproperty.

You will need to ensure that you are deleting data at the right level for your compliance scenario.

Roll-Up Property Concerns
Data deleted from the source property will also be deleted from the roll-up property. However, if data is deleted at the roll-up property level, it is only deleted from the roll-up property.

You will need to ensure that you are deleting data at the right level for your compliance scenario.


Often a DSAR will require disclosure or deletion of a specific user or anonymous ID. This is a slightly different process, which is detailed in the support documentation.

In the UI
Data deleted this way will stop displaying in 24 hours, but it may take up to 63 days to be removed from the underlying data tables.

You will need to create a segment for the user using the Explorer feature as described in the documentation. However, there are a few important call-outs to be aware of.

First, and perhaps most importantly, Google Analytics does not create a map between the User ID (which is only sometimes set) and the anonymous device ID that the individual user has been issued. This means that if you delete the User ID information, that data collected when that user was not logged in won’t be removed as expected, as there is no mapping to refer to behavior that was observed when no user ID was present.

If the intention is to delete all the data the user may have generated (as is the common case), it will be up to the website to develop a method to handle this mapping so that it may be used when serving DSAR requests.

If an organization wants to handle User Deletions programmatically (such as by API), Google offers the User Deletion API which may be used for this purpose. The use of the API is beyond the scope of this guide, but there are a few considerations to call out.

The User Deletion API has quota limits. You will need to ensure that your service does not exceed these limits and can gracefully handle scenarios where the quota may have been exceeded.

The API will take a single identifier (Client ID [device id], User ID, or APP Instance ID) and issue a deletion request for it. If you need to delete multiple identifiers, they must be issued as separate requests.

Deletion Time Frame
Once the data request is received by Google, data is removed from the Individual User Reports within 72 hours. It’s then slated for the next deletion process. These processes occur approximately once every two months.

You’ll want to ensure that you begin the process early enough that you satisfy legal requirements for how quickly the deletion must take place.


Data is often sent from Google Analytics to BigQuery, then onwards to multiple downstream systems. Depending on the regulation, you may also be required to develop processes to delete data from the BigQuery table(s) and any downstream system which may have ingested the data.

We advise you to consult legal counsel to determine which data is covered under DSARs and ensure that deletion occurs in each system where it is required.


Data Retention is heavily modified from Universal Analytics. In Universal Analytics, the configuration could be set to persist data indefinitely. This is not the case with GA4, which limits data persistence to either 2 months or 14 months in GA4’s free offering, and up to 50 months in GA4 360.

In the event you need to persist data for longer than those timeframes, you will need to export it to BigQuery for storage.

The duration of data persistence may be governed by law, and may vary depending on jurisdiction and regulatory requirements. You should align data persistence with your overall data governance strategy, while factoring in legal requirements.

Cory Underwood
CIPT, CIPP/US, Analytics Engineer

Cory Underwood is a certified data, analytics, and security expert with more than a decade of experience leading strategies across website development, optimization, and data compliance. As Senior Lead Analytics Engineer at Further, he develops security and privacy strategies for both the internal team and our clients. Cory is dedicated to teaching others the value of data through his blog and numerous speaking engagements. In his free time, Cory can be found playing video games, cooking delicious BBQ meals, or practicing his woodworking.


Read More Insights From Our Team

View All

Take your company further. Unlock the power of data-driven decisions.

Go Further Today