Google Analytics 4

AnalyticsTracking

Julià Pujol

April 22, 2021
Cabecera
Each Google Analytics version is just an updated reflection of the digital marketing industry. GA4 seeks to solve cross-device user identification challenges in a privacy driven times.

We all love Google Analytics - it's intuitive, very powerful and most important, very useful for online business or businesses with an online presence. Getting to know how users interact with apps and webs gives us a tremendous opportunity to improve their experience and so increase business revenues.

Google Analytics has a long story behind it. It started as a product developed by Urchin and later acquired by Google in 2005. In 2007, the Classic version was released, followed by the Universal version in 2012 till last year's announcement of the new Google Analytics 4, aka GA4.

Each version has brought new features and capabilities, for example, the User ID and the Measurement Protocol were capabilities introduced by the Universal version. In fact, Universal analytics born from the need of ingesting (and attribute) data from multiple devices and platforms.

A common characteristic that all versions have shared so far is the need for adapting the tracking codes of the previous version implementation. GA4 is no exception - not only honors this tradition but it also forces to create a new property. Migrations are not simple things to do, specially for those companies relying on their apps and webs for marketing or as a sales platform, such e-commerces. These companies have strongly customized implementations and upgrading is a decision that should be carefully considered.

If you are working for such companies, this post might be of your interest.

Why GA4?

Each Google Analytics version is just an updated reflection of the digital marketing industry and the online consumer behaviour. As Universal Analytics came, mainly, to solve cross-device user identification challenges in a less-privacy driven times, GA4 comes to solve, mainly, cross-device user identification challenges in a more-privacy driven times (please note the use of "mainly").

Google Analytics is a key piece of the Google's marketing platform ecosystem that not only centralizes the reporting from several Google Advertising products, but it also feeds those with website/app user's data for advertising purposes. Given that central role, any marketer wants assurances that the data in it is as trustworthy as possible.

Traditionally, data inconsistencies were due wrong implementations but, since Apple started changing the expiring rules of the first party cookies  (the mainstream method of Universal analytics to identify users) and set them to expire max. after 7 days, the inconsistencies were no longer (just) coming from bad developers: Google Analytics wasn't able to recognize a returning user (using Safari) if the user didn't visit the site during the last 7 days, as opposed to the 2 years time frame we were all used to. 

What about that? All those fancy multi-touch attribution projects using GA's data are worth nothing. How do you possibly attribute when each browser imposes a different definition of user?

Moreover, the latest iOS14 updates where users are now enforced to explicitly allow tracking (basically allow to be uniquely identified) in apps have hugely reduced the ability of uniquely identifying iOS users in apps. It's estimated that only 15% of iOS14 users are allowing being tracked in an app.

Although Google started to work on new ways of user identification before Apple's ITP 2.1 and surely before iOS14, those releases just reinforced the idea of going beyond cookies and mobile app identifiers. Ultimately, that is what, among other things, GA4 tries to solve.

Universal Analytics user identification

In digital, the ability to identify a user or a group of similar users is paramount. When an analyst looks for insights, really is looking for groups of users with common behaviours or demographics that performed (or didn't) certain actions.

Before proceeding, let me just clarify that when I talk about "identifying users", I am referring to non-web-logged-in users as those represent the vast majority of web traffic nowadays. For web-logged-in users (not to confuse with browser login such as Google login in Chrome), Universal got the User Id feature but, the key point is to identify those non-logged-in users (normally, not customers).

Without getting into much detail, analytics tools such as Universal Analytics have been leveraging first party cookies to identify users. Specifically, Universal analytics is using what's known as client side first party cookie, which in simple terms means that the cookie has been created from code running in the user's browser.

First party cookies weren't designed to allow cross-site tracking and were considered secure until some AdTech players used them for cross-site tracking. This misusage explains why now client side first party cookies expire after seven days in Safari. As discussed, this isn't good news, we still like the user that visited our website to be "the same user" after seven days, don't we?

The good news is that you don't need GA4 for that, now with Server side Tag Management you can actually set first party cookies without expiration limits, those are known as server side first party cookies or just HTTP cookies. Won't get into details on why Safari allows those to be created, you just need to know that those are a lot more secure.

Being said that, we could ask ourselves again, why GA4? Well, are we sure Apple won't start a crusade against HTTP cookies in their next ITP version? I am telling you, I don't see a reason from a technical/security standpoint for them to do that but I'm not positive, in fact, no one knows. What is certain is that if by any chance AdTech finds a way to utilize HTTP cookies as a means of cross-site tracking, these will be blocked too.

Regarding mobile apps, for analytics tools, still the App Instance ID (not to confuse with the Advertising ID - a unique ID per user's device) is used to identify users. This id is unique per user and app version and changes every time an app is updated. Different apps and different version of the same app have different App Instance Ids.

An app, in average, gets updated every twenty two days, therefore we can approximately infer that, in average, a user won't be the same "user" if the timespan between visits is greater than twenty two days - definitely not ideal for analytics purposes.

Nonetheless, Universal analytics for apps (Firebase) is also collecting, when available, Advertising IDs along with Vendor IDs to determine "Advertising efficiency" - it's a no brainer that these are also used to identify the uniqueness of a user.

Since the release of iOS14, as explained before, users allowing apps to use Advertising IDs for tracking purposes represents around the 10% - 15% of the total, which means that the precision on identifying iOS users based on device Ids is now far from what it was.

If there is something to learn from all of this is that we can't just rely on device Ids, being those cookies or any app mobile ID, for identification purposes. There must be something else.

Although Google started to work on new ways of user identification before Apple's ITP 2.1 and surely before iOS14, those releases just reinforced the idea of going beyond cookies and mobile app identifiers. Ultimately, that is what, among other things, GA4 tries to solve.

GA4 user identification

It's said that it's better not to put all your eggs into the same basket - this is precisely what GA4 Reporting identity feature does - instead of just relying on device or marketer-provided ids (User Id) as a means of identifying a user, it brings machine learning to infer user's identity from sites and apps that Google associates with users who have signed in to their Google accounts, and who have turned on Ads Personalization - this "feature" has been branded as Google Signals.

Google Signals isn't new, it has been implemented in Universal analytics since 2018 for a few pre-built reports, but now this functionality is available by default in all GA4 reports. This feature is backed up by the amount of user that Google has among all their products. Here is how it works:

I think the image is very self-explanatory - just be aware that, although you can activate Signals in Universal analytics, you can't benefit from its wealth in all reports, thus not taking full advantage of the opportunities it brings.

That alone should be enough reason for you to start thinking on to deploy GA4 to your web/apps right away. Call to mind that GA4 requires a new property, which means no historical data will be available on that property. If your data is valuable to you, the sooner you get GA4 rolling, the better.

Other GA4 new features

It's not the intend of this post to go in depth with other new GA4 features, you can find a good summary here and hundred more all over the web.

While most of the new features bring a clear improvement compared to the Universal version, those aren't a key consideration factor I'd use to advice a client on either or not make the investment on a new implementation. Data quality is a solid principle you can stand for, the rest, many times it's just noise.

Conclusion

While surely you can still operate with business as usual with Universal Analytics, it's in your best interest to start thinking on integrating Google Analytics 4 to your webs and apps. At Uptimal we are specialist at designing and deploying long live and accurate implementations ensuring above all, the quality of your data.

If the time isn't yet right for your company to step forward, I'll at least advise you to move just your web Universal analytics implementation to Server side Tag Management, thus ensuring your cookies stay safe and users are identified seamlessly across browsers. The quality of your data is important.

Posts that might be of your interest