IP Anonymization: How It Works, GA4 Behavior and Log Setup

IP anonymization is the practice of removing or altering part of a visitor’s IP address before it is stored, so the saved value no longer identifies a single device or connection. In analytics it usually means truncation: the last octet of an IPv4 address and the last 80 bits of an IPv6 address are set to zero. Google Analytics 4 does this for you, because it never stores IP addresses at all.

The term also gets used for the opposite side of the connection: hiding your own IP with a VPN, Tor or a proxy. This guide covers both, then goes further than most explanations: how many people actually share a truncated address, what anonymization does to your analytics and conversion data, how to anonymize your own server logs, and how to check that raw IPs are not leaking somewhere else.

What IP anonymization means in practice

Every request to a website carries the visitor’s public IP address. Servers, CDNs, analytics tools and form plugins can all write it down. Anonymization changes what gets written so the stored value is less precise or not reversible. There are two different jobs people mean by the phrase:

The first job is what “anonymize IP” means in Google Analytics, WordPress plugins and privacy policies. The third is usually called IP masking or hiding your IP. They protect different people: one protects your visitors from your records, the other protects you from everyone else’s.

How IP truncation works: IPv4 and IPv6 examples

Truncation keeps the network part of an address and zeroes the part that identifies a specific connection. The rule Google used in Universal Analytics, and which most tools copied, is documented in its IP masking help page: the last octet of IPv4 addresses and the last 80 bits of IPv6 addresses are set to zero in memory, before anything is written to disk.

IPv4

An IPv4 address is four numbers from 0 to 255 (four octets of 8 bits). Truncation replaces the last one with 0:

IPv6

An IPv6 address is 128 bits written as eight groups of four hex digits, each group 16 bits. Zeroing the last 80 bits clears the last five groups and keeps the first three. Runs of zero groups are written as ::, so the result looks short:

If you ever need to match an anonymized address against a list, this is the shape to expect. A rule written for the full address will never match the truncated one.

How many people share a truncated IP address?

Truncation is often described as making an address anonymous. Whether it does depends on how many people sit behind what is left. Here is the arithmetic.

The IPv6 number looks enormous, but it is misleading. IPv6 prefixes are handed out in blocks, and an internet provider often gives a single business or even a single home its own /48 or /56 block. The 48 bits that survive truncation are exactly a /48. So a truncated IPv6 address can still map to one office or one household, while a truncated IPv4 /24 is more often shared by many customers of a provider.

Two more things weaken truncation. A business with its own IP range keeps its identity after truncation, because the network part is what names the company. And truncated addresses stored next to a timestamp, user agent and page path can be narrowed down much further than the address alone suggests. Treat truncation as data minimization, not as a guarantee that no one can be identified.

IP anonymization in Google Analytics

Universal Analytics: the anonymize_ip setting

In Universal Analytics, IP anonymization was opt-in. You added a parameter to the tag, which sent aip=1 with each hit:

// Universal Analytics, gtag.js (legacy, no longer processes data)
gtag('config', 'UA-XXXXXX-Y', { anonymize_ip: true });

// Universal Analytics, analytics.js (legacy)
ga('set', 'anonymizeIp', true);

Plugins such as Rank Math and MonsterInsights exposed this as a checkbox, and many tutorials and videos still show it. Universal Analytics has stopped processing data, so these settings only matter if you are cleaning up old code.

GA4: always on, nothing to configure

Google’s documentation is direct: in GA4, IP masking is not necessary because IP addresses are not logged or stored. GA4 uses the address briefly to look up coarse location (city, region, country) and then drops it. For visitors in the EU, Switzerland and the UK, Google says collection runs through servers in those regions and the IP is discarded there.

That means adding anonymize_ip: true to a GA4 gtag(‘config’) call does nothing useful. The parameter is sent along with your events, which is why people see it in debug tools and assume it works. You can remove it.

Internal traffic filters: what the old advice gets wrong for GA4

A common forum question is whether IP anonymization breaks IP exclusion filters. For Universal Analytics, the answer was yes. Truncation happened before storage and processing, and filters ran during processing, so a filter on 203.0.113.57 never matched. The working fix was to filter on the prefix, for example “begins with 203.0.113.” for IPv4 or the first three groups for IPv6.

GA4 works differently, and applying the old advice there is a mistake. GA4’s internal traffic rules match the IP when the event is collected and add a traffic_type parameter (default value internal) to matching events. A data filter then excludes events with that value. Because the rule runs at collection, you can match full addresses, prefixes or CIDR ranges even though GA4 never keeps the IP.

• Use “IP address is in range” with CIDR for office networks, for example 203.0.113.0/24.
• For IPv6, list the office prefix, not one device’s address, because devices rotate their interface identifiers.
• Start the data filter in Testing state and compare reports before activating it. Google says a filter takes 24 to 36 hours to apply and its effect is permanent.
• Remote teams on home connections will not match any office range. A cookie- or parameter-based rule for staff is more reliable there.

What IP anonymization changes in your analytics and conversion data

None of the usual guides cover the measurement side, but that is what a marketer or site owner feels. Here is what anonymization changes and what it leaves alone.

