Track the visitor’s country with Cloudflare
This page describes GTM4WP 2.1.0. Release 2.0.0 removed the geo data feature that was built on the IP Stack service, and one geo variable survived it: geoCloudflareCountryCode, which needs no 3rd party service and no API key. Where GTM4WP 2.0.x behaves differently, its behavior is marked with a bold GTM4WP 2.0.x: lead-in. The variables that IP Stack provided are kept at the bottom of this page, each marked Legacy 1.x variable, so that you can look up what they used to hold.
geoCloudflareCountryCode
The two letter country code of the visitor, taken from the CF-IPCountry header that Cloudflare adds to the request. It is only available when your site sits behind Cloudflare, because nothing else sets that header. Cloudflare works the country out from the IP address itself, so the plugin makes no request to another service and needs no API key.
The value is a two letter ISO 3166-1 alpha-2 code or one of the two special codes Cloudflare uses: XX when it has no country for the visitor, and T1 for visitors on the Tor network. If the header holds anything else, the variable is left out of the data layer.
Turn it on with the Cloudflare country code option, in the Visitor data group of the Page variables section on the plugin settings screen. The option is switched off by default and is marked experimental, because whether the header arrives at all depends on infrastructure that sits outside the plugin. When the header is missing, the variable is left out of the data layer instead of being added empty, so build your Google Tag Manager triggers to cope with a variable that is not present.
A request that reaches your server directly, without passing through Cloudflare, can carry any CF-IPCountry value the sender chose. To rule that out, list the Cloudflare IP ranges in the Visitor IP – Trusted proxy addresses option. With the list filled in, the header is read only for requests that arrived from one of the listed addresses. Without the list, it is read as sent, and an admin notice asks you to add the ranges or turn the option off.
GTM4WP 2.0.x: the header was read as sent, even with trusted proxy addresses configured, and its value was passed on without a format check.
The option sits next to the other visitor variables, which are described on the user and visitor data page. With the Cache-safe data layer option enabled, this variable is delivered in the browser as part of the gtm4wp.visitorData event rather than in the cached HTML, and it is fetched once per session.
Replacing the feature
Where you need more than the country code, the closest replacement runs entirely in Google Tag Manager. The IP Geolocation API tag template by Simo Ahava loads the ipgeolocation.io SDK in the browser, looks the visitor up by IP address and pushes the result into the data layer under a custom event name that you choose. Tags that need the values fire on that event, which is the same pattern the plugin uses for its own client-side data. It is a web container template, so it needs no server-side Google Tag Manager setup.
The template needs an ipgeolocation.io API key, and that service has a free plan. Its include and exclude settings decide which fields of the response reach the data layer, and the response covers everything the removed variables carried: country code and country name, region, city, postal code, latitude and longitude.
As with the old plugin feature, the lookup sends the IP address of your visitor to a 3rd party service, and here it happens from the browser rather than from your server. Ask for consent where your data protection rules require it, and gate the tag on that consent in your container.
If you already run server-side Google Tag Manager, the geo data can come from the request itself instead. A host that resolves the location of the visitor adds it to the incoming request as HTTP headers, and you read those in the server container with a variable of the built-in Request Header type, so there is no template to import and no separate API key. On Stape hosting this is the GEO Headers power-up, available from the free plan upwards, which works the location out with MaxMind GeoLite2 data and adds X-GEO-Country, X-GEO-Country-Name, X-GEO-City, X-GEO-Region, X-GEO-PostalCode and X-GEO-Ipaddress. That covers the country, region, city and postal code, but it gives you no latitude or longitude.
The IP Stack geo variables
Everything below was removed in GTM4WP 2.0.0. The plugin no longer contacts IP Stack, and when you upgrade it deletes the stored geo options, including the saved API key. None of these variables is written into the data layer any more, so review your Google Tag Manager container and remove any tag, trigger or variable that reads one of them. Where you only need the country and your site is behind Cloudflare, geoCloudflareCountryCode above is the replacement. For anything finer than that, see the replacement options above.
In 1.x the lookup shared the IP address of the visitor with IP Stack, and a block_gtm4wp_geoip cookie set in the browser of the visitor switched it off for that person. Any of the values "yes", "true", "on" or "1" counted as a block. That cookie has no effect in 2.0.0, because no lookup is made. Depending on the traffic of the site, IP Stack could charge for the volume of requests.
geoFullGeoData
Legacy 1.x variable. The full API response of IP Stack, as an object. The fields it could contain are listed in the IP Stack documentation.
geoCountryCode
Legacy 1.x variable. The country code on its own, taken from geoFullGeoData, using ISO 3166-1 alpha-2 codes. On a site behind Cloudflare, geoCloudflareCountryCode reports the same kind of value and is still available.
geoCountryName
Legacy 1.x variable. The country name on its own, taken from geoFullGeoData.
geoRegionCode
Legacy 1.x variable. The region code on its own, taken from geoFullGeoData, for example CA for California.
geoRegionName
Legacy 1.x variable. The region name on its own, taken from geoFullGeoData, for example California.
geoCity
Legacy 1.x variable. The name of the city on its own, taken from geoFullGeoData.
geoZipcode
Legacy 1.x variable. The postal code on its own, taken from geoFullGeoData.
geoLatitude
Legacy 1.x variable. The latitude on its own, taken from geoFullGeoData.
geoLongitude
Legacy 1.x variable. The longitude on its own, taken from geoFullGeoData.
Related pages
The weather tracking feature, which depended on this geo data, was removed in 2.0.0 as well. See also user and visitor data.
