Geo Targeting and Country Analytics: Reading Location Data Honestly

A country chart is the first thing a link tool shows and the last thing that changes a decision. Thirty-eight percent of a campaign came from one country: that says nothing about whether those people were in that country, what network carried them, or what time it was where they were standing.

This guide covers the layer underneath the country chart: where country, region and city actually come from, what the accuracy radius means, why the network a visitor arrived on is a separate axis from the place they arrived from, how activity by the visitor's local hour differs from activity in your reporting time zone, what routing by country and language does and where it stops, and the three mistakes that reliably turn location data into confident wrong answers.

Where Country, Region and City Come From

Two sources answer the same question at different levels of detail, and knowing which one answered matters more than the answer itself.

The network answers first

Every request that reaches a redirect on an edge network arrives already carrying fields the network resolved itself: country, region, city, approximate coordinates, time zone, the autonomous system number and the name of the organisation that holds it. These cost nothing — no database read, no round trip — and they are sufficient for any decision that only needs a country, which is why they are what fast routing runs on.

A licensed database answers in more detail

A commercial geo database, repacked offline into a format built for single-read edge lookups, adds what a network-level answer does not carry: the accuracy radius of the city, the GeoNames identifiers behind region and city, stable place names in eight languages, the proxy type of the address range, and an autonomous system number where the network did not supply one. The geography and traffic quality breakdowns are built on that layer.

The interesting part is the failure mode. If the pack cannot be read, redirects keep working and analytics keeps recording: the resolver falls back to the network-level answer and marks the row with the source that produced it, so a chart never silently mixes precise and approximate data. Fallback rows have no city identifier and no accuracy radius, and the interface says so rather than leaving you to infer it.

Identifiers, not names

A click event stores an identifier, never a localised place name. This sounds like an implementation detail and is actually the difference between one row and two: "Bavaria" and "Bayern" are the same GeoNames identifier, and a report that stored strings would rank them as separate regions forever.

Names are resolved when a report is read, from the dictionary of the language the reader is using: eight of the ten dashboard languages have place names, and the other two fall back to English rather than to an empty cell. The language comes from the reader's own account setting rather than from a request parameter, because a parameter would let one person pin their language into a cache the whole workspace shares.

The Accuracy Radius Keeps the Map Honest

A city record is not a location. It is a point plus a radius, and the radius is the part that tells you what the point is worth. Twenty kilometres describes a range of addresses that an operator assigned somewhere in that area; it does not describe a person, a neighbourhood or a store catchment.

Two design choices follow. Coordinates are stored as whole ten-thousandths of a degree, because extra decimal places manufacture precision the source data does not have. And a radius of zero means "unknown", not "exact" — worth checking before anyone builds a map from an export.

The practical rule: use city data to compare markets and spot concentrations, not to conclude anything from a handful of records, and not at all on rows answered by the fallback path.

City and Network Are Different Axes

The place a click came from and the network it came through are separate questions, and answering only the first is how media buyers pay for traffic that never had a chance of converting. The network breakdown lists the autonomous system number, the provider name, the proxy type of that range, and — the column that does the work — human clicks alongside total clicks. The gap between those two columns on one provider is usually the entire finding.

| Range label | What the range is | | --- | --- | | Data centre | Hosting, cloud and colocation address space | | Public proxy | Open proxies anyone can route through | | VPN | Commercial VPN exit ranges | | Search robot | Published crawler ranges of search engines | | TOR | Exit nodes of the TOR network | | Web anonymiser | Browser-based proxy services |

Ranges belonging to none of these are ordinary addresses, and the largest labelled group by far is data centres rather than consumer VPNs. That label is combined with other signals — verified crawler lists, reverse DNS for robots that publish no list, user agent patterns, request behaviour — into a visitor type and a quality score from 0 to 100 with its reasons attached. The score blocks nothing by itself: blocking is what you configure in traffic rules, and the score exists to explain a decision and feed the report. Classification mechanics are covered in traffic filtering.

One deliberate asymmetry: three panels — filtered traffic, traffic quality and networks — include automated traffic even when "exclude bots" is on, because excluding bots there would empty out the screens you opened in order to look at bots. Everywhere else the filter behaves normally, and automated traffic never consumes a plan's tracked-click allowance.

Activity by the Visitor's Clock

A report can be rendered in one time zone. Every click has its own. Convert stored timestamps into a workspace time zone and an evening peak in three markets flattens into a plateau that suggests your audience has no schedule.

The local hour is therefore computed when the click is written, from the time zone resolved for that visitor, and stored on the row — the only point in the pipeline where the visitor's own time zone is still known. What it buys is a send-time answer that survives a multi-market campaign: the hour at which your audience actually opens things, rather than the hour your server was busy.

The honest cost is that the caveats of the location answer propagate. A click routed through an exit node in another country carries that country's hour, and a row answered by the fallback path carries whatever time zone the network reported. Local-hour charts are worth reading alongside the network breakdown for the same reason the city chart is.

Routing by Country and Language