The attribution row is the one people worry about most, and it is the safest. A visit is credited to Google organic or ChatGPT because of the referrer and campaign tags on the landing page request, not because of who owns the IP. That is also how privacy-first tools work: SEOConversion, for example, is first-party, cookieless and PII-free, and still reports conversions and their value by organic and AI landing page. If you are rebuilding measurement around privacy, the cookieless tracking guide covers the methods and their accuracy trade-offs.

Worked example: an internal traffic leak after anonymization

Illustrative numbers. A B2B site gets 8,000 sessions a month and records 160 lead form submissions. The team has an IP exclusion filter for the office, written on the full address. After IP anonymization is switched on in a tool that truncates first, the filter silently stops matching. The office generates 600 sessions and 40 test form submissions a month while the team checks forms and landing pages.

The report overstates lead value by $2,000, or 33% of the real figure, and the inflated conversion rate concentrates on whichever landing pages the team tests most. The fix is not to turn anonymization off. It is to rewrite the rule against the truncated prefix or a CIDR range and to check that test submissions disappear from the report. For how to set a defensible value per lead, see how to calculate conversion value, and for the full measurement setup, the SEO conversion tracking guide.

How to anonymize IP addresses in your own logs and databases

Analytics tools are only one place IPs land. Web server logs, application databases and form submissions often keep full addresses for months. The right method depends on what you still need the data to do.

Researchers who publish packet traces add two refinements worth copying. Keep special ranges, such as private and multicast addresses, separate so they do not collide with public ones. And remember that a distinctive host, like a company’s only web server, stays recognizable under almost any scheme, because its behavior gives it away.

Example: anonymized nginx access logs

This configuration writes truncated addresses to the access log. It zeroes the last IPv4 octet and keeps only the first two IPv6 groups, which is stricter than the 80-bit rule. Adjust the IPv6 pattern if you need the third group for abuse reports.

# /etc/nginx/conf.d/anon-log.conf  (http context)
map $remote_addr $remote_addr_anon {
    ~(?P<ip>\d+\.\d+\.\d+)\.     $ip.0;    # IPv4: zero the last octet
    ~(?P<ip>[^:]+:[^:]+):          $ip::;    # IPv6: keep the first 2 groups
    default                        0.0.0.0;  # anything else: drop it
}

log_format anon '$remote_addr_anon - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log anon;

Test it with nginx -t, reload, and check the log. If your server sits behind a CDN or load balancer, the address in $remote_addr is the proxy’s unless you configure the real IP module, and the CDN keeps its own logs with full addresses.

Checklist: where raw IP addresses still hide

Turning on anonymization in one tool rarely covers the whole stack. Go through this list once and note who owns each item.

• Analytics requests. Open your browser’s developer tools, Network tab, and filter for collect. Legacy Universal Analytics hits should carry aip=1. GA4 needs no parameter.
• Web server logs. nginx and Apache store full IPs by default. Truncate them in the log format or rotate and delete them on a short schedule.
• CDN and firewall logs. These are separate from your server and have their own retention settings.
• Forms, CRM and email tools. Many form plugins save the submitter’s IP with each entry. Check the plugin settings and your CRM import.
• Comments, error trackers and session replay. Check each tool’s privacy settings for an IP option.
• Backups and exports. Anonymizing the live database does not change last month’s backup.

Is an anonymized IP address still personal data?

Under the GDPR, IP addresses are listed as online identifiers, and EU courts have held that even a dynamic IP can be personal data when the site operator has lawful means to identify the person behind it. The legal test for “anonymous” is strict: data falls outside the GDPR only when no one can reasonably identify the person, using any means likely to be used. Data that can be linked back with a key or with other records is pseudonymous, and pseudonymous data is still personal data.

So truncation lowers risk but does not, on its own, make processing lawful or remove the need for consent. European regulators that ruled against specific Google Analytics deployments did not accept the IP anonymization setting as enough. The sensible reading:

• Anonymize or drop IPs everywhere you can, as part of data minimization.
• Do not claim in a privacy policy that data is “anonymous” just because the IP is truncated.
• Decide on consent based on what your tools store and do on the device, not on the IP setting alone.

This is general information, not legal advice. Check with your privacy counsel for your jurisdiction.

Hiding your own IP address: VPN, Tor and proxies

If you came here to make your own browsing anonymous, the tools are different. Your public IP reveals your internet provider and a rough location, often a city and sometimes the wrong one. It does not reveal your name; only your provider can connect the address to your account. Hiding it stops sites, ad networks and anyone watching the connection from tying your activity to that address.

For site owners, the flip side matters: visitors on VPNs, Tor and private relays show up with the wrong location and sometimes as bots. That is one more reason to treat IP-derived city data as approximate.

Private IP ranges and IP classes

Several common questions about IP privacy are really about private addresses. RFC 1918 reserves three IPv4 blocks for private networks that are not routed on the public internet:

So yes, any 192.168.x.x address is private. 192.168.1.1 is the default address of many home routers. It is not dangerous in itself, and no one on the internet can reach it directly. The real risk is a router whose admin login still uses the factory password. Private addresses also never appear in your website analytics, because your visitors’ routers translate them to a public address before the request leaves the house.

The “5 classes of IP” come from the original IPv4 design, before classless routing (CIDR) replaced it. They are still taught and still describe the address ranges:

The “/24” you see in IP masking discussions is CIDR notation: the first 24 bits are the network, leaving 8 bits, or 256 addresses. That is exactly what IPv4 truncation keeps.

FAQ