Аудит власної аналітики: чому наші сайти не фіксували заявки і що ми встигли виправити за день

З чого почалося

Ми ведемо для себе щоденний звіт по відвідуваності двох власних сайтів — показуємо собі в Telegram трафік за вчора, джерела, сторінки, видимість в AI-пошукових системах. Коли готували черговий розбір, звернули увагу на цифри: один сайт отримує 6–18 відвідувачів на день, другий — 0–6. Для порівняння з кількістю заявок, які реально приходять у відділ продажів, цього явно замало. Вирішили не просто зафіксувати малий трафік, а перевірити, чи аналітика взагалі бачить ті заявки, які є.

Почали з найпростішого питання: скільки разів за останні 28 днів на сайтах спрацювала подія заявки. Відповідь виявилась незручною — majority подій, які вважались «ключовими» в Google Analytics, за цей час не прийшли жодного разу.

Що показав аудит GA4

Перше, що впадало в очі: список ключових подій у Google Analytics складався зі старих назв — назви на кшталт «заповнена_форма», «клік тел», «клік телеграм» і ще пара подібних. Жодна з них за 28 днів не прийшла. Причина проста: коли на сайтах оновлювали код форм і кнопок, назви подій змінили, а в налаштуваннях аналітики їх так і не перейменували.

Друге — на одному із сайтів узагалі не було подій форми й запису сесій користувачів, хоча на другому вони вже стояли. Третє — подія, яка мала б означати «заявка підтверджена», існувала в коді, але ключовою в GA4 позначена не була, тобто не потрапляла в жодні зведені звіти і конверсії.

Окремо порахували «сирі» дані: на сайті, де відстеження форми хоч якось працювало, за 28 днів подія старту форми спрацювала 8 разів. Подій відправки й підтвердження — за цей же період не було зафіксовано жодної. Тобто навіть якщо люди форму заповнювали, аналітика цього не бачила.

Якщо у вас «мало заявок» за звітом аналітики — спершу перевірте, чи взагалі долітають до звіту самі події, а вже потім робіть висновки про трафік чи конверсію.

Що показала CRM

Паралельно подивились у нашу CRM — куди реально падають заявки з обох сайтів. За 30 днів у ній було зафіксовано 4 ліди, і всі — через месенджер. Жодного запису, привʼязаного до джерела «сайт», не знайшли. Це означає, що навіть ті заявки, що приходять іншими каналами, у звʼязку з сайтом ніяк не відображаються — складно сказати, яка сторінка чи яка кампанія їх привела.

Що пішло не так

Ми виокремили кілька конкретних проблем, кожна з яких сама по собі невелика, але разом вони практично «осліпили» звітність:

• Назви ключових подій у аналітиці не оновлювали після зміни коду форм — події жили під старими іменами, нові під новими, і жодна зі старих назв більше не спрацьовувала.
• Подію підтвердження заявки ніхто не позначив ключовою — вона технічно існувала, але в жодному стандартному звіті конверсій не враховувалась.
• На другому сайті відстеження кліків по контактах і форми не було встановлено взагалі — там, де трафіку й так найменше, ми не бачили навіть той мінімум активності, що є.
• Половина візитів на обох сайтах позначена як «пряме джерело» (direct) — і при цьому не було фільтра внутрішнього трафіку з офісу, тобто частина цих «прямих» заходів могла бути нашою власною.
• Номер телефону, вказаний на сайті, не входив у список номерів, прив'язаних до облікового запису IP-телефонії, — тобто дзвінки з цього номера теж випадали зі звіту.
• Сайт не був підтверджений у Bing Webmaster Tools — хоча в Google Search Console дані є, частина пошукового трафіку з інших систем лишалась невидимою.

Жодна з цих проблем не була критичною сама по собі — умовно, «подія не позначена ключовою» звучить як дрібниця. Але в сумі вони давали картину, в якій заявки з сайтів фактично не видно ні в аналітиці, ні в CRM, і зробити правильний висновок про ефективність сайтів чи реклами на основі цих даних було неможливо.

Що виправили за день

Частину проблем можна було закрити без додаткових прав доступу — і ми зробили це одразу, того ж вечора:

