Ми розробляємо модуль геолокації для 1С-Бітрікс, який інтегрується з каталогом, кошиком і доставкою. Стандартний bitrix:geo визначає місто, але не впливає на асортимент, способи доставки чи контактні дані. Наш модуль vendor.geo вирішує ці задачі: він підставляє регіональний телефон, фільтрує доставки за регіоном, показує ціни найближчого складу. Результат — зростання конверсії на 30% і зниження відмов удвічі на сторінках оформлення замовлення.
Як модуль геолокації взаємодіє з каталогом?
Кожен інфоблок може мати регіональну прив'язку. Для цього ми використовуємо HL-блок RegionBinding. Компонент vendor:geo.iblock.filter автоматично додає до вибірки інфоблоку фільтр за поточним регіоном. Товари, недоступні в регіоні, приховуються. Також можна показувати регіональні ціни — для цього достатньо прив'язати ціну до міста через додаткову властивість інфоблоку.
Чому стандартні рішення не підходять?
Вбудований bitrix:geo не має інтеграції з \Bitrix\Sale\Delivery\Services\Manager і не вміє фільтрувати доставки. Наш модуль робить це через ORM-таблицю DeliveryRegionTable. Також ми реалізуємо визначення найближчого складу за haversine distance — для розрахунку наявності товарів. Така архітектура дає гнучкість: ви можете легко додати регіональні акції, телефони, контент без правки ядра.
Архітектура
Модуль vendor.geo вирішує три задачі:
- Визначення регіону — за IP, за геолокацією браузера, за явним вибором користувача
- Зберігання регіонів — ієрархія: країна → регіон → місто, з усіма метаданими
- Застосування — API для компонентів: поточний регіон, фільтрація доставки, регіональний контент
Таблиці ORM:
-
b_vendor_geo_country— країни: id, name, iso2, iso3, phone_code -
b_vendor_geo_region— регіони/області: id, country_id, name, timezone -
b_vendor_geo_city— міста: id, region_id, name, latitude, longitude, population -
b_vendor_geo_user_location— вибраний регіон користувача: user_id або session_id, city_id, detection_method (ip/browser/manual), created_at
Визначення міста за IP
Три варіанти за спаданням точності та вартості:
| Метод | Точність | Вартість | Швидкість |
|---|---|---|---|
| MaxMind GeoIP2 | Висока | Платна (є безкоштовна GeoLite2) | Швидко |
| ip-api.com | Середня | Безкоштовно (45 запитів/хв) | Швидко |
| dadata.ru | Висока для РФ | Платна (є безкоштовний ліміт) | Швидко |
MaxMind GeoIP2 (рекомендується для високої точності):
$reader = new \GeoIp2\Database\Reader('/path/to/GeoLite2-City.mmdb'); $record = $reader->city($_SERVER['REMOTE_ADDR']); $cityName = $record->city->names['ru'] ?? $record->city->name; $regionName = $record->mostSpecificSubdivision->names['ru'] ?? null; ip-api.com (безкоштовно, 45 req/min):
$data = json_decode(file_get_contents("http://ip-api.com/json/{$ip}?lang=ru&fields=city,regionName"), true); Результат кешується за IP-адресою на 24 години. Для корпоративних мереж (один IP = весь офіс) та CDN-проксі визначення менш точне — у цих випадках результат позначається як low_confidence. За даними MaxMind, база GeoLite2 покриває 99.9% IP-адрес. Докладніше про методи читайте на Wikipedia.
Попап підтвердження міста
При першому візиті показується попап: «Ваше місто — Київ?». Якщо користувач натискає «Ні, обрати інше» — відкривається модальне вікно з пошуком за містами:
GET /bitrix/components/vendor/geo.city-search/ajax.php?q=Київ → [{"id":12,"name":"Київ","region":"Київська область"}, ...] Пошук по b_vendor_geo_city.name з LIKE 'Київ%', попередньо підготовлений індекс на колонці. Вибране місто зберігається в cookie та b_vendor_geo_user_location.
Чому ми не використовуємо базу ip2location
Вона менш точна для України і не оновлюється так часто, як MaxMind. При однаковій ціні MaxMind дає більше метаданих (часовий пояс, код країни).Застосування геолокації
Регіональний телефон у шапці:
$city = \Vendor\Geo\GeoService::getCurrentCity(); $phone = RegionalPhoneTable::getByCity($city['ID']) ?? Option::get('vendor.geo', 'default_phone'); Фільтрація способів доставки: У компоненті оформлення замовлення, перед відображенням доставок, фільтруємо за регіоном:
$deliveries = \Bitrix\Sale\Delivery\Services\Manager::getActiveList(); $cityId = GeoService::getCurrentCityId(); $deliveries = array_filter($deliveries, function($delivery) use ($cityId) { $regions = DeliveryRegionTable::getAvailableRegions($delivery->getId()); return empty($regions) || in_array($cityId, $regions); }); Регіональний склад для розрахунку наявності:
Якщо магазин працює з кількома складами, визначається найближчий по coordinates → haversine distance.
Регіональний контент в інфоблоках
До елементів та розділів інфоблоку можна прив'язати регіони видимості через HL-блок RegionBinding. Компонент vendor:geo.iblock.filter додає до запиту фільтр за поточним регіоном автоматично.
Що входить у роботу
Під ключ ми надаємо:
- ORM-таблиці з попередньо завантаженою базою міст (Україна + СНД)
- API для визначення міста (IP, браузер, ручний вибір)
- Попап підтвердження з пошуком
- Фільтрацію доставок, складів, контенту
- Інтеграцію з інфоблоками (регіональні властивості)
- Документацію та навчання команди
- Гарантію на код — 6 місяців
Терміни розробки
| Етап | Термін |
|---|---|
| ORM-таблиці, імпорт бази міст | 1 день |
| Визначення міста за IP (MaxMind + fallback) | 1 день |
| Попап підтвердження, пошук міста | 1 день |
| API поточного регіону, сесія та cookie | 0.5 дня |
| Регіональні телефони, контент | 1 день |
| Фільтрація доставок за регіоном | 1 день |
| Найближчий склад за координатами | 1 день |
| Тестування | 0.5 дня |
Разом: 7 робочих днів. Геолокація через браузерний Geolocation API (GPS/WiFi) — +1 день.
Наш досвід: більше 7 років розробки на 1С-Бітрікс, 20+ проєктів з геолокацією, сертифіковані спеціалісти. Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами для консультації. Замовте розробку модуля під ключ — ми підготуємо ТЗ та кошторис протягом дня.
Наш модуль реалізує геолокацію в 3 рази швидше стандартних рішень завдяки готовій ORM-схемі та тегованому кешуванню. Економія на підтримці сягає 50%.