There are two issues with typical analytics solutions:
- they rely on visitor consent
- they involve processing in the US
Some people believe that they can sidestep GDPR problems by only collecting anonymous data, but this doesn't matter for the consent requirement, and is also impractical in my experience.
These aspects are discussed in more detail below.
Before I go further, I have to mention that no common analytics solution relies on third-party cookies. While analytics services are often provided by a third party, that is neither technically nor legally relevant. Technically, these analytics scripts usually set some analytics ID on a first-party cookie – a cookie scoped to the domain where the website is running, not scoped to the analytics provider's domains. Legally, analytics services often serve as a “data processor” on behalf of a website, and don't use the collected data for their own purposes. GDPR allows outsourcing processing activities (such as analytics collection) to others.
In particular, this means that there is no technical or legal argument for preferring self-hosting over using some analytics services, assuming other relevant conditions are complied with (data processing agreement, international transfers). In the past, ad blockers have also blocked a large percentage of self-hosted analytics servers.
Self-hosting some analytics solution is primarily valuable because it gives you more control over where the data is processed. But it doesn't give you better analytics, and doesn't let you sidestep any consent requirements.
Server-side tracking is quite limited in what kind of info it can collect, but it is the only collection method that cannot be blocked. Since you're only re-interpreting data that the server has anyway, no extra network requests are caused between the client and the server. Collection session- or user-level data can be challenging though, unless the visitor is logged in. Server-side data collection is very easy on traditional websites, but more challenging e.g. with single-page applications that communicate with the backend via GraphQL.
Server-side data collection is most valuable when business-level events can be tracked – an event such as “placed order” is probably closer to the user's intent than “navigated to /checkout”.
You will probably find that this is not an either–or situation. You will likely want some server-side analytics as a baseline (limited data, but less problematic legally, and limited impact of blocking software), but still want to use traditional analytics for those visitors that consent to it.
When consent is needed
By itself, there might be a legitimate interest for collecting analytics. But for collecting session-level data, it is necessary to assign some kind of identity to visitors. This is usually done by setting a cookie with a random ID.
Per the ePrivacy Directive in the version from 2009, any access or storage to information on the end user's device needs consent, unless that access/storage is strictly necessary for a service explicitly requested by the user. This is known as the “cookie law”, but is not technology-specific and will also apply to equivalent client-side approaches such as LocalStorage, tracking IDs in URLs, or fingerprinting. The consent requirement is also independent from the question whether the stored information qualifies as personal data.
The GDPR didn't change anything with these rules. It only changed the definition of consent, invalidating “implied consent” approaches like “by continuing to use this site, you consent to …”. Consent means opt-in. Consent must be easy to decline and to withdraw, and users must understand what specifically they are consenting to. This has led to a decrease in percentage of people who consent to storage of analytics IDs.
What you can do about it
Consent is only explicitly required for client-side storage or equivalent technologies. That means you may be able to collect some analytics on an opt-out basis. You can collect some client-side data without asking for consent. And you can probably use server-side data for analytics purposes.
That means you are able to get comparable page-level data, but not session-level data. For determining the country of the user, you just need the user's IP, and this is available server-side.
Google's deprecation of UA and move to GA4 helps analytics customers to be more compliant, by making it easier to collect data without setting a ClientID.
Why US-based services are a problem
The GDPR expects that the entire data processing pipeline maintains a high level of data protection. This means that transferring personal data into non-European countries is only allowed if they offer an adequate level of data protection. Alternatively, contracts (SCCs) between the data exporter and data importer may be able to translate enough of the GDPR into an enforceable contract with the foreign importer, to ensure compliance of processing there.
The US did have an adequacy decision called “Privacy Shield”, but this was invalidated due to concerns over the rule of law in relation to US mass surveillance laws. For the same reasons, contracts with US-based data importers are probably invalid. There are also increasing concerns of using EU-based services from US-controlled companies.
In particular with relation to Google Analytics, there have been repeated warnings by data protection agencies that use of this service violates GDPR. GA does not guarantee that the personal data collected via the analytics platform is only processed in Europe.
What you can do about it
The international transfer problems can be avoided by using an analytics service hosted in Europe, or in any other country with an adequacy decision (such as Canada). Self-hosting on an European server is another popular option.
Analytics data is rarely anonymous
In your question, you write:
I don't want to use PII data, but eager instead to find a privacy-friendly way to distinguish one user from another.
It is important to mention here that the US concept of PII is substantially more narrow than the GDPR concept of personal data (PD). PD is not just directly identifying info, but any data relating to an identifiable person. A person is identifiable not only when you know their real-world identity or email address, but already when you can single them out in a data set, or otherwise distinguish them from others.
Thus, per-session or per-visitor analytics data should be treated as personal data, and GDPR continues to apply (which may or may not mandate consent).
Anonymization is possible but challenging. Anonymization tries to ensure that there are no reasonable means that could likely identify the data subject. The only widely used anonymization method is aggregate statistics, e.g. moving from per-user events to average values. In particular, aggregate metrics such as “pageviews per month” are anonymous.
Other anonymization techniques I have seen:
Tokenization: mapping the user's ID to an entirely random ID. After some time (e.g. 24 hours), the mapping is erased so that the random ID cannot be traced back to a user.
Plausible uses a weaker variant of this that uses a hash function to derive a pseudo-random ID from the user's identifying info (e.g. IP address). While Plausible's approach avoids having to store a large lookup table, a malicious server operator could log the daily key and use it to recover the original data from the hashed IDs.
The weakness of this approach is that it still relies on some identifying data. While it is a good compliance and security measure, it doesn't really change anything fundamental from the GDPR perspective.
Differential privacy: individual records are distorted with an appropriate amount of noise, but the noise cancels out when calculating aggregate statistics.
Such techniques are the state of the art, and the only class of general-purpose anonymization techniques that are likely to achieve anonymization in the sense of the GDPR.
However, they are mathematically involved. I don't know of any analytics product that incorporates differential privacy techniques. From my own research into GDPR-anonymized analytics, I found it challenging to design solutions that both provide proper anonymization and are able to provide sufficiently accurate session-level statistics as expected from a typical web analytics solution.
