Зміст матеріалу

Що важливо зрозуміти

Конверсія має відповідати реальній бізнес-дії: збереженій заявці, погодженій угоді або оплаті. Натискання кнопки чи відкриття сторінки подяки саме по собі не підтверджує результат.

Визначте, яка дія є результатом

Для форми звернення корисний результат — успішно збережена заявка з ідентифікатором. Натискання кнопки може завершитися помилкою. Відкриття сторінки подяки може повторитися або відбутися без нового звернення. Тому спочатку опишіть бізнес-подію, її момент і джерело підтвердження.

Відрізняйте кілька рівнів: звернення, кваліфіковане звернення, погоджена послуга та оплата. Одна назва «конверсія» для всіх рівнів заважає зрозуміти якість трафіку. У GA4 можна використовувати рекомендовану подію generate_lead для отримання звернення, але її коректність залежить від моменту запуску.

Що перевірити в налаштуванні

DebugView та звіти реального часу допомагають перевірити надходження події, але не замінюють звірку з базою заявок. Метод підрахунку ключових подій у GA4 також впливає на кількість: підрахунок кожної події та один раз за сеанс дають різний результат для повторних дій.

  • Подія надсилається після підтвердженого збереження, а не тільки кліку.
  • Повторне натискання та оновлення сторінки не створюють зайвий бізнес-результат.
  • Помилка валідації або сервера не рахується успішним зверненням.
  • Визначено правила тестових звернень, дублікатів і повторних клієнтів.

Перевірити на своїх даних

Приклад розбіжності між кліками та заявками

Умовна технічна перевірка форми за погоджений період.
Що порахувалиКількістьЯк тлумачити
Натискання кнопки100Спроби відправлення
Успішні записи в базі80Збережені звернення
Із них тестові5Виключаються з бізнес-оцінки
Із них дублікати одного запиту10Об’єднуються за погодженим правилом
Унікальні нетестові звернення65Основа оцінки потоку заявок

Якщо аналітика показує 100 «лідів», вона рахує іншу подію, ніж база. Навіть правильні 80 подій збереження не означають 80 нових клієнтів: для бізнес-оцінки потрібні правила якості й дублікатів. У цьому прикладі тестові та дубльовані записи — різні, непересічні групи.

Далі перевіряємо оплату: скільки з 65 звернень стали замовленнями й за який час. Не слід порівнювати їх із усіма оплатами місяця, якщо частина оплат належить зверненням попередніх періодів.

Коротка матриця технічних сценаріїв

Очікувана бізнес-поведінка форми; кількість аналітичних подій залежить також від згоди та доставки.
СценарійУ базіУспішна подія
Коректна відправкаОдна нова заявкаОдин раз після підтвердження
Помилка поляНемає нової заявкиНе надсилається
Помилка сервераНемає підтвердженого записуНе надсилається як успіх
Оновлення сторінки подякиБез нового записуБез нового успіху

Абсолютної рівності аналітики й бази може не бути через згоду користувача, блокування, втрату мережі та різні часові межі. Важливо пояснити причини й не змінювати число в базі заради збігу. Персональні поля форми — email, телефон і текст запиту — не потрібно передавати в аналітичні параметри.

Як вимірювати органічні звернення та продажі

Зберігайте початкову сторінку, допустимі дані джерела та ідентифікатор звернення. Подальші статуси й оплату пов’язуйте з цим записом. Тоді можна оцінювати кількість органічних звернень, частку кваліфікованих, замовлення та дохід. Джерело й атрибуція мають бути описані, а результати — звірені з обліком.

Перевірка повторного надсилання й помилок

У тестовому середовищі перевірте подвійний клік, повтор після перезавантаження та мережеву помилку. Подія успішного звернення має відповідати підтвердженому збереженню заявки. Помилка валідації, натискання кнопки та завантаження сторінки подяки не є підтвердженням нового ліда.

Використовуйте стабільний ідентифікатор спроби, щоб повторний запит не створював другу заявку. Зіставте одну збережену заявку з подіями аналітики й перевірте, чи подія не запускається одночасно у коді форми та менеджері тегів. Це сценарій перевірки налаштувань: наявність GA4 або конкретної події на вашому сайті потребує окремого підтвердження.

Джерела методики