Як перевірити точність даних вебаналітики

Як перевірити точність даних вебаналітики

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

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

1. Виберіть кілька подій для перевірки

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

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

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

Також визначте очікувані умови. Якщо подія надсилання форми має спрацьовувати лише після успішної перевірки даних, невдала спроба не повинна зараховуватися. Це важливо, наприклад, коли користувач натискає «Надіслати», не заповнивши обов’язкове поле: кнопку натиснуто, але форму не надіслано.

2. Простежте шлях кожної події — від дії до звіту

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

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

На кожному етапі використовуйте однакову назву події. Наприклад, сайт може надсилати подію form_success, тоді як у звіті налаштовано показувати generate_lead. Обидві назви можуть бути доречними, але між ними має бути зв’язок через відповідне правило або налаштування звітності. Командам, які підтримують кілька ресурсів, інструмент моніторингу, наприклад платформа вебаналітики та моніторингу, може допомогти виявляти зміни, однак він не замінить перевірку самої події.

3. Проведіть контрольовані тести в новому сеансі браузера

За можливості використовуйте новий профіль браузера або приватне вікно з вимкненими розширеннями. Так ви зменшите вплив збережених файлів cookie, попередніх відвідувань і доповнень браузера. Записуйте точні кроки й час: відкрити цільову сторінку о 10:04, переглянути один товар, додати його до кошика й зупинитися. Часові позначки полегшать зіставлення дій у браузері із запитами аналітики та серверними записами.

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

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

4. Порівняйте аналітику з незалежними даними

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

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

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

5. Перевірте, чи немає дубльованих або втрачених подій

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

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

Виявити відсутні події може бути складніше, ніж дублікати. Перевірте помилки валідації, повільне з’єднання та повернення на сторінку кнопкою «Назад», якщо такі ситуації трапляються на сайті. Форма може успішно зберегти відповідь, навіть якщо скрипт не спрацював і не надіслав аналітичну подію. Це проблема відстеження, а не втрачений лід.

6. Перевірте вплив згоди, блокування та переходів між доменами

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

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

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

7. Задокументуйте результати й повторіть тест після змін

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

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

Якщо під час перевірки виникла підозра на помилку в Google Analytics, з’ясовуйте, як знайти помилки в даних Google Analytics: перевірте часовий проміжок, фільтри, назви подій, затримку обробки та зіставлення тестових дій із незалежними записами.