Динамічні 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 переходять на сторінку App Store; користувачі Android переходять на Google Play; сканери на комп'ютері (хтось фотографує оголошення камерою ноутбука) переходять на веб-додаток.
Як це налаштувати:
- Платформа читає строку User-Agent із запиту сканування.
- Маршрутизуйте
iOS→ URL App Store;Android→ URL Play Store;Other/Desktop→ веб-додаток.
Чому це важливо: Сторінки перенаправлення App Store мають дуже погану автоматичну детекцію платформи. Відправлення користувачів Android на посилання App Store призводить до помилки й убиває конверсії. Маршрутизування за пристроями вирішує це чисто без необхідності реалізації користувацької смарт-сторінки на вашому вебсайті.
Сценарій 4: Комбінування правил (маршрутизування з кількома умовами)
Деякі платформи дозволяють складати правила — наприклад, країна І пристрій. Звичайне налаштування в реальному світі:
| Пріоритет | Умова | Призначення |
|---|---|---|
| 1 | Країна = США + Пристрій = iOS | США App Store |
| 2 | Країна = США + Пристрій = Android | США Play Store |
| 3 | Країна = DE | Німецька сторінка |
| 4 | Резервний | Глобальна сторінка |
Правила оцінюються від верхньої до нижньої, тому порядок має значення. Поставте найспецифічніші умови першими, широкі географічні правила в середині й резервний варіант останнім. Це легко неправильно упорядкувати — завжди тестуйте кожну умову реальним пристроєм і, якщо можливо, VPN, налаштованим на відповідну країну, перед друком.
Що ви можете відстежувати для кожного маршруту
Маршрутизування — це лише половина картини. Кожна URL-адреса призначення повинна мати параметри UTM, щоб ви могли розділити продуктивність за сегментом аудиторії в своїй аналітичній платформі. Скан, маршрутизований на французьку сторінку, повинен запустити ?utm_source=qr&utm_medium=print&utm_content=fr, щоб ви могли розрізнити його від загального скана.
Для більш детального розгляду того, які метрики витягати з вашої панелі QR-кодів, посібник з аналітики QR-кодів, які справді впливають на рішення охоплює детальне відстеження від скана до конверсії.
Ви також можете використовувати журнали маршрутизування, щоб виявити несподіване відрізків трафіку — якщо 40% сканів на друку лише для Великобританії спрацьовують на «британський резервний варіант», ваше налаштування геолокації потребує перевірки перед збільшенням видатків.
Чеклист платформи перед тим, як взяти на себе маршрутизування
Не кожна динамічна платформа QR-кодів підтримує умовне маршрутизування. Перед вибором потвердіть:
- Часові правила доби з виділенням часового поясу (не лише UTC)
- Маршрутизування за геолокацією на рівні країни/регіону
- Детекція типу пристрою (мінімум iOS / Android / Other)
- Підтримка складання правил або мультиумовної логіки
- Аналітика сканування за правилами, не лише загальні показники
- Резервна URL-адреса завжди обов'язкова й редагована
Якщо вашому поточному інструменту не вистачає цього, перейдіть на нашу платформу, яка підтримує умовне маршрутизування за часом, країною й пристроєм з включеною аналітикою для кожного правила.
Основні висновки
- Маршрутизування відправляє різних сканерів на різні URL-адреси з одного надрукованого QR-коду, використовуючи логіку серверного перенаправлення.
- Маршрутизування за часом доби потребує правильного налаштування часового поясу — стандарти UTC помиляються в більшості ринків.
- Маршрутизування за країною використовує геолокацію IP, яка надійна на рівні країни, але не працює для користувачів VPN.
- Маршрутизування за пристроями — це найчистіший спосіб для кампаній завантаження додатків, що потребують розділення iOS та Android призначень.
- Завжди додавайте параметри UTM до кожної маршрутизованої URL-адреси, щоб аналітика потім залишалась розділеною.
- Тестуйте кожне правило маршрутизування реальним пристроєм (і бажано VPN) перед друком у великих масштабах.