Модуль 7 · Урок 24
Measurement plan, події та ключові дії
Аналітика починається не з тегів. Спершу визначають рішення, outcome, дію користувача, population, definition, baseline, target і guardrail — і лише тоді проєктують події, параметри та QA.
Від рішення до даних
«Відстежувати сайт» — не measurement plan. Сильніше: «через 28 днів owner вирішить, чи продовжувати distribution, якщо частка qualified requests з eligible consented sessions перевищить baseline без зростання spam». Тут зрозумілі рішення, population, window і guardrail.
Name · decision · exact numerator/denominator · population · inclusion/exclusion · time zone/window · source · baseline · target · guardrail · owner · QA · review rule.
Чотири типи подій GA4
| Тип | Коли | Дія команди |
|---|---|---|
| Automatically collected | Базові взаємодії після налаштування tag/SDK | Перевірити collection і consent |
| Enhanced measurement | Типові web-взаємодії: scroll, outbound click, file download тощо | Перевірити settings і реальну семантику |
| Recommended | Стандартна бізнес-дія має визначену назву/parameters | Використати spec, наприклад generate_lead або purchase |
| Custom | Жодна стандартна подія не описує потрібну дію | Документувати стабільну назву та parameters |
Не створюйте custom event, якщо recommended event точно підходить. Назва має описувати підтверджену дію, а не елемент UI: успішна заявка важливіша за клік по кнопці, який міг завершитися помилкою.
Event contract і key event
Позначення події key event не виправляє слабкий trigger і не доводить causal impact. Воно допомагає reporting і downstream use, якщо measurement contract уже коректний.
QA до production
- Test case описує starting state, consent, action і expected event/parameters.
- Tag-manager preview або дозволена локальна перевірка показує правильний trigger.
- Network request не містить заборонених даних і не дублюється.
- Realtime/DebugView підтверджує event і parameter values.
- Negative cases не відправляють success event.
- Після release порівняйте aggregate count із дозволеним source-of-truth і зафіксуйте latency/limits.
Debug не дорівнює production truth
DebugView підтверджує збір окремого тесту. Для довіри потрібні consent coverage, filtering, timezone, deduplication, data latency та reconciliation.
Практика уроку
- Оберіть одне marketing decision і заповніть metric contract.
- Спроєктуйте 4–6 подій: trigger, type, parameters, owner, consent і report.
- Позначте максимум 1–2 key events та обґрунтуйте business value.
- Напишіть positive, negative і duplicate test cases.
- Складіть rollback/escalation rule на випадок різкої зміни collection.
Офіційні джерела
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.