Google’s Consent Mode continues to be a hot topic, especially since in 2024 it will be required to implement Consent Mode in case a website or app is collecting data for audience building or remarketing with Google’s advertising services. I’ve discussed consent mode before, and I’ve also built a Google Tag Manager community gallery template for managing Consent Mode on a website. With V2, the biggest updates are two new consent signals, ad_user_data and ad_personalization, as well as a revamped URL schema for passing consent states to Google’s services.
For the longest time, Google has been working towards consolidation of their products to build a unified tagging platform. Products that are instrumented (or associated) with “tags” would fall under this umbrella. These comprise tools like Google Tag Manager, Google Ads, Google Optimize, and, of course, Google Analytics. If you’ve been peeking under the hood, you might have noticed how all the tools listed above already run through the gtag.js library.
One of the key skills for anyone working with web analytics and tag management is understanding how to identify where things went wrong, why they went wrong, and ideally how to fix them. There are plenty of excellent browser extensions for helping you debug, and we’ll discuss these in the guide, too. But most of all we’re going to use browsers’ own developer tools, as they are always the best source of truth for anything that happens within the browser window.
Note! This is about the original version of Consent Mode. While the content is still very valid and you should read through it to understand how it works, Google has since released a “V2” update with additional consent signals. You can read about Consent Mode V2 here. . Not too long ago, Google announced a new consent mode for Google tags. It allows you to build a mechanism where Google’s tags parse, react, and respond to the consent status of your site visitors.
With the enforcement of SameSite settings in the latest versions of Google Chrome, it’s become a mad scramble to get cookies working across first-party and third-party contexts. I’ve covered this phenomenon before in my SameSite article, as well as in my guide for setting up cookieless tracking for iframes. Recently, Google Analytics updated its libraries (App+Web, gtag.js, and analytics.js) with a new setting: cookieFlags (analytics.js) or cookie_flags (App+Web and gtag.js).
One of the hard-and-fast rules in Google Analytics is that once hits have been collected and processed into your data properties, those hits are untouchable. This means that if you mistakenly collect duplicate or incorrect transactions, PII traffic, or referral spam, for example, it’s extremely difficult, if not downright impossible, to purge or change this data in Google Analytics. Another staple of Google Analytics’ strict schema is that displacing hits in time is also very difficult.
In Google Analytics: App + Web, you collect events. One event differs from another event by the name it uses. An event with the name page_view is different from, say, an event with the name file_download. This is all run-of-the-mill stuff. You know this. However, the fundamental change that App + Web introduces, when compared to Universal Analytics, is how event parameters are collected and processed. This gets more complicated than it should be.
- OLDER POSTS
- page 1 of 10