• На сайті, де відстеження клієнтських дій уже було, додали окремі події на кліки по телефону, пошті, Telegram і месенджеру — щоб бачити не лише заповнення форми, а й усі способи звернення.
• На другому сайті, де відстеження взагалі не стояло, розгорнули той самий набір подій на всіх сторінках: кліки по контактах плюс повноцінна воронка форми — старт заповнення, відправка, підтвердження або помилка відправки.
• На цьому ж сайті додали запис сесій користувачів (той самий інструмент, що вже стояв на першому сайті) — щоб мати змогу подивитись, як саме люди взаємодіють зі сторінками.
• Додали UTM-мітки на внутрішнє посилання з одного сайту на інший, щоб переходи між нашими ж ресурсами не губились у «прямому» трафіку.
• Відправили адреси сторінок на індексацію пошуковику напряму (окремим службовим запитом), щоб не чекати природного сканування.
• Оновили щоденний звіт по сайтах — додали в нього дані про кліки по контактах і записи сесій для обох сайтів, щоб ці цифри були на очах щодня, а не лише під час спеціального аудиту.
• Зафіксували правила для UTM-міток в окремому документі — щоб надалі кампанії й внутрішні посилання розмічали однаково.

Усе перелічене перевірили по коду і логіці подій, але вживу в реальному часі в аналітиці подій ще не передивлялись — для цього потрібен окремий прогін із браузером безпосередньо на сайті, і це ще в плані.

Що не вдалося виправити того ж дня

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

• Позначити нові події (заявку, кліки по контактах) ключовими — без цього вони так і не потраплять у стандартні звіти конверсій.
• Виставити термін зберігання подій на довший період — зараз дані зберігаються лише 2 місяці, чого замало для порівняння сезонності чи кварталів.
• Налаштувати фільтр внутрішнього трафіку за IP-адресою офісу — цю опцію можна увімкнути тільки вручну через інтерфейс, автоматично через API вона не виставляється.
• Підтвердити сайт у Bing Webmaster Tools і перенести туди дані з Google Search Console.
• Додати окремий номер телефону сайтів до облікового запису IP-телефонії, щоб дзвінки з сайту враховувались у загальній статистиці заявок.

Усі ці пункти чекають на вхід у відповідні сервіси з правами редактора — технічно вони прості, організаційно вимагають, щоб хтось із доступом власника акаунта виконав кілька кліків.

Висновки, які можна застосувати в себе

Кілька правил, які ми винесли для себе з цього аудиту — і які радимо перевірити будь-кому, хто вважає, що з аналітикою «все налаштовано»:

• Раз на квартал перевіряйте, чи події, позначені ключовими у вашій аналітиці, взагалі ще спрацьовують — після будь-якого оновлення коду форм назви подій можуть «відірватись» від налаштувань звіту, і ніхто про це не повідомить.
• Перевіряйте не лише факт встановлення лічильника аналітики на сайті, а конкретно — чи стоїть відстеження форми й кліків по контактах на кожному сайті окремо, особливо якщо сайтів кілька і вони розвивались у різний час.
• Звіряйте дані аналітики з CRM: якщо в CRM є заявки, яких немає в аналітиці (чи навпаки) — це сигнал, що десь втрачається привʼязка джерела.
• Фільтр внутрішнього трафіку — не розкіш, а базова гігієна: якщо половина візитів позначена як «пряме джерело», частина з них цілком може бути вашою ж командою.
• Номер телефону на сайті обовʼязково має бути привʼязаний до тієї ж системи обліку дзвінків, що й усі інші канали, — інакше частина звернень просто випадає з будь-якої статистики.
• Права службового облікового запису аналітики варто одразу видавати з запасом (редактор, а не лише перегляд) — інакше кожне виправлення перетворюється на ще один запит на доступ і чекання.

Результат у цифрах

Чим це відрізняється від стандартного аудиту «для клієнта»

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

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

Чому старі назви подій у Google Analytics просто перестали працювати, а не видали помилку?

GA4 не попереджає, якщо подія з певною назвою перестала надходити — вона просто зникає зі звітів конверсій, бо система не розрізняє «подію вимкнули» і «подію перейменували в коді». Побачити це можна тільки порівнявши список ключових подій у налаштуваннях з реальними назвами подій, які зараз фіксуються.

Чи можна довіряти даним про трафік, якщо є проблеми з подіями заявок?

Так, кількість відвідувачів і джерела трафіку рахуються окремим механізмом і зазвичай не залежать від налаштування конкретних подій. Проблема була саме в подіях-діях (заявка, клік, форма), а не в базовому підрахунку візитів.

Чому для позначення події ключовою потрібні права редактора, а не перегляду?

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

Чи варто перевіряти аналітику, якщо на сайті і так мало трафіку?

Саме малий трафік — причина перевіряти уважніше: коли відвідувачів небагато, кожна втрачена заявка через неправильне відстеження відчутніша у відсотках, а помилку складніше помітити на око серед невеликої кількості подій.

Що робити, якщо CRM і аналітика показують різну кількість заявок?

Почати з перевірки, чи взагалі привʼязана подія заявки на сайті до запису в CRM технічно — часто це дві окремі системи, які ніхто не звіряв напряму. Далі варто порівняти період і джерела: аналітика може рахувати по кліку на кнопку, а CRM — лише по факту, що менеджер заявку підтвердив.