No, you don't need an ID. The article has one implementation that avoids IDs, but here's a simpler one:

Place a cookie HAS_BEEN_ON_SITE=true as soon as someone loads any page.

Voila, your server can now distinguish between users who've been to your site and users who haven't, without being able to tell recurring users apart from each other.

The implementation in the article is fancier, because the cache control headers allow distinguishing this on a page-by-page basis, but it's the same general idea. Don't give the client an ID, just ask the client to tell you if it's been there before.

Putting cookie like that means consent thingy you need to add tho.

Only ones that you don't need are ones that are expected functionality of the site, like you don't need to put it for shopping basket

Yes, but whether you legally must get consent is a separate question from whether you can count unique visitors while still being unable to tell them apart from each other.

Back in my days we called those "tracking pixels" and it didn't even need a cookie.

That's just not a real problem to solve. If you don't want to track users just giving each one unique ID is not a problem if you don't store them for future lookup.

The fact remains that from client perspective client have no way of telling whether you track them or not so you can't really prove to user you're not tracking them.

Reminder that the GDPR does not care about cookies specifically but about personal data and tracking in general. Using the the cache invalidation for tracking does not require any less consent then the equivalent cookie.

However, it does look like the ePrivacy Regulation will clear this specific case up, at least according to Wikipedia:

> The proposal also clarifies that no consent is needed for non-privacy-intrusive cookies improving internet experience (like to remember shopping cart history) or cookies used by a website to count the number of visitors.