Skip to content

Consent Mode and Google Analytics 4

With the rollout of Google Analytics 4, the recent addition of Consent Mode Debugging to Google Tag Manager and the start of enforcement of the EU consent policy, I’ve been seeing some discussion on consent mode and what that means for Google’s data collection. I hope to highlight some concerns I have regarding the feature when I consider how it behaves against how different regulations and technical policies are tracking.

Before we begin

A lot of users believe (and I can’t blame them) that consent mode means that it is a legally viable consent solution offered by Google for the various regulations one may need to comply with.  In truth, it may be, but there are things that consent mode does which are not immediately obvious, and which may ultimately have legal ramifications under various legal frameworks.   I strongly encourage anyone considering consent mode to speak with their legal team to ensure that the behavior of the functionality aligns with whatever regulation & policies you may be subject to.

Consent Mode Behavior

For Google’s tags, consent mode modifies the behavior of Google Ads, Floodlight tags and Google Analytics.  Users, via a consent management platform, will have the ability to conditionally approve or deny access to ad_storage and analytics_storage and thus affect how the Google tags operate.

You would be forgiven if you assumed that a user who denied access, would result in no data being collected.  However, you need to know that data is collected from those who do not consent, it’s just modified during the collection and processing phases.    

If you were legally bound to not send any data to Google when consent was denied, then consent mode isn’t a viable solution.  

Google will continue to receive beacon pings when ad_storage and analytics_storage is denied.  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 for whether or not 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)

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.

Web:

  • Advertising Cookies may be written or read
  • IP Addresses are collected
  • The full web page URL is accessible
  • 3rd party cookies are accessible for browsers that support them

