Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Segmenting analytics by country without a tracking script
Most analytics platforms answer "where are my visitors coming from" by loading a script in the visitor's browser and reporting back whatever it can gather. A publisher trying to keep its pages fast and its script footprint small wanted the same answer without adding one more piece of client-side code that had to load, execute, and report before the number appeared in a dashboard.
The alternative was already sitting in the request the publisher's own server handled for every page view: the visitor's IP address. Passed to /v1/ip, that address resolves to country, region, city, postcode, coordinates, time zone, ASN and organization, all without the visitor's browser doing anything at all. The publisher's server logged the country and region fields alongside each page view it was already recording, and country-level traffic segmentation became a report generated from data the server already had, rather than a data source that had to be added.
This is a meaningfully different approach from a pixel or a beacon. Nothing was fired from the visitor's browser back to a third party, and nothing depended on a script surviving an ad blocker or a privacy setting that silently drops third-party trackers, which is a real and growing share of traffic on most sites. The lookup ran entirely server-side, at the moment the request was already being processed, and the result was recorded directly rather than inferred from whatever fraction of visitors' browsers cooperated with a script.
The publisher used the resulting country data for two things right away. Editorial could see, for the first time with real confidence, which countries were reading which sections, since the country field was attached to every page view rather than only the subset that a JavaScript-based tool managed to capture. Ad sales could report geographic reach to advertisers using the same underlying numbers the editorial team was already looking at, rather than maintaining two separate, sometimes disagreeing, analytics systems.
None of this required storing anything unusually sensitive. Country and region level detail is coarse by nature, useful for aggregate reporting rather than for identifying an individual visitor, and the publisher's retention policy for this data followed the same rules it already applied to its server logs generally.
Volume tracked page views directly, which for a publisher of any real size will move usage past the free daily allowance and into prepaid credit fairly quickly, at €0.0001 a request, or make an Unlimited key at €50 a month the simpler option once volume is high and predictable. Either way, the math was straightforward to run against the cost of a third-party analytics platform charging for the same country breakdown, often for less reliable data because of how much a script-based approach misses.
The bigger shift was philosophical as much as technical: location for analytics purposes does not need to come from something running in the visitor's browser. It can come from the same server that is already handling the request, using data the server already sees. Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/.