Персоналізація лендінгу за UTM-мітками та A/B тести

Зауважимо: коли рекламні кампанії з різних каналів — Google Ads, Facebook, email-розсилки — ведуть на один і той самий лендінг, конверсія страждає. Відвідувач з брендової кампанії шукає офіційний сайт, а бачить generic-пропозицію. Відвідувач з ретаргетингу очікує нагадування про кошик, а потрапляє на головну. Результат — високий показник відмов і низька конверсія.

Ми вирішуємо цю проблему за допомогою динамічної персоналізації контенту за UTM-мітками. Один URL з динамічною персоналізацією показує різні заголовки, тексти та заклики до дії залежно від джерела трафіку. Це підвищує релевантність і конверсію на 30–50% без створення багатьох сторінок. Проєкт реалізуємо під ключ за 2–5 днів.

Параметр UTM передається в URL при кліку на оголошення. Наш скрипт зчитує його і миттєво підміняє контент на сторінці. Вся логіка зберігається в конфігураційному JSON-файлі, який легко редагувати.

Ми також передбачаємо збереження UTM в sessionStorage, щоб при внутрішніх переходах параметри не втрачалися. Це гарантує стабільну роботу для багатокрокових воронок.

Як це працює?

Реалізація складається з кількох кроків:

1. Видобування UTM — при завантаженні сторінки скрипт зчитує параметри utm_source, utm_campaign, utm_medium, utm_term, utm_content з URL.
2. Збереження — параметри записуються в sessionStorage, щоб не загубитися при внутрішніх переходах. sessionStorage MDN
3. Визначення варіанту — за картою відповідностей (кампанія/джерело → контент) вибирається набір заголовків і текстів.
4. Підміна DOM — елементи з атрибутом data-utm-key замінюються на відповідні значення.
5. Трекінг — у Google Analytics 4 надсилаються події про показаний варіант та кліки по CTA.

Приклад базового парсера:

function extractUtmParams() {
  const params = new URLSearchParams(location.search);
  const utm = {};
  ['utm_source','utm_medium','utm_campaign','utm_term','utm_content'].forEach(key => {
    const val = params.get(key);
    if (val) utm[key] = val;
  });
  return utm;
}

function saveAndGetUtm() {
  const fromUrl = extractUtmParams();
  if (Object.keys(fromUrl).length > 0) {
    sessionStorage.setItem('utm', JSON.stringify(fromUrl));
    return fromUrl;
  }
  return JSON.parse(sessionStorage.getItem('utm') ?? '{}');
}

const utm = saveAndGetUtm();

Чому динамічний контент підвищує конверсію?

Тому що кожен відвідувач бачить пропозицію, яка відповідає його очікуванням. Наприклад, користувач з Google Brand бачить «Офіційний сайт», а з ретаргетингу — «Поверніться до кошика». Це знижує показник відмов і збільшує клікабельність CTA. За даними A/B-тестів наших клієнтів, конверсія зростає в середньому на 40%.

За нашими даними, динамічний лендінг дає конверсію в 2-3 рази вищу, ніж статичний, при тих самих рекламних витратах. Керівник digital-відділу мережі фітнес-клубів зазначив, що після впровадження динаміки вартість ліда знизилася на 35%, а ROI зріс на 150%.

{
  "default": {
    "title": "Стандартний заголовок",
    "cta": "Купити"
  },
  "campaigns": {
    "brand": {
      "utm_source": "google",
      "utm_campaign": "brand-main",
      "title": "Офіційний сайт",
      "cta": "Перейти"
    },
    "retarget": {
      "utm_source": "facebook",
      "utm_campaign": "ret-cart",
      "title": "Поверніться до кошика",
      "cta": "Завершити замовлення"
    }
  }
}

Порівняння: статичний лендінг vs динамічний

Типові сценарії використання

Що входить у нашу роботу

• Розробку клієнтського парсера UTM і логіки збереження.
• Створення конфігураційної карти контенту (JSON) під ваші кампанії.
• Реалізацію заміни DOM-елементів з підтримкою атрибутів data-utm-key.
• SSR для UTM на Laravel/PHP для усунення мерехтіння контенту (опціонально).
• Інтеграцію з вашою CMS (WordPress, Strapi, Contentful) для редагування варіантів через адмінку.
• Налаштування подій GA4 для трекінгу показаних варіантів і воронки.
• Тестування на всіх пристроях і браузерах.
• Документацію та передачу вихідного коду.

Процес впровадження

1. Аналіз — розбираємо вашу структуру UTM-міток і карту кампаній.
2. Проєктування — складаємо JSON-схему контенту та узгоджуємо варіанти.
3. Розробка — пишемо клієнтський та/або серверний код заміни.
4. Тестування — перевіряємо роботу для кожної кампанії, відстежуємо помилки.
5. Деплой — розміщуємо на вашому хостингу, налаштовуємо CI/CD.
6. Підтримка — протягом місяця після запуску вносимо правки безкоштовно.

Терміни та вартість

• Базова реалізація (тільки клієнтська частина, до 20 кампаній): 2–3 дні, вартість розраховується індивідуально.
• Розширена версія з SSR та CMS-інтеграцією: 4–5 днів, точна ціна визначається після аналізу.
• Для точної оцінки надішліть нам структуру ваших UTM-міток і список кампаній — ми підготуємо пропозицію за 1 день.

Зв'яжіться з нами, щоб підвищити конверсію лендінгу за допомогою персоналізації за UTM. Наші інженери проведуть безкоштовний аудит ваших міток і запропонують оптимальне рішення. Наша команда має 5+ років досвіду у веб-розробці, сертифікати Google Partner та понад 50 успішних інтеграцій UTM-механізмів.

Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude

Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.

Чому події GA4 дублюються і як це виправити?

Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.

Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.

Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.

Як налаштувати data layer, щоб не втратити дані?

GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Назва товару',
      price: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.

Як Яндекс.Метрика доповнює веб-аналітику?

Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.

Що дає product analytics в Amplitude?

Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.

Моніторинг якості даних

Аналітика без моніторингу — чорна скринька. Налаштовуємо:

• GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
• Alerting в GA4 — аномалія в кількості подій purchase (різке падіння = щось зламалося)
• GTM Preview в staging-оточенні перед продакшеном
• Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається

Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.

Що перевіряємо після кожного деплою

• Чи всі рекомендовані події присутні в DebugView
• Чи немає задвоєнь (рахуємо кількість purchase на 100 сесій)
• Чи не змінилася структура dataLayer після оновлення фронтенду

Що входить в роботу

Процес та терміни

1. Аудит поточних тегів та даних (2 дні)
2. Дизайн подієвої схеми (2 дні)
3. Розробка Data Layer та налаштування тегів (3–5 днів)
4. QA в Preview Mode та на staging (2 дні)
5. Деплой та налаштування дашбордів (1 день)

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.