We all love Google Analytics. It's intuitive, powerful and extremely useful for online businesses (or any business with an online presence). Getting to know how users interact with your apps and webs gives us a tremendous opportunity to improve the user experience and 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 until 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 evolved from the need to ingest and attribute data from multiple devices and platforms.
A common characteristic that all versions have shared so far is the need to adapt the tracking codes of the previous implementation. GA4 is no exception. It not only honours this tradition but also forces you to create a new property. Migrations are not simple things to do. Especially for companies relying on their apps and webs as their marketing or sales platforms, like any e-commerce. These companies have heavily customized implementations and upgrading is a decision that has to be carefully considered.
If you are working for such a company, this post might be in your interest.
Why GA4?
Each new version of Google Analytics is a reflection of the digital marketing industry and online consumer behaviour of the time. As when Universal Analytics was introduced, mainly, to solve cross-device user identification challenges in 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 Google's marketing platform ecosystem. It not only centralizes the reporting from several Google Advertising products but also feeds those with websites and apps with user data for advertising purposes. Given that central role, every marketer needs assurances that the data being used is as trustworthy as possible.
Previously data inconsistencies were due to 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 after a maximum of 7 days, the inconsistencies were no longer just coming from bad developers. Google Analytics wasn't able to recognize a returning user (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.
All those fancy multi-touch attribution projects using GA's data were now worthless. How can you possibly attribute when each browser imposes a different user definition?
Moreover, with the latest iOS14 updates users are requested to give explicit permission for each app to allow tracking. This has massively reduced the ability to uniquely identify iOS users in-app. It's estimated that only 15% of iOS14 users have given permission to be tracked in-app.
Although Google started to work on new ways of user identification before Apple's ITP 2.1 and definitely before iOS14, those releases just reinforced the idea of going beyond cookies and mobile app identifiers. Ultimately, that is what GA4 tries to solve, amongst other things.
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, what they often target are groups of users with common behaviours or demographics that performed (or didn't) certain actions.
We should clarify that when we talk about "identifying users" we refer 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 already has the User Id feature but, the key point is to identify those non-logged-in users (normally, not customers).
Without getting into too much detail, analytic tools such as Universal Analytics have been leveraging first-party cookies to identify users. Universal Analytics uses what are known as client-side first-party cookies. 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 abuse 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.
If that's the case, then "why do we need GA4?" we hear you ask. Well, are we sure Apple won't start a crusade against HTTP cookies in their next ITP version? I don't see a reason from a technical/security standpoint for them to do that, but the truth is nobody 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, 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 versions of the same app have different App Instance Ids.
An app, on average, gets updated every twenty-two days. Therefore we can approximately infer that, on 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 users allowing apps to use Advertising IDs for tracking purposes represents around 10% - 15% of the total. This means that the precision of 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
We all know it's best not to put all your eggs into one basket, yet this is precisely what GA4 Identity Reporting feature does. Instead of just relying on the device or marketer-provided ids (User IDs) to identify a user, it brings machine learning to infer a 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 number of users Google has across all its products. Here's how it works:
I think the image is pretty self-explanatory. Just be aware that, although you can activate Signals in Universal analytics, you can't benefit from its wealth of information in all reports, thus not taking full advantage of the opportunities it brings.
That alone should be enough reason for you to start thinking about deploying GA4 to your web/apps right away. Don't forget 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 our intention with this post to go in-depth on all the other new GA4 features, you can find a good summary here and hundreds more all over the web.
While most of the new features bring a clear improvement compared to the Universal version, they're not key consideration factors I'd use to advise a client on whether or not to invest in a new implementation. Data quality is a solid principle you must stand for, the rest, more often than not, is just noise.
Conclusion
While you can still operate with business as usual with Universal Analytics, it's in your best interest to start thinking about integrating Google Analytics 4 into your webs and apps. At Uptimal we are specialists at designing and deploying robust and accurate implementations ensuring above all, the quality of your data.
If it isn't the right time for your company to make the change to GA4 just yet, then fine, but we'd advise you to start moving just your web Universal Analytics set up 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.