One short address, different destinations: a German visitor lands on the German store, a French-speaking Belgian visitor on the French page, everyone else on the main site. Targeting rules are an ordered list, conditions inside a rule are combined with AND, and the first complete match wins. Ordering by hand rather than by a specificity score is a deliberate trade: an ordered list can be read aloud, and a precedence table cannot be debugged at all once it has more than three entries.

Language matching has one rule worth memorising: en covers every regional variant, so en-GB and en-US both match it, while en-GB requires an exact match and will not catch American English. Write the broad rule when you mean the language and the specific one when you mean the market.

Missing data never turns into a block. If a condition cannot be evaluated — the country is unknown, the pack was unavailable — the rule simply does not match and the visitor continues to the base destination. In traffic rules the same principle is explicit: every condition is three-valued, true, false or unknown, a rule with an unknown condition is skipped whole, and negation works only on known data, so "allow only these countries" does not lock out the world when a lookup fails.

The pipeline order is fixed: traffic rules first, because they answer "should this request be served at all", then targeting, then any split test, then the base destination. Per-destination country filters in the rotator are a fourth place where geography narrows a choice: targeting decides where a market goes, the rotator decides how that market's traffic is shared.

Routing is not swapping content

The distinction matters more than it looks. Routing chooses which real destination a person is sent to, and every destination is a page anybody can open and see in full. Swapping content means one address renders different things depending on who is asking — and the version of that practice search engines object to is showing a crawler something a person would never see.

The redirector does not render or rewrite destination pages; it answers with a redirect and the destination serves itself. The one place where a request gets something other than a redirect is a social preview crawler, which is answered with the link's own preview markup so a shared link renders the same card regardless of where the crawler runs. That is a preview, not a substitute page.

Rules can also treat verified crawlers differently: let them through, close the link, send them to a stub page. The platform gives you the mechanism, a preview of which rule would fire for a given visitor profile before a single click happens, and a log of what fired afterwards. Whether a crawler should receive something different from what a person receives is a decision you own, and the log is what makes it auditable.

Three Ways Geo Data Produces Confident Wrong Answers

Reading a market off traffic that was not in that market. A country climbing your chart is not evidence of demand until you have looked at what carried it. If most of its clicks arrive from data centre ranges or commercial VPN exits, you are looking at where exit nodes are, not where buyers are. This is the most expensive mistake in the list because it produces a plan: budget moves, creative gets localised, and none of it reaches a person.

Ranking countries without ranking their volume. A market with 90 clicks and a 4.4 percent conversion rate is not outperforming a market with 9,000 clicks and 3.9 percent; it is a market where four extra events would swing the number by more than the gap you are excited about. Set a floor for the volume at which a country enters a ranking at all, and compare the observed difference against how much a handful of events would move it. The point is not statistical purity, it is not reorganising a quarter around noise.

Trusting a city when the data only supports a region. City rows come with radii, and some rows have no city at all. A campaign built for one metro area on rows whose radius covers half a country is a plan built on a rounding artefact. When the question genuinely needs a city — a store opening, an event, a local promotion — check how many of the underlying rows carry a city identifier and what their radii look like before committing. When they do not support it, use the region, which is stable, identifier-backed and far harder to misread.

A fourth habit stops the three from compounding: read geographic breakdowns next to the click-quality caveats in tracking link clicks, and remember that unique visitors is a daily metric — a monthly country comparison sums daily uniques rather than counting distinct people.

What the Data Deliberately Does Not Contain

The visitor's address is never stored. It exists inside one function long enough to produce a daily salted fingerprint and to look up the address range, and it does not reach the event. The postal code is resolved by the database and deliberately not recorded, because in dense housing a postal code is close to an address.

How much of the rest is stored is a workspace setting, applied when the event is written rather than when it is read.

| Level | What is stored | | --- | --- | | Full | Country, region, city, coordinates, accuracy radius, time zone, local hour | | City without coordinates | Country, region, city, time zone, local hour | | Country only | Country and continent |

Separate switches cover the visitor's network, the full referring address and traffic-type detection. Retention is written into each event as a number of days, which is a different thing from a plan limiting how far back you may look, and changes reach live links within seconds rather than at the next cache expiry. Details are in privacy modes and the geography guide.

One output limit is easy to assume wrongly: a link's public statistics page shows only country and city from all of this — no networks, no traffic type, no quality score, no coordinates. That boundary is checked by a test on the shape of the response rather than left to convention.

A Setup That Survives Scrutiny

1. Read the network breakdown before the country chart on any campaign you pay for, comparing human clicks against total clicks per provider.
2. Set a minimum click volume below which a country does not enter a ranking, and write it down so it is not renegotiated per meeting.
3. Check the accuracy radius before any decision that depends on a city, and fall back to the region when it does not support one.
4. Preview what a given visitor profile would receive before publishing targeting rules, rather than testing in production with your own traffic.
5. Choose a geo detail level deliberately: it decides what gets written, and nothing turned off can be recovered later.
6. Reconcile analytics against destination-side data once per campaign, especially in markets where the two disagree most.

Location data works best as two questions instead of one: where the request appears to come from, and what carried it. The first alone always produces a chart; the second is what makes the chart worth acting on. Media buyers hit this earliest, which is why the affiliate setup leans on the network and quality axes rather than on the map.