Using self-hosted Umami for iOS app analytics

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.

Re: Using self-hosted Umami for iOS app analytics

#8

Post by josters » Sun, Jul 19, 2026, 5:01 PM UTC

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...

Re: Using self-hosted Umami for iOS app analytics

#9

Post by kodebach » Sun, Jul 19, 2026, 5:19 PM UTC

josters wrote: post #8

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".

Re: Using self-hosted Umami for iOS app analytics

#10

Post by josters » Sun, Jul 19, 2026, 5:35 PM UTC

kodebach wrote: post #9

josters wrote: post #8

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…

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.