Mobile Apps:

  • Advertising IDs are available (assuming consent has been granted (iOS / Android)
  • The app-instance ID generated is collected

Now let’s take a look at what happens when a user denies access to one of the storage types and what effect that has on the data collection.

Ad Storage Denied

Web:

  • Advertising Cookies may not be written or read
  • IP Addresses are collected and used for Google Ads Geo-lookup to derive IP Country, but are not logged and immediately deleted.  Google Analytics 4 will collect IP Address as per the analytics configuration
  • Google Analytics will not read / write cookies and Google Signals will not record data for this traffic
  • The full web page URL is accessible but will only be used to approximate accurate traffic measurement
  • Requests are sent through different domains to avoid reading previously set 3rd party cookies

Mobile Apps:

  • Advertising IDs are unavailable
  • Google Signals will not record data for this traffic
  • IP Addresses are collected and used for Google Ads Geo-lookup to derive IP Country, but are not logged and immediately deleted.  Google Analytics 4 will collect IP Address as per the analytics configuration

Ad Storage Denied and Redacted

Web:

  • Advertising Cookies may not be written or read
  • IP Addresses are collected and used for Google Ads Geo-lookup to derive IP Country, but are not logged and immediately deleted.  Google Analytics 4 will collect IP Address as per the analytics configuration
  • Google Analytics will not read / write cookies and Google Signals will not record data for this traffic
  • The full web page URL is accessible but will only be used to approximate accurate traffic measurement
  • Requests are sent through different domains to avoid reading previously set 3rd party cookies
  • Ad-Click identifiers in consent and conversion beacons are redacted
  • Page URls with ad-click identifiers are redacted

Analytics Storage Denied

Web:

  • Analytics cookies may not be written or read
  • Beacons will not include cookies, but will still be sent to Google Analytics.  Google Analytics 4 will use these beacons for data modeling
  • Google Optimize is not affected by this setting

Mobile Apps:

  • Events without device or user ids will be collected.  Google Analytics 4 will use these beacons for data modeling

As you can see, even if both ad_storage and analytics_storage are denied, Google obtains quite a bit of data from the user.   Depending on the regulations in question, I have to ponder if some courts or authorities may determine that even this data is unlawful.  Certainly the recent decisions by Austria call a lot of this into question and that’s not even addressing the issue of international data transfers that would still occur even if consent was denied.

Would just the IP Address, Referrer and Page URL be considered personal data?  It’s possible.  It will be very context dependent. Certainly, some developers pass personal data in the URL’s query string (against best practices), and in these instances, the data is still collected and parsed and the data is personal.   So again, I urge a review by legal counsel to avoid surprises later on should the website come under investigation.

Data Modeling

I feel it’s important to touch on the data modeling aspect of Google Analytics 4 when discussing consent mode. Google has this to say on Data Modeling:

Core reports (such as the Event, Conversions, and Attribution reports) and Explorations where you can select event-scoped dimensions will include modeled data. These reports automatically attribute conversion events across channels based on a mix of observed data where possible and modeled data where necessary.   

https://support.google.com/analytics/answer/10710245

A non-exhaustive list of scenarios which may incur modeling include:

  • Browsers that block 3rd party cookies (in practical terms most browsers restrict or block 3rd party cookies).
  • Browsers that limit the duration of first party cookies (such as those browsers affected by Intelligent Tracking Prevention).
  • The use of consent mode, denied consent results in modeled conversions.
  • App Tracking Transparency is in force.
  • Cross Device conversion scenarios

It is important to note that modeled data can be updated for upwards of 7 days after the conversion is recorded.  This makes the data a bit more tricky to work with and analysts who are using Google Analytics 4 need to be made aware of this before incorporating modeled data into their analysis or reporting.

This also means any time you rely on conversions for sending data to other platforms (such as Google Ads) the data may be modeled.  This may affect targeting or segmentation selection on those platforms because the model is operating on probabilistic assumptions rather than deterministic actions.

Google says the models are built on historical conversion rates, device type, time of day, geo and other factors, but not fingerprint ids.  With that said, I do question how this fits legally into the various regulations that allow people to opt out of modeling.  If you take the strict stance that opting out of modeling means no data is used for modeling, then consent mode isn’t viable, and you’d have to rely on the consent manager and tag manager integration to prevent the tag from executing entirely.   It’s important to consider this factor of when modeling happens and what users can legally opt out of under various regulations.  You are best off conferring with your legal team to determine how consent mode’s behavior applies to your specific use cases.  

Legal/Policy 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 a is unlawful to collect without explicit consent of the user.

We also have to consider if the data is personal (which means GDPR could apply) if a Data Protection Authority would consider the international data transfer (we know Google Analytics sends data to the USA) compliant if the user was led to believe they were opting out, and that no data would be collected as a result (which is a reasonable belief, in my opinion). My view is that if we saw this challenged via a compliant to a DPA, it may not go well for the website under investigation.

Further, store policies such as Apple’s App Tracking Transparency may prevent you from specific forms of tracking, such as conversion measurement with a 3rd party advertiser when a user declines to consent.  It’s important to ensure that when using consent mode with a mobile app, you are also complying with the different store policies (Apple/ Google) or you risk facing enforcement action ranging from suspension all the way through developer account termination.   If this scenario applies to your situation, then your legal team and mobile app developers need to be in alignment in regard to the specific store policies, and whatever regulation you are subject to.

Next Steps

As I’ve shown above, the decision of when to use consent mode isn’t as straightforward as one may expect.  I hope this post has been helpful in highlighting the edge cases that I believe need to be considered when deciding on whether or not consent mode is right for your use cases.

Some next steps that could be taken in evaluating if consent mode is right for you:

  • Determine what the consent requirements are for any regulation you need to comply with
  • Determine what the profiling clauses of any regulation you are subject to say about users opting out of data collection
  • Determine if your website includes data which may be considered personal data in the URLs of the website.
  • Determine what the tracking policies are for any mobile application distribution store in which you publish an app.

Based on the answers to these (and potentially more) questions, you will be able to gauge if consent mode is right for your use cases.  It’s worth taking the time to evaluate usage from multiple angles, to avoid any unwelcome surprises later on.

Published inLegalPrivacyTag Management