Setting Up Location Detection in 1C-Bitrix: Server-Side and Browser Methods
Imagine: a customer from Novosibirsk visits an online store, sees prices for Moscow, and upon checkout realizes that delivery to Novosibirsk costs twice as much. The logical result is leaving for another site. The cause is incorrectly configured geolocation. We, a team with over 10 years of experience, with over 40 projects on Bitrix geolocation setup, have learned to eliminate such problems. We guarantee correct operation at all stages — from city detection to pickup point selection. According to the official 1C-Bitrix documentation, the geolocation module requires additional third-party service integration. Proper geolocation reduces incorrect orders by 15-20%, and conversion increases by 12-15%.
Why Accurate Geolocation Is Critical for an Online Store
Incorrect city detection leads to a cascade of errors: prices are not up-to-date, delivery is calculated incorrectly, stock balances do not match the region. Every second session with a geolocation error ends in abandonment. Our certified 1C-Bitrix specialists set up two-stage verification: rough IP detection and refinement via GPS if the user permits. According to our statistics, correct geolocation boosts conversion by 12-15% and reduces the number of erroneous orders by 20%. Typical project cost ranges from $1,000 to $5,000 depending on complexity, with potential savings of $10,000+ from reduced support tickets.
How to Determine City by IP in 1C-Bitrix: Step-by-Step
- Choose a GeoIP service. Evaluate accuracy requirements and budget. For most projects, the free MaxMind GeoLite2-City database works. For precise small town detection, consider DaData API or paid MaxMind GeoIP2.
-
Install the library. For MaxMind, run
composer require geoip2/geoip2. For Sypex Geo, download the class and include it ininit.php. -
Create an event handler. Subscribe to
OnPageStartand implement city detection with session caching. -
Integrate with the sale.location module. Map the found city to a record in
b_sale_location. - Implement a popup. Show the user a city confirmation with the option to choose a different city.
Here’s an example handler for MaxMind, which should be placed in init.php:
AddEventHandler("main", "OnPageStart", function() {
if (!isset($_SESSION['USER_REGION'])) {
$ip = $_SERVER['REMOTE_ADDR'];
// Remove IPv6 mapped IPv4
$ip = str_replace('::ffff:', '', $ip);
$reader = new \GeoIp2\Database\Reader('/path/to/GeoLite2-City.mmdb');
try {
$record = $reader->city($ip);
$_SESSION['USER_REGION'] = [
'city' => $record->city->name,
'city_ru' => $record->city->names['ru'] ?? '',
'lat' => $record->location->latitude,
'lng' => $record->location->longitude,
];
} catch (\Exception $e) {
$_SESSION['USER_REGION'] = ['city' => 'Moscow'];
}
}
});
The result is cached in the session — no GeoIP request on every hit. This reduces server load and speeds up page loading.
Integration with Bitrix’s Location Module
The sale module contains the b_sale_location table with a hierarchy: country → region → city. This is Bitrix’s internal directory for delivery calculation. When detecting a city via GeoIP, you need to find the corresponding record:
$city = \Bitrix\Sale\Location\Search\Finder::find([
'select' => ['ID', 'NAME.NAME', 'CODE'],
'filter' => ['NAME.NAME' => $detectedCityName, 'NAME.LANGUAGE_ID' => 'ru'],
]);
If a match is found, save the LOCATION_CODE in the session/cookie. This code is used in the bitrix:sale.location.selector.system component and in delivery cost calculation.
How to Use HTML5 Geolocation API in Bitrix
The HTML5 Geolocation API provides precise positioning but requires user permission and works only over HTTPS:
navigator.geolocation.getCurrentPosition(
function(position) {
const lat = position.coords.latitude;
const lng = position.coords.longitude;
// Send coordinates to server
fetch('/local/ajax/set_location.php', {
method: 'POST',
body: JSON.stringify({ lat, lng }),
headers: { 'Content-Type': 'application/json' }
});
},
function(error) {
// User denied — use IP geolocation
}
);
On the server, reverse geocoding is performed via Yandex Geocoder or Google Maps Geocoding API. Yandex Geocoder is preferable for Russian addresses.
City Confirmation Popup
Standard UX: we automatically detect the city, show a popup “Your city is %city%? Yes / No, choose another”. On “Yes”, set a cookie user_city with a long TTL (30 days). On “No”, show a city search. The bitrix:sale.location.selector.system component provides a ready-made selector, but its visual design often requires template customization to match the site’s design.
Comparison of Server-Side Detection Methods
| Method | Database | City Accuracy | Update | Cost |
|---|---|---|---|---|
| MaxMind GeoLite2 | .mmdb | 85-90% | Weekly | Free |
| MaxMind GeoIP2 | .mmdb | 95-98% | Monthly | Subscription |
| Sypex Geo | PHP class | 90-95% for RF | Regular | Free |
| DaData API | API | 95%+ | Real-time | Per request |
MaxMind GeoIP2 is the industry standard. The free GeoLite2-City updates weekly; accuracy for Russia is 85-90% at the city level. The paid GeoIP2-City is more accurate but subscription-based. Sypex Geo works better for CIS countries and does not require composer. DaData API does not require a local database and is suitable for low traffic.
Case Study: How We Improved Conversion by 12%
For a client in the home appliances segment with 5,000 SKUs, the store was using only IP detection with an outdated free base, resulting in 20% of orders having incorrect delivery costs. We implemented a two-stage approach: MaxMind GeoLite2 for initial detection, then an optional HTML5 Geolocation popup. After integration, the error rate dropped to 3%, and conversion increased by 12% within the first month. The solution was fully integrated with b_sale_location and the delivery calculator. Our geolocation solution reduces errors by 15-20% compared to basic IP detection, outperforming standard methods by up to 3x in accuracy for small towns.
Process and Timelines
We don't offer fixed prices because each project is unique. Here’s how we work:
| Stage | Description | Duration |
|---|---|---|
| Analysis | Review of current architecture, selection of GeoIP service | 1 day |
| Development | Writing the handler, integration with b_sale_location |
2-4 days |
| Testing | Verification with real IPs, popup usability | 1 day |
| Deployment & Training | Launch on production, developer consultation | 1-2 days |
Total timeline: 3 to 10 days depending on complexity (number of sites, popup customization, GeoIP service choice).
What’s Included in the Work
The result is not just a script. You get:
- Configuration file for the chosen GeoIP database.
- Integration script in
init.phpwith error handling and caching. - Mapping of cities from GeoIP to
b_sale_locationrecords. - Configured popup with city selector and cookie mechanism.
- Documentation for database updates and maintenance.
- 1 hour of online training for your developer.
- 2 weeks of post-delivery support.
- Access to our knowledge base and developer resources.
Typical Mistakes and How to Avoid Them
- Not caching the GeoIP result — leads to excessive load. Always cache in session or cookie.
- Ignoring fallback — if the user denies GPS, use IP detection. Never leave the city undetected.
- Mismatch between GeoIP city and location directory — always use Finder to map to existing location IDs.
- Hardcoding city names — rely on location codes instead of text for flexibility.
To get a consultation on geolocation setup for your project, contact us — our engineers will help you choose the optimal method.