Your visitors' IP addresses will all be anonymized with the default privacy settings.

IPv4 addresses are 32-bit. To anonymize them, we save the first 24 bits and drop the rest.
In human-readable format, that means this:

209.17.88.170 -> 209.17.88.0
IPv6 addresses are 128-bit. To anonymize them, we save the last 32 bits and drop the rest.
In human-readable format, that means this:

2604:ca00:31a:9ae2::6e4:a4be -> :6e4:a4be
Why do we save different parts of the two address types? It's complicated!

IPv6 addresses are huge no matter which way you slice it. This makes for poor readability, and is a problem for database storage when we're logging 100M+ per day. To make matters worse, the second half of an IPv6 address changes every 24 hours on most consumer devices due to privacy extensions . This means it's actually 100M+ new and unique 128-bit addresses every day, which has a major impact on normalization and would result in significantly more than 4x the storage of IPv4 over an extended period of time.

For these reasons, and in consideration of a more privacy-friendly future, we decided to save just 32 bits of an IPv6 address, no matter what your privacy preferences are set to.

You may wish we chose a different part of the IPv6 address, and it's certainly debatable which part is most interesting. Bits 33-64 are roughly equivalent to a full IPv4 address, in terms of identifying a specific network (e.g. a home router) and being fairly stable. Years ago this would be fine, but today a significant portion of internet traffic is behind large VPN-ish services like iCloud Private Relay . Every iCloud visitor in the same general location will have the same first half of an IPv6 address, and without tracking cookies, it's not always possible to distinguish multiple visitors online at the same time when the IP fragment we're saving is the same for each one.

You may be asking, "doesn't this apply to IPv4 too?", and the answer is yes — which is precisely why we're not using bits 33-64. Instead, by using the last 32 bits, every visitor becomes easily distinguishable, with the tradeoff being it's harder to know if they come back after 24+ hours. Rapidly changing addresses is also why our IP tagging feature doesn't support IPv6.

It's also much clearer which part of the address is being displayed in a report when it's the start or end, rather than the middle. The start is only unique on a per-provider basis, which leaves the end as the only clear choice.

The end of a string is also easier to match up with other logs and data sources using just the human eye. Although it is worth noting, if your website does not support IPv6, you will still have visitors on IPv6 that may connect to your site with IPv4, but then connect to our tracking servers with IPv6. This will result in the IP we log being completely different than what you may have in your own log files. There's nothing we can do about that unfortunately, other than recommend getting your website on IPv6 as soon as possible!