Аудит аналітики: чекліст на 40 пунктів

Перед тим як будувати дашборд чи міняти рекламні бюджети, варто переконатися, що дані взагалі правильні. Аудит аналітики відповідає на три питання: що збирається, наскільки це точно і чого бракує для рішень. Нижче — чекліст, яким я користуюсь, розбитий на блоки.

#Як проводити

1. Зібрати доступи: GA4, GTM, рекламні кабінети, CRM, платіжна система.
2. Пройти чекліст і позначити кожен пункт: ✅ ок, ⚠️ частково, ❌ немає.
3. Оцінити вплив і складність виправлення.
4. Скласти план: спочатку те, що спотворює гроші.

#1. GA4: базові налаштування

• Правильний часовий пояс і валюта ресурсу
• Збереження даних 14 місяців (а не 2 за замовчуванням)
• Виключено внутрішній трафік
• Список виключених рефералів (платіжні системи)
• Крос-доменне відстеження, якщо є кілька доменів
• Увімкнено експорт у BigQuery (гайд)

#2. Події та конверсії

• Ключові події позначені як key events
• Немає дублювання purchase/generate_lead
• transaction_id унікальний
• value і currency передаються коректно
• E-commerce події за стандартною схемою (трекінг e-commerce)
• Події перевірені в DebugView
• Назви подій узгоджені (snake_case, без дублів)

#3. Тег-менеджер

• Немає застарілих і дублікатних тегів
• Теги спрацьовують за правильними тригерами
• Є опис і власники контейнера
• Опубліковані версії мають коментарі

#4. Згода і приватність

• Банер згоди відповідає вимогам ринку
• Consent mode передає стан згоди (consent mode)
• Теги не спрацьовують до згоди, де це вимагається
• Політика конфіденційності актуальна
• Персональні дані (email, телефон) не потрапляють в URL і параметри подій

#5. UTM і джерела

• Є єдина конвенція UTM (правила UTM)
• Рекламні кабінети ставлять мітки автоматично
• Частка (direct)/(not set) — в розумних межах і пояснена
• Email і Telegram-розсилки розмічені

#6. Звірка з CRM і оплатами

• Кількість замовлень GA4 vs CRM звірено (розбіжності)
• Виручка GA4 vs платіжна система звірено
• Повернення враховуються
• Офлайн/телефонні продажі мають джерело
• Статуси лідів передаються назад у рекламу (за потреби)

#7. Реклама

• Конверсії в кабінетах = ті самі події, що й в GA4
• Немає подвійного рахування між платформами
• Витрати всіх каналів збираються в одному місці (зведений звіт)
• Вікна атрибуції задокументовані

#8. Дані та дашборди

• Є словник метрик з формулами
• Один джерельний набір для всіх звітів
• Оновлення автоматичне, з моніторингом збоїв
• Доступи надано за ролями
• Ключові звіти мають власника

#Пріоритети виправлень

#Шаблон звіту за аудитом

1. Резюме: 3–5 головних проблем і їхній вплив.
2. Таблиця пунктів зі статусом.
3. План виправлень з оцінкою часу.
4. Що зміниться в звітах після виправлень (наприклад, «виручка в GA4 стане ближчою до CRM»).

Після виправлень дані готові для бізнес-дашборду.

#Запити, що прискорюють аудит

Якщо ввімкнено експорт у BigQuery, кілька пунктів чекліста перевіряються одним запитом кожен.

Дублі покупок:

SELECT ecommerce.transaction_id, COUNT(*) AS events
FROM `project.analytics_123456.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930' AND event_name = 'purchase'
GROUP BY 1 HAVING COUNT(*) > 1
ORDER BY events DESC;

Покупки без суми або з нульовою сумою:

SELECT COUNTIF(ecommerce.purchase_revenue IS NULL OR ecommerce.purchase_revenue = 0) AS bad,
       COUNT(*) AS total
FROM `project.analytics_123456.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930' AND event_name = 'purchase';

Частка сесій без джерела:

SELECT COALESCE(collected_traffic_source.manual_source, '(none)') AS source,
       COUNT(DISTINCT CONCAT(user_pseudo_id,
             CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING))) AS sessions
