Menu

#GTMTips: Consent Granted Reprocesses Previously Denied Hits

If using Google's Consent Mode, you do not need to resend hits that happened on the same page (when consent was denied) once consent is granted. The denied hits are automatically reprocessed to have granted status.
Simo Ahava in GTM Tips on #google tag manager , #gtmtips , #consent mode , #google analytics 4 Non-AMP version

This will be a quick tip, but it’s here to correct my previous statements in the comments section of different articles on this blog.

When using Advanced Consent Mode, Google Analytics 4 collects hits when consent is in "denied" state. These hits have a lot of parameters stripped off them, including identifiers like the Client ID and the Session ID.

The hits will not surface in reports directly, but they will instead go through a modeling process to enrich the reports once modeled.

In this article, I’ll explain why it’s not necessary to resend these hits once consent is granted later on the same page.

I had previously thought that yes, of course you need to resend the hits. Switching previously “consent-denied” hits to suddenly be “consent-granted” just because something happened later on the page sounds suspect.

I was wrong. Or well, I was partly right because it still sounds suspect, but this type of reprocessing is exactly what Google Analytics 4 does.

Tip 137: No need to resend previously denied hits if consent is granted later on the page

Long story short, Google Analytics 4 reprocesses hits that had “denied” status if, later on the same page, consent is switched to “granted” for analytics_storage.

This means that you do not have to resend those hits. They will appear in your GA4 reports and in your daily BigQuery export as if they had been collected when consent was “granted”.

Here’s how I tested it. I collected data from three users, each sending different events with different timing related to consent state. Here are the results from the BigQuery export:

All of these hits have the user_pseudo_id assigned to them. If consent was considered “denied”, then user_pseudo_id should have been null.

I did check the intraday tables. In those, the denied hits did indeed have null for the values. However, in the daily export (in the screenshot), this is no longer the case. The data has been reprocessed.

The use cases were:

d-denied-purchase-u

  1. Consent was denied
  2. page_view and first_visit were collected
  3. purchase was collected
  4. Consent was granted
  5. user_engagement was automatically collected

Result: All four events were associated with the user with all parameters intact.

GA4 collects a user_engagement hit as soon as consent is granted, no doubt to enable this reprocessing in cases where no other hits are sent later.

d-denied-u-pv

  1. Consent was denied
  2. page_view and first_visit were collected
  3. Consent was granted
  4. user_engagement was automatically collected
  5. page_view was manually sent

Result: All four events were associated with the user with all parameters intact. In other words, the page_view info is duplicated for this user.

d-denied-u

  1. Consent was denied
  2. page_view and first_visit were collected
  3. Consent was granted
  4. user_engagement was automatically collected

Result: All three events were associated with the user with all parameters intact.

Summary

This makes Consent Mode setups so much simpler because you no longer need to re-send hits with potentially important campaign data.

Of course, if those hits happened on previous page loads, then that information is lost. It’s not possible to persist information from page to page without consent.

Now, whether it’s legally or ethically OK to backstitch data like this is another consideration.

On a simple landing page where it takes time for the user to grant consent, I don’t think there is any problem here. This is information that’s readily available on the page and would have the same content (apart from the timestamp) if collected after the user consented.

On a more complex setup like a single-page app, it’s more nuanced. I haven’t tested whether there is some extra logic in GA4 for only reprocessing hits that occurred within a short time period or on the same page_location, but if the reprocessing applies to all hits collected within the same page load then it’s possible data gets collected that the user certainly didn’t consent to.

Let me know in the comments if you have questions about this!

No, I don’t know what happened to the session_start event – it wasn’t in the BigQuery data – perhaps it did not get reprocessed the same as the other hits.