Покупатель заходит в магазин из Новосибирска, а на первом экране ему предлагают самовывоз из московского пункта и доставку «по Москве за 300 рублей». Он либо вручную ищет переключатель города, либо просто уходит — потому что не поверил, что вы вообще возите в его регион. Автоопределение города по IP снимает это трение: сайт сразу показывает релевантные способы доставки, склад и сроки, а покупателю остаётся подтвердить или поправить город одним кликом.
В этой статье разберём, как в 1С-Битрикс аккуратно определить город по IP, где хранить выбор, как не сломать композитный кэш и связать город со способами доставки, складом и сроками. Тема тесно связана с автоматизацией продаж и склада, поэтому по ходу дадим ссылки на профильные услуги — например, автоматизацию продаж и склада на 1С, откуда приходят остатки по регионам.
Коротко
- IP даёт город с точностью 70–90%, поэтому его нужно предлагать с возможностью исправить, а не переключать всё молча.
- Определение города выносите в некэшируемую зону композита или в отдельный AJAX-запрос, иначе первый посетитель «закэширует» свой город всем.
- Выбранный город храните в сессии и куках и пробрасывайте в свойства заказа, службы доставки и склад отгрузки.
- Всегда держите безопасное значение по умолчанию — оформление заказа не должно зависеть от доступности геосервиса.
Зачем определять город автоматически
Способы доставки, сроки и стоимость в интернет-магазине почти всегда зависят от региона. Пока покупатель не указал город, магазин вынужден показывать либо «средние по больнице» условия, либо условия своего домашнего региона — и то и другое дезинформирует. Автоопределение города решает задачу первого экрана: показать релевантные варианты до того, как человек начал что-то настраивать вручную.
Выгода прямая и измеримая. Покупатель быстрее понимает, довезёте ли вы товар и за сколько, а значит, реже уходит на этапе «а вы вообще в мой город возите?». Для магазина это меньше брошенных корзин и меньше обращений в поддержку с вопросами про доставку. Но у автоопределения есть цена ошибки, поэтому важно не переусердствовать — об этом ниже.
Как IP превращается в город
Технически геолокация по IP — это сопоставление адреса, с которого пришёл запрос, с базой соответствия «диапазон адресов → регион и город». Есть два основных способа получить это соответствие.
- Офлайн-база у себя. Таблица диапазонов разворачивается на сервере и обновляется по расписанию агентом Битрикса. Определение мгновенное и не зависит от стороннего сервиса, но базу надо регулярно освежать.
- Внешний геосервис по API. Запрос уходит наружу и возвращает город. Данные всегда свежие, но появляется сетевая задержка и внешняя точка отказа, которую нужно закрывать таймаутом и кэшем ответов.
В обоих случаях реальный IP клиента нужно получать корректно: за балансировщиком или CDN настоящий адрес приходит в заголовках вроде X-Forwarded-For, и если брать адрес «в лоб», можно определить город прокси, а не покупателя. Это частая причина, по которой «геолокация врёт» — не база плохая, а IP берётся не тот.
Предлагать, а не навязывать
Ключевой принцип: определённый по IP город — это гипотеза, а не факт. Точность на уровне города высокая, но не стопроцентная: корпоративные сети, мобильные операторы с общим пулом адресов, VPN и региональные провайдеры регулярно дают промах. Поэтому город нужно предлагать, а решение оставлять за покупателем.
Плохой паттерн — молча переключить весь сайт на определённый город, поменять цены и регион без спроса. При ошибке геолокации покупатель увидит чужие условия и потеряет доверие. IP — это подсказка для первого экрана, а не команда переключить всё.
Где хранить выбранный город
Как только город определён или выбран, его нужно где-то удерживать, чтобы он пережил переходы между страницами и попал в заказ.
- Сессия. Быстрый доступ в рамках визита: серверный код на любой странице знает текущий город.
- Кука. Долгоживущий выбор между визитами — вернувшийся покупатель сразу видит свой город.
- Свойства заказа. При оформлении город попадает в заказ как свойство местоположения, чтобы менеджер и 1С видели регион отгрузки.
Важно, чтобы ручной выбор всегда побеждал автоопределение: если покупатель однажды указал город сам, IP-гипотезу к нему больше не применяют. Иначе получится раздражающая ситуация, когда сайт упорно «возвращает» человека в неправильный регион.
Город и композитный кэш Битрикса
Здесь кроется главная техническая ловушка. Композитный сайт в 1С-Битрикс отдаёт статическую версию страницы мгновенно и одинаково всем посетителям. Если определять и выводить город прямо в кэшируемой части шапки на стороне сервера, первый посетитель закэширует свой город, и все следующие увидят его же — до сброса кэша.
Правильных решения два, и их часто комбинируют:
- Некэшируемая зона. Блок с городом помещают в динамическую (некэшируемую) область композита, чтобы он считался для каждого посетителя отдельно.
- Догрузка по AJAX. Композитная страница отдаётся общей и быстрой, а персональный город и способы доставки подтягиваются отдельным запросом после загрузки.
Такой подход сохраняет главное преимущество композита — скорость первого экрана, — но делает город и доставку персональными. Про устройство композита и кэша в архитектуре магазина мы подробно писали в материалах по инфраструктуре на BitrixVM и выкладке изменений через CI/CD.
Подстановка способов доставки
Когда город известен, задача — показать покупателю только релевантные способы доставки и их реальную стоимость. Для жителя своего города это самовывоз и курьер, для другого региона — транспортная компания и почта с расчётным сроком.
В модуле «Интернет-магазин» способы доставки настраиваются как службы с профилями и ограничениями. Каждой службе можно задать зоны действия и правила, а расчётные обработчики считают стоимость и срок в зависимости от локации и параметров заказа. Задача автоопределения — заранее подставить в интерфейс те службы, что доступны для города, а не заставлять покупателя перебирать все варианты вручную.
- Фильтрация по зоне. Недоступные для региона службы не показываются вовсе, чтобы не вводить в заблуждение.
- Предрасчёт стоимости. Для доступных способов сразу считается цена и срок по городу.
- Значение по умолчанию. Самый вероятный для города способ подсвечивается как предлагаемый.
Склад отгрузки и сроки по региону
Для магазинов с несколькими складами город определяет ещё и то, откуда поедет товар. От склада отгрузки зависят и наличие, и срок доставки, и иногда стоимость. Поэтому выбранный город логично связывать с приоритетным складом для этого региона.
Схема обычно такая: региону сопоставлен основной склад, с него берётся наличие и рассчитывается срок; если позиции там нет — рассматривается запасной склад с большим сроком. Данные об остатках по складам приходят из учётной системы, поэтому корректность этой логики держится на обмене. Настройку такого обмена и распределение остатков мы закрываем услугой автоматизации на 1С.
Наличие и цена в разрезе города
Наличие и цена тоже могут зависеть от региона, но здесь нужна осторожность. Показывать наличие по складу региона — полезно и безопасно. А вот менять цену только по определённому IP рискованно: при промахе геолокации покупатель увидит чужие условия.
Если магазин по-настоящему мультирегиональный, стоит заранее навести порядок в структуре инфоблоков, ценах и остатках по регионам. Такой аудит — часть услуги аудита и оптимизации 1С: без чистых данных региональная логика всегда будет «подтекать».
Обработчики доставки в модуле магазина
Техническая сердцевина региональной доставки — расчётные обработчики служб доставки. Именно они превращают «город + состав заказа» в конкретную стоимость и срок. Часть служб (популярные транспортные компании и почта) имеет готовые обработчики, но под реальные тарифы бизнеса их почти всегда дорабатывают или пишут свои.
Собственный обработчик доставки — это код, который на входе получает регион и параметры заказа, а на выходе даёт цену и срок. Его пишут по правилам модуля, аккуратно кэшируют внешние запросы к тарифным API и обкладывают таймаутами, чтобы медленный сторонний сервис не тормозил оформление. Разработку и интеграцию таких обработчиков с внешними сервисами удобно вести через REST и вебхуки с продуманной безопасностью, а доступ к данным строить на D7 ORM.
Сценарии, когда город не определён
Геосервис может не ответить, база — не знать диапазон, IP — оказаться «мусорным». Нельзя, чтобы в этих случаях страница зависала или показывала пустой блок доставки. Нужен безопасный сценарий по умолчанию.
- Город по умолчанию. Если определить не удалось, подставляется основной регион магазина как рабочее значение.
- Явное приглашение выбрать. Рядом всегда есть заметная возможность указать свой город.
- Таймаут на геосервис. Внешний запрос ограничен по времени; не ответил — работаем со значением по умолчанию.
- Оформление не блокируется. Покупатель может дойти до заказа, даже если автоопределение полностью не сработало.
Реализация в 1С-Битрикс пошагово
Общая последовательность внедрения выглядит так; названия пунктов зависят от редакции и версии.
- Источник геоданных. Выберите офлайн-базу или внешний API, разверните и настройте обновление агентом.
- Корректный IP. Научите систему брать реальный адрес клиента за балансировщиком или CDN.
- Блок города. Разместите переключатель города в некэшируемой зоне или подгружайте его по AJAX.
- Хранение выбора. Сохраняйте город в сессии и куке, ручной выбор — с приоритетом над IP.
- Связка с доставкой. Отфильтруйте службы доставки по региону и настройте расчётные обработчики.
- Склад и наличие. Сопоставьте региону склад отгрузки, подтяните остатки из 1С.
- Проброс в заказ. Убедитесь, что город попадает в свойства заказа и уходит в 1С.
- Тестирование. Проверьте разные регионы, пустой IP, недоступность геосервиса и приоритет ручного выбора.
Частые ошибки
- Город кэшируется композитом. Определение сделано в кэшируемой части — все видят город первого посетителя.
- Берётся IP прокси. За балансировщиком не читают X-Forwarded-For и определяют город сервера, а не клиента.
- Молчаливое переключение всего сайта. Цены и регион меняются по IP без подтверждения — при промахе покупатель видит чужие условия.
- Нет запасного сценария. Геосервис недоступен, и блок доставки пустой или страница зависает.
- Ручной выбор перетирается IP. Покупатель выбрал город, а сайт упорно возвращает его в определённый по адресу.
- Город не доходит до заказа. В интерфейсе регион есть, а в свойствах заказа и в 1С его нет.
- Внешний геосервис без таймаута. Медленный ответ стороннего API тормозит весь первый экран.
Чек-лист внедрения
- Источник геоданных настроен. База или API работают, обновление идёт по расписанию.
- Реальный IP клиента. Адрес корректно читается за CDN и балансировщиком.
- Кэш не ломается. Город в некэшируемой зоне или догружается по AJAX.
- Выбор устойчив. Город хранится в сессии и куке, ручной выбор в приоритете.
- Доставка релевантна. Службы отфильтрованы по региону, стоимость и срок считаются.
- Склад и наличие по региону. Регион связан со складом, остатки приходят из 1С.
- Заказ знает город. Регион попадает в свойства заказа и в учётную систему.
- Отказоустойчивость. Есть значение по умолчанию, таймаут и рабочее оформление при сбое геосервиса.
Вывод
Автоопределение города по IP — недорогой способ снять трение на первом экране: покупатель сразу видит, довезёте ли вы товар и за сколько. Но работает это только при правильной сдержанности — город предлагают, а не навязывают, ручной выбор всегда побеждает гипотезу, а критичные вещи вроде цены переключают лишь после подтверждения.
Технически ключевых момента два: не сломать композитный кэш (некэшируемая зона или AJAX) и аккуратно связать город со службами доставки, складом и наличием, данные о которых приходят из 1С. Наведите порядок в обмене и региональных данных — и геодоставка станет заметным плюсом к конверсии, а не источником путаницы.
