Nice writeup and I really like the minimal aesthetic of your site!
On unique users: I wonder if there is a way to set this up to work similar to TelemetryDeck's double-hashing anonymization[1]. Did you look into that before deciding to go purely session-based?
Based on my understanding of the GPDR, this scheme wouldn't be anonymous, if the salt is stored anywhere. Using the salt(s) and the full list of all your users emails, you could find out which one matches the hash, thereby linking the analytics to the original PII. Of course that's a rather ridiculous idea, but AFAIK the GDPR doesn't put any qualifiers or limits on "it's not anonymous if the PII can be recovered with extra data".
It wouldn't if you own the full chain, i.e. have knowledge of both the on-device salt and hash AND the server salt and hash. However, in the scenario of using a third party like TelemetryDeck you as the developer would not be able to link the device hash to the server hash because you never see the latter.
So, my reading is: if there would be some mechanism (or a third party) which obfuscates the server hash so that you cannot tie it back to the device hash and only tells you "we've seen this device already" it could be anonymous. Of course, it also heavily depends on what other data you associate with that.
My umami instance handles a modest 1-2K events per day but does so on 150MB of memory and approximately no cpu. I switched from plausible, which might have been fine except clickhouse requires like 4 different containers and idles using 4+ GB. I am very happy with never needing to even think about umami.
Nice writeup and I really like the minimal aesthetic of your site!
On unique users: I wonder if there is a way to set this up to work similar to TelemetryDeck's double-hashing anonymization[1]. Did you look into that before deciding to go purely session-based?
[1]: https://telemetrydeck.com/docs/articles/anonymization-how-it...
Based on my understanding of the GPDR, this scheme wouldn't be anonymous, if the salt is stored anywhere. Using the salt(s) and the full list of all your users emails, you could find out which one matches the hash, thereby linking the analytics to the original PII. Of course that's a rather ridiculous idea, but AFAIK the GDPR doesn't put any qualifiers or limits on "it's not anonymous if the PII can be recovered with extra data".
It wouldn't if you own the full chain, i.e. have knowledge of both the on-device salt and hash AND the server salt and hash. However, in the scenario of using a third party like TelemetryDeck you as the developer would not be able to link the device hash to the server hash because you never see the latter.
So, my reading is: if there would be some mechanism (or a third party) which obfuscates the server hash so that you cannot tie it back to the device hash and only tells you "we've seen this device already" it could be anonymous. Of course, it also heavily depends on what other data you associate with that.
My umami instance handles a modest 1-2K events per day but does so on 150MB of memory and approximately no cpu. I switched from plausible, which might have been fine except clickhouse requires like 4 different containers and idles using 4+ GB. I am very happy with never needing to even think about umami.
Umami is awesome, I remember having one timezone based issue that was resolved the next week. Apart from that I've had no problems.
Tweaking a self-hosted Umami instance to support apps too
I'm also self-hosting umami, great project.
Another happy user here. Thank you for the awesome project.