FROM `project.analytics_123456.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930' AND event_name = 'session_start'
GROUP BY 1 ORDER BY sessions DESC;

Домени платіжних систем як джерела (проблема самореферальності):

SELECT collected_traffic_source.manual_source AS source, COUNT(*) AS events
FROM `project.analytics_123456.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930'
  AND REGEXP_CONTAINS(LOWER(collected_traffic_source.manual_source), r'pay|liqpay|stripe|paypal|wayforpay|fondy')
GROUP BY 1 ORDER BY events DESC;

Без експорту ті самі перевірки можна зробити в дослідженнях GA4 — лише повільніше.

#Приклад: підсумок аудиту

Ілюстративні знахідки для магазину — в тому порядку, як вони йдуть у звіті:

Підсумок для власника: «Виручка в GA4 зараз завищена приблизно на 7% (дублі плюс відсутні повернення), і близько десятої частини продажів приписано сторінці оплати замість реального каналу. Пункти 1–3 можна виправити цього тижня менш ніж за день роботи. Після цього звітам за каналами можна довіряти рішення щодо бюджету.»

#Оцінка пріоритетів

Коли список довгий, проста оцінка тримає розмову об'єктивною:

Пріоритет = вплив (1–5) × впевненість (1–3) / зусилля (1–5)

Вплив — що саме спотворює проблема (гроші — 5, джерела — 4, поведінка — 3, гігієна — 1). Впевненість — наскільки ви певні, що проблема реальна і виправляється так, як описано. Зусилля — грубий розмір роботи. Сортуйте за оцінкою, але все, що спотворює виручку, виправляйте першим незалежно від оцінки.

#План аудиту на два тижні

Для невеликого сайту з одним доменом і кількома інтеграціями часто виходить швидше. Для кількох доменів, застосунків і ринків — довше.

#Знахідки, що трапляються найчастіше

Від аудиту до аудиту повторюється та сама жменька проблем. Якщо часу мало, перевірте спершу їх:

1. Покупка спрацьовує до оплати. Тег стоїть на «замовлення створено», тож невдалі й покинуті оплати рахуються як виручка. Перенесіть його на підтвердження оплати або на сервер.
2. Самореферали зі сторінок оплати. Клієнти повертаються від платіжної системи і починають нову сесію, яку приписують їй. Додайте домени платіжки у список виключених рефералів.
3. Повернень у GA4 немає. Виручка ніколи не зменшується, тож ROAS виглядає кращим щомісяця, поки частка повернень росте.
4. Внутрішній трафік у даних. Команда тестує сайт, менеджери оформлюють телефонні замовлення через сайт — обсяг невеликий, але в магазинах з невеликим трафіком він спотворює конверсію.
5. Хаос в UTM. Той самий канал під десятком написань плюс внутрішні посилання з UTM, що перезаписують справжні джерела.
6. Налаштування без власника. Контейнери GTM з тегами трьох колишніх агенцій — і ніхто не знає, які з них ще потрібні.

Жодна з цих проблем не потребує нового інструмента. Потрібно, щоб хтось перевірив, виправив і записав, що зроблено. Тому звіт аудиту має закінчуватися коротким журналом «що і коли змінили». Наступного разу, коли якесь число стрибне, саме туди варто зазирнути першим.

#Після аудиту

Заплануйте легку повторну перевірку через три місяці: прогнати запити вище, переконатися, що виправлення пережили релізи сайту, переглянути нові теги й кампанії. Трекінг «розмивається» з кожним релізом, і щоквартальна двогодинна перевірка значно дешевша за ще один повний аудит через рік.

#Часті запитання

#Як часто проводити аудит?

Повний — раз на рік або після редизайну, зміни платформи чи CRM. Звірку з CRM — щомісяця.

#Скільки триває аудит?

Для типового сайту з GA4, GTM і 2–3 рекламними каналами — зазвичай кілька днів роботи, залежно від кількості доменів і інтеграцій.

#Можна провести аудит самостійно?

Так, чекліст вище це дозволяє. Найскладніше — звірка з CRM і пошук причин розбіжностей; там допомагає досвід.

#Що робити, якщо історичні дані неправильні?

Виправити трекінг з поточного моменту, задокументувати дату змін і за потреби перерахувати історію в сховищі з CRM-даних.