Tutorial: Server-Side IP Anonymization: GA4, Adobe Launch, and Jentis

Contents
In server-side tracking architectures, masking IP addresses before transmission to analytics endpoints is a critical step for data protection. The following guide details the technical configuration required to implement server-side IP anonymization across three major platforms: Server-Side Google Tag Manager (sGTM), Adobe Experience Platform (Adobe Launch), and Jentis.
1. Server-Side GTM (sGTM) for GA4
Anonymizing an IP address in sGTM requires creating a custom Variable Template using Sandboxed JavaScript, as standard browser-based JavaScript variables are not supported in a server environment.

- Navigate to the Templates section in the server container and click New under Variable Templates.
- In the template editor, go to the Code tab and insert the following Sandboxed JavaScript code:
const getEventData = require('getEventData');
const createRegex = require('createRegex');
const lastOctet = createRegex('\\.[^.]+$');
const ip = getEventData('ip_override') || getEventData('ip');
if (ip && typeof ip === 'string') {
return ip.replace(lastOctet, '.0');
}
return '0.0.0.0';
- Go to the Permissions tab and ensure the template has permission to read the
ipandip_overridekeys from event data. - Save the template with a recognizable name, such as Masked IP.
- Navigate to Variables, create a new variable using this template, and save it.
- Open the GA4 Tag. Under Parameters to Add / Edit, set the parameter name to
ip_overrideand the value to the newly created variable.
2. Adobe Launch (Server-Side / AEP Edge Network)
In an Adobe Experience Platform server-side setup, IP obfuscation is handled directly within the Datastream configuration.
- Access the Adobe Experience Platform Data Collection interface.
- Navigate to the Datastreams configuration menu.
- Select the specific Datastream used for routing the server-side traffic.
- Edit the Adobe Analytics service configuration within the stream.
- Enable the toggle labeled Mask IP Address. This setting instructs the Edge Network to automatically truncate the last octet of the IP address before forwarding it to the Analytics processing servers.
3. Jentis
Jentis offers built-in, centralized privacy controls for server-side data manipulation.
- Open the Jentis Data Capture Control Panel.
- Navigate to the Data Protection or Privacy settings section.
- Locate the PII (Personally Identifiable Information) masking rules.
- Create a new masking rule targeting the IP address parameter. The platform provides a pre-configured masking operation (truncation of the last octet) which can be applied either globally to all tools or specifically to a single destination.
- Save and publish the configuration to ensure the raw IP is dropped at the Jentis server level.
The Impact of IP Anonymization on GA4 Geolocation Data
The anonymization of IP addresses profoundly impacts the accuracy and granularity of geolocation reporting in Google Analytics 4. GA4 relies heavily on the visitor’s IP address to map sessions to specific geographic entities, such as cities, regions, and Internet Service Providers (ISPs). When the last octet of an IP address is truncated (e.g., altering 192.168.1.55 to 192.168.1.0), the source data loses its host-level uniqueness.
The immediate consequence is a significant reduction in geographic precision. While country-level data remains highly accurate, city-level attribution is often lost. The obfuscated IP address typically maps to a broader regional hub or the ISP’s main routing center, rather than the user’s actual municipality. Consequently, GA4 reports will exhibit a sharp increase in “Not Set” values for the “City” dimension, or display an artificial concentration of users in major metropolitan areas where ISP hubs are located.
Furthermore, this loss of granularity affects behavioral modeling, localized marketing attribution, and the ability to build hyper-local audience segments. Google’s internal machine learning models, which fill in data gaps, also receive a less precise initial signal, rendering local trend analysis less reliable. Organizations must therefore weigh the strict compliance benefits of IP masking against the structural degradation of local geographic insights.
2 comments
Having the three platforms in one place is useful, and the closing section on what masking costs in geographic detail is the part most guides leave out entirely.
A question on that trade: is the loss avoidable by masking after the geography has been derived — letting GA4 resolve the region first and discarding the address afterwards?
Not from the container. The derivation happens on Google’s side from whatever address arrives, and
ip_overrideis that address — there is no step in between where the raw value is used for geography and then discarded on request.So the choice really is what the article describes: city-level reporting, or an address that never leaves in full. That makes it a policy decision rather than a technical one, and it is better made explicitly than discovered later by an analyst wondering why every city reads as "not set".
Two things soften it in practice. Country and region survive masking in most cases, so the reports that drive budget decisions usually hold up. And dropping the last octet — what the template does — is already the mildest form available; anything coarser removes region as well. Where city-level detail genuinely matters for one specific report, the honest route is a separate, consented data source for that report rather than a weaker rule for all traffic.