Динамические QR-коды не обязаны отправлять всех сканирующих на один и тот же URL. Условная маршрутизация — её также называют маршрутизацией сканирований или правилами перенаправления — позволяет направлять разные аудитории на разные адреса, используя один напечатанный код. Если вы когда-то мечтали, чтобы листовка к обеду перенаправляла на меню, вечерний поток посетителей — на форму бронирования, а международных посетителей — на локализованную страницу, то эта функция работает ровно для этого.
Вот как работают самые полезные сценарии маршрутизации, что нужно настроить в первую очередь и где люди часто допускают ошибки.
Что на самом деле означает «маршрутизация» в контексте динамического QR
Когда сканирующий нажимает на динамический QR-код, целевой URL хранится на сервере — не встроен в сам код. Именно на сервере живёт логика перенаправления. Вместо плоского перенаправления («все сканирования → URL A») вы добавляете условные правила:
- Если условие выполнено → отправить на URL A
- Иначе → отправить на URL B (резервный адрес)
Большинство платформ, поддерживающих эту функцию (иногда её называют «мультиURL QR-коды» или «умные перенаправляющие QR-коды»), позволяют наложить два-три правила. Резервный URL всегда обязателен. Понимание разницы между статическим и динамическим поведением здесь критично — полное руководство о статических и динамических QR-кодах объясняет, почему логика перенаправления находится на сервере и почему это важно для маршрутизации.
Сценарий 1: маршрутизация по времени суток
Случай использования: кафе печатает один QR-код на настольной палатке. Утренние сканирования показывают меню завтрака; дневные — меню обеда; вечерние — список напитков.
Как настроить:
- Создайте три целевых URL (или разделы страницы) для каждого периода меню.
- Добавьте временные правила в UTC — не забудьте учесть смещение вашего локального часового пояса.
- Установите наиболее частый вариант использования в качестве резервного на случай, если сканирование произойдёт вне определённого времени.
Где это ломается: команды забывают, что время сканирования регистрируется на сервере в UTC по умолчанию. Правило, установленное на «11:00–14:00» без настройки часового пояса, будет срабатывать в неправильные часы для сканирующих в вашем городе. Всегда проверьте обработку часовых поясов на вашей платформе перед печатью.
Другие практические примеры:
- Площадки для событий, маршрутизирующие на программу до 19:00, затем на товары после 21:00
- Розничные магазины, показывающие лендинг вспышки продаж только в окна продвижения
- Спортзалы, отправляющие расписание занятий по будням и выходное расписание на выходные
Сценарий 2: маршрутизация по стране или языку
Случай использования: коробка товара отправляется в 12 стран. Один QR-код маршрутизирует англоязычные рынки на страницу поддержки на английском, франкоязычные рынки — на французскую версию, остальных — на селектор языка.
Как настроить:
- Движок маршрутизации определяет страну сканирующего по геолокации IP.
- Свяжите коды конкретных стран (US, GB, CA → англ. страница; FR, BE, CH → фр. страница; DE → немецкая страница).
- Установите страницу селектора языка как глобальный резервный адрес.
Оговорки для внутренней документации:
- Геолокация IP точна на уровне страны примерно на 95–99%, но пользователи VPN будут маршрутизированы неправильно. Это приемлемо для большинства случаев использования.
- Не маршрутизируйте по предпочтению языка, определяемому из браузера — запросы сканирования QR-кодов не надёжно передают заголовки Accept-Language через все приложения.
- Если ваша платформа взимает плату за целевой URL или за каждое правило, группируйте страны вместе, а не перечисляйте 40 отдельных стран.
Сценарий 3: маршрутизация по типу устройства
Случай использования: объявление компании-разработчика печатается как в торговом журнале, так и в рассылке для разработчиков. Пользователи iOS переходят на AppStore; Android — на Google Play; сканирующие с рабочего стола (кто-то фотографирует объявление на веб-камеру ноутбука) попадают на веб-приложение.
Как настроить:
- Платформа читает строку User-Agent из запроса сканирования.
- Маршрутизируйте
iOS→ AppStore URL;Android→ Play Store URL;Other/Desktop→ веб-приложение.
Почему это важно: страницы перенаправления AppStore печально известны плохой автоматической идентификацией платформы. Отправка пользователей Android на ссылку AppStore вызывает ошибку и убивает конверсии. Маршрутизация по устройствам решает это проблему чисто и элегантно, не требуя пользовательской реализации умного баннера на вашем сайте.
Сценарий 4: объединение правил (маршрутизация с несколькими условиями)
Некоторые платформы позволяют складывать правила — например, страна И устройство. Типичная реальная настройка:
| Приоритет | Условие | Адрес назначения |
|---|---|---|
| 1 | Страна = US + Устройство = iOS | US App Store |
| 2 | Страна = US + Устройство = Android | US Play Store |
| 3 | Страна = DE | Немецкая лендинг-страница |
| 4 | Резервный | Глобальная лендинг-страница |
Правила оцениваются сверху вниз, поэтому порядок имеет значение. Поместите самые специфичные условия в начало, широкие географические правила в середину и резервный адрес в конец. Это легко неправильно упорядочить — всегда тестируйте каждое условие с реальным устройством и, если возможно, с VPN, установленным на соответствующую страну, перед печатью в масштабе.
Что вы можете отследить по каждому маршруту
Маршрутизация — это только половина. Каждый целевой URL должен содержать UTM-параметры, чтобы вы могли разделить производительность по сегментам аудитории в своей аналитической платформе. Сканирование, маршрутизированное на французскую страницу, должно срабатывать с ?utm_source=qr&utm_medium=print&utm_content=fr, чтобы вы могли отличить его от простого сканирования.
Для более глубокого изучения того, какие метрики извлекать из вашей QR-панели, руководство по аналитике QR-кодов, которая реально влияет на решения подробно рассматривает отслеживание от сканирования к конверсии.
Вы также можете использовать журналы маршрутизации, чтобы выявить неожиданные паттерны трафика — если 40% сканирований в распечатке, предназначенной только для Великобритании, вызывают «резервное перенаправление для не-UK», ваша настройка геолокации нуждается в проверке перед масштабированием расходов.
Чек-лист платформы перед выбором маршрутизации
Не каждая динамическая QR-платформа поддерживает условную маршрутизацию. Перед выбором подтвердите:
- Правила по времени суток с выбором часового пояса (не просто UTC)
- Маршрутизация по геолокации на уровне страны/региона
- Определение типа устройства (iOS / Android / Прочее как минимум)
- Поддержка складывания правил или мультиусловий
- Аналитика сканирований по каждому правилу, а не только агрегированные итоги
- Резервный URL всегда обязателен и редактируем
Если ваш текущий инструмент не поддерживает это, Super QR Code Generator поддерживает условную маршрутизацию по времени, стране и устройству со встроенной аналитикой по каждому правилу.
Ключевые выводы
- Маршрутизация отправляет разных сканирующих на разные URL с одного напечатанного QR-кода, используя логику серверного перенаправления.
- Маршрутизация по времени суток требует правильной настройки часового пояса — UTC по умолчанию будет срабатывать неправильно в большинстве рынков.
- Маршрутизация по стране использует геолокацию IP, которая надёжна на уровне страны, но не работает для пользователей VPN.
- Маршрутизация по устройству — самое чистое решение для кампаний загрузки приложений, которым нужно разделить назначения iOS и Android.
- Всегда добавляйте UTM-параметры к каждому маршрутизируемому URL, чтобы аналитика оставалась сегментированной.
- Тестируйте каждое правило маршрутизации с реальным устройством (и в идеале с VPN) перед печатью в масштабе.