Події тримаються на посиланнях. Посилання на реєстрацію, посилання спікерів, посилання спонсорів, QR-коди на бейджах, ланцюжки follow-up. Коли шар посилань безладний — обліковий запис Bitly для команди реєстрації, Google-форма для сесій, список Sendinblue для follow-up — атрибуція зламана ще до відкриття події. Ця стаття — про архітектуру посилань, яка справді працює для конференції на 200 або виставки на 2000 осіб.
Для глибокого занурення в тему QR стаття QR-кампанія з нуля охоплює QR-дизайн виробничого рівня та рішення «статичний vs. динамічний». Ця стаття — про ширший контекст життєвого циклу події.
Чотири стадії посилання для події#
У кожної події є ті самі чотири стадії. На кожній стадії — різні вимоги до базового посилання.
1. Реєстрація#
Посилання, що залучають реєстрації. Вони з'являються на:
- CTA лендингу події
- Email-запрошеннях
- Промоматеріалах партнерів
- Публікаціях спікерів у соцмережах («приходьте послухати мій виступ про X»)
- Розміщеннях спонсорів
Що важливо: UTM-атрибуція за джерелом. Спонсор повинен знати, скільки реєстрацій прийшло з його публікації; спікер хоче того самого; email-команда вимірює за розсилкою. Один короткий домен (go.yourevent.com) для послідовності бренду. Кожне посилання позначене UTM-мітками source/medium/campaign.
Антипатерн: «сирі» URL вендора (нативний URL форми реєстрації), поширені скрізь. Ви не отримуєте ні атрибуції, ні послідовності домену. Варто скорочувати кожне посилання на реєстрацію, навіть якщо коротка довжина не є суворою необхідністю.
2. Бейдж#
Кожен учасник отримує бейдж. На бейджі — QR-код. QR-код веде на сторінку профілю.
Що важливо: QR має надійно зчитуватися на будь-якому телефоні (деякі не читають коди з низьким контрастом, деякі погано справляються на відстані понад 2 м), а призначення має завантажуватися швидко при великому одночасному навантаженні (вхід у день-1 вранці може видати 200 одночасних сканувань до вашого ендпоінту).
Антипатерн: запекти URL сайту конференції в бейдж як звичайний QR. Після цього ви не можете змінити призначення після друку бейджа. Статичний QR постійний; динамічний QR (де QR резолвиться через сервіс коротких посилань) дозволяє змінити призначення після друку — корисно, коли в день-2 розклад має відображатися інакше, ніж у день-1.
Для детального вивчення рішення «статичний vs. динамічний» — стаття динамічні vs. статичні QR-коди є докладним матеріалом на цю тему.
3. Сесія#
Кожна сесія має посилання. Слайди, додаткові матеріали, CTA «підпишіться на розсилку спікера», форма «оцініть сесію».
Що важливо: послідовність між сесіями, атрибуція на рівні кожної сесії (яка сесія мала найвищий рівень залученості?), а посилання має бути достатньо коротким, щоб продиктувати зі сцени, якщо трансляція QR-коду на екрані не спрацювала (це ніколи не спрацьовує).
Антипатерн: кожен спікер приносить своє коротке посилання від свого вендора. Тепер перед аудиторією пролітають 30 різних коротких доменів, половина з них — bit.ly, які ви не можете перевірити.
Правильний підхід: попередньо видавати посилання для сесій з вашого короткого домену події (go.yourevent.com/session-42). Видаєте спікеру слаг; він налаштовує URL призначення. Атрибуція залишається у вас.
4. Follow-up#
Пост-подієві ланцюжки. Листи з підсумками. Опитування «оцініть подію». Посилання «перегляньте записані сесії». CTA «реєструйтеся на наступний рік».
Що важливо: атрибуція назад до того, яка подія призвела до конверсії. Чи конвертував лист із підсумками? Чи призвело QR-опитування на місці до підписок на розсилку? Чи виправдала себе конверсія ROI від присутності на місці загалом?
Антипатерн: розглядати follow-up як окрему маркетингову кампанію без зв'язку з даними сесій події. Тоді конверсія реєстрації на наступний рік виглядає так, ніби прийшла з email — але насправді користувач був відвідувачем сесії, рішення якого повернутися було прийнято в день-2 самої події.
Перенаправляйте події конверсії з форми реєстрації назад у вашу аналітику посилань, щоб атрибуція follow-up поєднувалася з даними під час події. Стаття Пересилання конверсій до Meta CAPI охоплює механіку; той самий патерн пересилання працює для будь-якої CRM або email-системи нижче за потоком.
Референсна архітектура для події на 1000 осіб#
Це та архітектура посилань, яку я рекомендую найчастіше. Вона масштабується вниз до 100 і вгору до 5000 осіб з незначними змінами.
Один короткий домен на подію. go.yourevent.com. Налаштовується через DNS + функція власного домену вашого скорочувача URL. Caddy on-demand TLS або керований вендором сертифікат. Причина: послідовність бренду + єдина аналітична поверхня для запитів.
Три префікси слагів:
r/— посилання на реєстрацію.go.yourevent.com/r/email,r/sponsor-acme,r/speaker-jane. UTM-мітки вбудовані в URL призначення. Аналітична поверхня для джерела реєстрації.s/— посилання на сесії.go.yourevent.com/s/keynote-day1,s/track-a-2pm. Призначення на рівні кожної сесії, іноді однакове для всіх сесій, якщо LMS автоматично маршрутизує за користувачем.b/— посилання на бейдж.go.yourevent.com/b/<attendee-id>. Індивідуальне для кожного учасника. Веде на сторінку профілю/розкладу. Опціонально персоналізоване для VIP.
Три "набори" коротких посилань:
- Набір реєстрації створюється на момент анонсу. Приблизно 20-50 посилань. Кожне несе UTM-мітку, кожне відправляється до події.
- Набір сесій створюється після фіналізації програми. Одне посилання на сесію. URL призначення вказує на сторінку деталей сесії; URL можна оновити після події, щоб він вказував на запис.
- Набір бейджів створюється після закриття реєстрації. Один на кожного учасника. Масово імпортується з експорту реєстраційної платформи.
Три аналітичні поверхні:
- Тег реєстрації → контакт у CRM через приховане поле форми реєстрації. Захоплює UTM
sourceтаcampaignз кліку; передає їх у форму; CRM бачить, яке джерело привело реєстрацію. - Клік на сесію → аналітичний дашборд з областю видимості для префіксу
s/. Дашборд відповідає на питання «яка сесія мала найбільшу залученість?» - Сканування бейджа → подія реєстрації на місці через вебхук від сервісу коротких посилань до системи реєстрації на місці. Сканування бейджа збільшує лічильник відвідуваності та (опціонально) контролює вхід.
Архітектура складається з ~80 посилань + 1000 бейджів учасників для події на 1000 осіб. Час налаштування — ~3 години, якщо ваша реєстраційна платформа експортує CSV.
Чотири антипатерни, що руйнують дані події#
1. Окремі облікові записи скорочувача для кожної команди. Різні команди (маркетинг, операції, партнерства) мають свої облікові записи Bitly / Rebrandly. Атрибуція розпорошена по трьох дашбордах, жоден з яких не має повної картини. Консолідуйтеся на одному обліковому записі до події, а не після.
2. Повторне використання слагів минулого року. go.yourevent.com/r/keynote — це кейнот 2025 року. Якщо ви використовуєте його для 2026 без скидання аналітики, дані кліків 2026 року забруднюються трафіком 2025 року, що досі резолвиться зі старих email-розсилок. Щороку видавайте нові слаги (використовуйте go.yourevent.com/r/keynote-2026).
3. Дозволяти спікерам приносити свої посилання. Кожне коротке посилання в події — це точка даних. Посилання спікерів від довільних скорочувачів не відображаються у вашому дашборді. Якщо ви не можете їх перевірити — ви не можете їх виміряти. Давайте спікерам слаги з вашого домену і дозвольте їм вказувати куди завгодно.
4. Ігнорування навантаження в день події. Типове навантаження на посилання під час події — 50-200 редіректів на секунду протягом перших 30 хвилин дня-1 (всі сканують свій бейдж, щоб знайти карту вхідного залу). Перевірте, чи ваш скорочувач URL витримає це без збоїв. Більшість може; деякі вендори безкоштовного рівня пригальмовують у найгірший момент. Стаття redirect p95 < 15ms охоплює, на що звертати увагу в показниках продуктивності редіректів.
Практичні рекомендації щодо QR-кодів на місці#
QR-код на бейджі — це найважливіше посилання у події. Кілька практичних нотаток:
Друкуйте з правильним рівнем корекції помилок. ECC-M (середній) підходить для більшості бейджів; ECC-H (високий) є правильним вибором, якщо ви ламінуєте, тиснете або друкуєте на текстурованому матеріалі, який може затуляти модулі. Компроміс — щільність модулів: QR-коди ECC-H більш візуально навантажені.
Тестуйте контраст. Сканери QR на телефонах потребують ~60% яскравісного контрасту між модулями та фоном. Надрукуйте зразок із обраним контрастом і відскануйте його своїм телефоном з 1 м у трьох різних умовах освітлення, перш ніж підписувати тираж. Чорне на білому — безпечний варіант за замовчуванням; фірмові кольори можуть не пройти тест контрасту при слабкому освітленні.
Плануйте на випадок збою. Коли QR не сканується (це трапляється), що робить учасник? На бейджах Elido ми рекомендуємо друкувати короткий URL під QR-кодом (go.yourevent.com/b/A38K) — 6-символьні слаги можна набрати за 4 секунди, що набагато зручніше, ніж просити учасника знайти стійку інформації.
Не кладіть персональні дані в QR. QR кодує коротке посилання, а не email або ім'я учасника. Пошук відбувається на боці сервера — перехожий, що сканує QR на переповненому виставковому залі, не отримає доступу до адрес ваших учасників, навівши камеру на чийсь бейдж.
Аналіз після події#
Дані, які у вас мають бути протягом 48 годин після закінчення:
- Загальна кількість реєстрацій за джерелом (спонсор / партнер / спікер / платне / органіка)
- Відвідуваність кожної сесії + клікабельність (прокси залученості, коли лічильники в залі недоступні)
- Топ-10 сесій за наступними діями учасників (поставили 5 зірок, завантажили слайди, підписалися на розсилку спікера)
- Патерн відвідуваності: день-1 vs. день-2 vs. день-3
- Гео + UA-розбивка трафіку кліків
- Форвардна атрибуція: хто на що клікнув під час події і потім конвертувався в реєстрацію на наступний рік
Якщо ваш скорочувач URL може відповісти на всі шість питань з коробки — бюджет витрачено добре. Якщо вам потрібно писати SQL до вашого аналітичного сховища, щоб відповісти на половину з них — врахуйте це в наступному контракті.
Де знаходиться Elido#
Ми не будували Elido спеціально для подій — описана вище архітектура працює на будь-якому скорочувачі URL, що підтримує власні домени, динамічний QR і вебхуки. Але події є випробуванням під високим тиском для трьох ключових обіцянок платформи (затримка, атрибуція, резидентність у ЄС), тому ми в результаті маємо кілька опінінованих можливостей для подій:
- Масова генерація бейджів —
POST /v1/links/bulkприймає CSV ідентифікаторів учасників і повертає пакет коротких посилань, готових до динамічного QR, за один виклик. 2000 бейджів за 8 секунд. - On-demand TLS для
go.yourevent.com— вкажіть CNAME на наш edge, сертифікат видається за 30 секунд. Команда події може підняти свій домен події того ж ранку, коли запускає просування. - Вебхук при скануванні — кожне сканування бейджа може відправити вебхук до вашої системи реєстрації на місці протягом 200 мс. Диспетчер підписує доставки за допомогою HMAC-SHA256, щоб ваш обробник реєстрації міг перевірити джерело без заголовка автентифікації.
- Резидентність даних у ЄС для подій кліків — дані сканування учасників за замовчуванням зберігаються в ClickHouse у регіоні ЄС. Відповідність GDPR не вимагає паперової роботи для кожної події.
Для дзвінка з налаштування перед вашою наступною подією — сторінка рішень для подій містить відповідні деталі.
Пов'язані статті в блозі#
- QR-кампанія з нуля — глибоке занурення в тему QR
- Динамічні vs. статичні QR-коди — компроміс між довговічністю та змінністю
- Відстежуйте UTM-кампанії наскрізно без CDP — базова стаття для кластера туторіалів
- Скорочувачі URL для ecommerce: рівень даних за лійкою — суміжна галузева стаття
- Досягнення p95 < 15ms для редіректів — бюджет затримки для навантаження в день події