GA4 може збирати сотні подій і не відповідати, чи створює маркетинг якісний попит. План вимірювання зʼєднує кожну подію з питанням, власником, визначенням і рішенням.
1. Почніть із рішень
Спершу запишіть регулярні рішення: який канал фінансувати, який landing page виправити, яку аудиторію виключити, який контент допомагає пайплайну. Потім визначте мінімальні дані для кожної відповіді.
2. Спроєктуйте таксономію подій
Спершу перевірте рекомендовані назви в документації Google, а для власних подій узгодьте зрозумілу схему назв і параметрів. У списку Google generate_lead означає звернення, а qualify_lead, ліда, позначеного як такого, що відповідає критеріям кваліфікації. Це різні етапи: заповнення форми ще не підтверджує якість запиту. Google дозволяє позначати важливі для бізнесу події як ключові; які саме важливі у вашій моделі продажів, має визначити команда.
3. Опишіть згоду та якість даних
Для кожної події запишіть умову спрацювання, дозволені параметри, поведінку за різних станів згоди, власника й тест. За правилами Google в Analytics не можна передавати дані, які Google може розпізнати як PII: зокрема email та особисті номери телефонів. Перевірте також URL і заголовки сторінок: дані форми не повинні випадково потрапляти туди. Це вимога продукту, а не повний перелік ваших правових обов’язків.
Не обіцяйте, що модельовані дані заповнять усі прогалини. У документації Google для поведінкового моделювання є окремі умови, і навіть їх виконання не гарантує доступності. У звіті зазначайте, чи моделювання справді застосовується; звірка з CRM має пояснювати відмінності, а не підганяти числа до повної рівності.
У плані також зазначте, для якого аналізу й на який період потрібне зберігання даних; погодьте це з відповідальними за дані. Не подавайте свіжий звіт як остаточний: Google попереджає, що розподіл внеску каналів у ключові події може змінюватися до 12 днів після події. Фіксуйте дату отримання звіту, щоб команда розуміла, чому пізніша звірка може дати інші числа.
4. Запускайте release checklist
Google DebugView показує події та їхні параметри з пристрою, для якого ввімкнено debug mode. Пройдіть тестовий сценарій і звірте його з очікуваними подіями. Окремо перевірте, що звернення справді з’явилося в CRM: наявність події в GA4 сама цього не доводить.
Повторіть сценарій за наданої та відхиленої згоди й перевірте мережеві запити браузера та переданий стан згоди проти погодженої специфікації. Google зазначає: події не видно в DebugView, коли застосовуються клієнтські засоби захисту приватності або налаштовано consent mode й користувач не погодив Analytics cookies. Тому порожній DebugView сам по собі не доводить ані правильного блокування, ані поломки збору.
Наш робочий приклад, запит консультації, а не результат реального клієнтського експерименту. У специфікації запишіть: generate_lead надсилаємо після підтвердженого прийняття форми; клік по кнопці без успішного прийняття звернення не рахуємо результатом. form_id допомагає розрізняти форми; текст повідомлення, email і телефон у параметри не додаємо. Потім менеджер окремо визначає, чи запит відповідає погодженим критеріям: наприклад, чи потрібна людині саме наша послуга. Лише цей підтверджений статус є підставою для qualify_lead у налаштованій інтеграції; сама GA4 такої оцінки за команду не робить.
Перевірте успішне надсилання, помилку валідації та повторну спробу: у кожному випадку заздалегідь запишіть, скільки звернень система має прийняти й скільки подій ви очікуєте. Якщо один запит створює дублікати, виправте умову спрацювання до порівняння каналів. Якщо заявок багато, а кваліфікованих мало, перевірте реальні причини відмов у CRM: це підстава дослідити обіцянку на сторінці або аудиторію, але ще не доказ, що конкретний канал не працює.
Після запуску призначте відповідального за перевірку розбіжностей і повторюйте перевірку після змін форми, тегів або CRM. Частоту планової звірки оберіть за обсягом звернень і тим, коли команда ухвалює рішення про бюджет; універсального достатнього інтервалу тут немає.