Bulk GEO IP Locator

Search Engine Optimization

Bulk GEO IP Locator


Processing...

Your IP City Region Country Country Code ISP Latitude Longitude

 
Try New IP

About Bulk GEO IP Locator

Why do you need GeoIP

Are you faced with the task of showing different phones / prices / availability of goods depending on the user's city? Or maybe you want to make it easier for the user to checkout? - These tasks run into the automatic detection of the country / city by IP-address.

Is it difficult to determine a user's location by IP address? Perhaps not difficult. But to do it efficiently is not a task for the faint of heart. There are several reasons for this:

  1. The detection accuracy is extremely low and varies depending on the base of IP addresses
  2. IP addresses are constantly changing location, and site owners forget to update databases
  3. Developers are tempted to take a crooked path and start accessing online services.
  4. Developers are too lazy to do caching
  5. The city name returned by geo-bases is difficult to relate to site locations and business logic.
  6. Bitrix does not have a ready-made component for displaying / changing the city

The difference in labor intensity between “it will do” and “reliable solution” is 20-40 man-hours. We stuffed bumps for a long time, and when we got tired of it, we collected all our developments in one cool module for 1C-Bitrix .

Under the hood of the geo-module

Several GEO IP bases to choose from

There are 4.22 billion IPv4 addresses in total. They are divided between countries. Within countries between internet operators. The latter, in turn, distribute them between the cities of presence. And then they are redistributed as needed.

There are special registers where this very distribution is recorded. For the purposes of this article, we will call them GeoIP-bases. They differ in frequency of updating, accuracy and volume of additional data (city names in several languages, postal codes, names of Internet operators).

In the module, we support 3 common geo-bases:

  • MaxMind,
  • IpGeoBase ,
  • Sypex Geo

and one “meta-base”: MaxMind + IpGeoBase.

MaxMind locates all the way to cities around the world. But it is rarely updated (free version once a month). On the other hand, IpGeoBase works well only in Russia and Ukraine, but it is updated every day.

The “meta base” determines the location first by IpGeoBase. If the country is defined as Russia or Ukraine, the data is considered the most accurate. If the country is different, we turn to MaxMind.

Independence from encodings

Different databases are stored in different encodings (CP1251, UTF-8). And sites can be in different encodings. It was not easy, but we have implemented the correct operation of all geo-bases for sites in both encodings.

High speed of work

Almost all geo-databases can be accessed both via web services and locally (after downloading).

Novice developers often choose the first option. It is understandable, it is simpler and you do not need to worry about updating the databases. But there are 2 fly in the ointment:

  • The web service will freeze - the site will also freeze. The web service "died" - the site does not open at all.
  • A web service call is a network request. And this, in turn, is the “longest” operation in programming (10-100% of the time it takes to form the entire page).

We (INTERVOLGA) have seen many examples when developers went this way and got a bunch of problems with the speed of the site.

Our module works exclusively with local geo-bases. In addition, we have implemented caching of queries to these databases. As a result, the determination of the location by IP has practically no effect on the speed of the site.

Automatic updating of geo-bases

Local geo-bases are reliable. But they need to be updated. And no one remembers about it.

Especially for this case, we have implemented an automatic update of these same databases: only necessary ones, only if they have changed, with the frequency required for a specific database, with the subsequent reset of the cache of geo-queries.

There are several ways to choose from: on agents (default), on hits and on CRON.

Communication with Bitrix locations

Geobases return the textual name of the country and city. But without being tied to the logic of the site's work, there is zero sense from this.

Let's take a closer look at why you need to determine the position of the user at all:

  1. Show availability and / or cost of delivery in a specific city in the product card.
  2. Select a city by default in the order form.
  3. Show different phone numbers in the header for Moscow, St. Petersburg, City X and the default phone number for everyone else.

Unfortunately, in the program code, you will only recognize the name of your visitor's city. For example, Volgograd. This is enough for one of the three tasks.

For the other two tasks, you will need to compare the text name of the city from the geo-base with the locations of 1C-Bitrix . And they are tree-like, and the names of cities with geo-bases do not coincide (“Volgograd” vs “Volgograd”) ...

We have implemented such a comparison with a tricky algorithm and consider the resulting result to be of sufficient quality.

Integration with the new Bitrix API for geolocation

Since version 17.0.9 of the main module, geolocation services have been added to the BUS and we have implemented the integration of our module with this new API.

Widgets and Components

The module has 2 components:

  • User location.
    The widget shows the current city of the visitor with the ability to change.
  • Autolocation.
    A button when clicked on which the location is determined and the page reloads. Additionally, this component implements the definition of a city based on Yandex.Maps (more precisely, but only works in the browser - not on the server).

More details about their use are below.

More information about the browser

In addition to determining the GEO IP, we have built in our module the determination of information about the visitor's browser (operating system, mobility, language, etc.) based on the “User Agent” browser parameter.

This information is rarely needed, but it came in handy in a couple of projects.