13 найчастіших помилок у налаштуванні Google Analytics, SEO кейси соціалки, реклама, інструкція
Ми зібрали для вас найпоширеніші помилки у відслідковуванні та налаштуваннях Google Analytics. Сподіваємось, вони будуть вам корисні.
Відсутність лічильника на деяких сторінках сайту
Коли перевіряють, чи встановлений на сайті лічильник аналітики, зазвичай заходять на 2-3 сторінки і дивляться, чи є там лічильник. Іноді цього недостатньо. При більш детальному вивченні питання може виявитися, що відстеження дійсно налаштоване на більшій частині сайту, але дані про деякі сторінки або розділи відсутні. Часто лічильник просто забувають ставити на нові сторінки, лендинги, піддомени, мобільну версію сайту.
Важливо, щоб усі члени вашої команди, які займаються розробкою сайту, знали, що лічильник Google Analytics має стояти на всіх сторінках сайту. І звичайно ж, як тільки зміни на сайті переносяться з тестового середовища до робочого, необхідно перевіряти коректне встановлення лічильника на всіх нових або оновлених сторінках.
Якщо якісь сторінки не відстежуються, ця інформація може з'явитися в оповіщеннях Google Analytics:
Відключено збір даних демографічних звітів
Буває, що сайт вже працює кілька років і лічильник на ньому стоїть, але коли справа доходить до аналізу аудиторії, виявляється, що весь цей час дані про аудиторію не збиралися. Таким чином ви втрачаєте цінну інформацію про ваших відвідувачів та покупців, яка могла б вам допомогти краще дізнатися про вашу аудиторію та зрозуміти, як найбільш ефективно позиціонувати ваш продукт.
Щоб увімкнути збір даних про аудиторію вашого сайту, потрібно включити його в налаштуваннях ресурсу:
yabs.yandex, (not set) у джерелі та каналі
Іноді у джерелах трафіку ви можете побачитиyabs.yandex та (not set) замість очікуваних yandex cpc:
Для перевірки та формування посилань з мітками можна використовувати сервіс Google Компонувальник URL.
Некоректний редирект на мобільну версію сайту
Сайти без адаптивної верстки можуть мати окрему версію для мобільних пристроїв, як правило, на піддомі, наприклад m.site.ru. Перехід на мобільну версію зазвичай відбувається так:
1. Користувач переходить до сайту site.ru.
2. Серверний код визначає тип пристрою користувача.
3. Якщо цей мобільний пристрій, відбувається редирект на мобільну версію m.site.ru.
На жаль, іноді програмісти забувають передавати параметри URL на мобільну версію. Якщо передавалися utm-мітки, вся інформація про джерело буде втрачена.
Щоб усі мітки зберігалися та джерело визначалося правильно після редиректу, необхідно запам'ятовувати всі параметри URL, за якими користувач до вас прийшов, та пересилати їх далі у редиректі на мобільну версію сайту.
Не налаштована помилка 404
По-перше, на сторінку 404 помилки також необхідно ставити лічильник Google Analytics.
По-друге, необхідно налаштувати 404 помилку так, щоб її легко можна було відстежити. Для цього слід прописати коректний заголовок для сторінки 404, яким її можна буде легко знайти і подивитися, як на неї потрапив користувач:
Другий варіант коректного відстеження – відправляти події при відкритті 404 сторінки:
Не відстежуються сторінки з відсутнім товаром
Ця проблема актуальна для інтернет-магазинів. Користувачі можуть потрапляти на сторінки товарів, які зараз відсутні у магазині. Якщо не налаштовувати відстеження такихтоварів, то ми навіть не знатимемо, наскільки серйозною є ця проблема. Уявіть - користувачі переходять на сторінку товару в надії його купити, а виявляється, що його немає. Магазин через це втрачає прибуток. Знаючи, які відсутні товари цікавлять користувачів, ми зможемо вжити заходів щодо закупівлі нової партії чи збільшення складу.
На щастя, рішення цієї проблеми досить просте – необхідно налаштувати передачу подій у Google Analytics, коли користувач потрапляє на сторінку відсутнього товару. В цьому випадку можна буде легко відстежити, як часто і на які товари переходять користувачі:
У випадках, коли в URL необхідно прописати мітки і якір, іноді просто копіюють посилання з якорем і в кінець додають мітки:
Однак така послідовність якоря та параметрів некоректна. При переході за таким посиланням якір не спрацює і сторінка, що відкрилася, не перегорнеться до потрібного місця.
Якір URL завжди повинен знаходитися в самому кінці, після всіх параметрів:
Платіжні системи визначаються як джерело замовлення
При онлайн-оплаті замовлення користувач зазвичай залишає сайт магазину і переходить на сайт платіжної системи, де здійснює оплату банківською карткою або електронними грошима. Після оплати користувач повертається на ваш сайт і йому виводиться повідомлення про успішну оплату або про замовлення. У цьому випадку Google Analytics створює другу сесію, коли користувач повертається на ваш сайт із платіжної системи. Як результат у джерелах транзакцій ви побачите реферал із сайтом платіжної системи та втратите інформацію про те, звідки насправді прийшов користувач, який здійснив транзакцію.
Вирішити цю проблему можна додавши домени платіжних системи до списку виключенихджерел переходу у коді відстеження ресурсу. Після цього транзакціям присвоюватиметься їхнє справжнє джерело.
Відстежуються не всі типи транзакцій
Як правило, в інтернет-магазинах існує більш ніж одна можливість оформлення замовлення – не тільки через кошик, а й покупка в один клік, бронювання товару тощо. Часто трапляється так, що при налаштуванні електронної торгівлі було враховано лише один шлях оформлення замовлення, зазвичай це оформлення через кошик. Таким чином, в Google Analytics надходять замовлення тільки з кошика, а решта втрачається.
Найчастіше така ситуація трапляється через недостатню комунікацію в команді. Наприклад, у першій версії сайту оформлення замовлення було налагоджено лише через кошик і для цього варіанта було налагоджено електронну торгівлю. Через деякий час на сайт додали можливість покупки в один клік або кредит, але маркетолога про це не сповістили, а програміст не знав, що потрібно і в цьому випадку встановлювати код електронної торгівлі. У результаті нових типів оформлення замовлення транзакції не відправляються.
Менеджер проекту, програмісти та маркетолог повинні тримати один одного в курсі всіх змін та доопрацювань на сайті. У технічних завданнях програмістам необхідно уточнювати, що код транзакції має бути встановлений для всіх варіантів оформлення замовлення: оформлення через кошик, швидка покупка, покупка в кредит, бронювання товару з будь-якими типами доставки та оплати. Після впровадження коду необхідно переконатися, що він виконується як потрібно будь-яких замовлень.
Подвійне спрацювання транзакцій
При налаштуванні електронної торгівлі код транзакції повинен виконуватись на сторінці «Дякую за покупку». Це всі розуміють, але є один нюанс – цей код має виконуватися лише один раз!Іноді користувачі оновлюють сторінку підтвердження замовлення або залишають цю вкладку відкритою у браузері, тоді при наступному відкритті браузера ця сторінка буде знову відкрита. У цьому випадку інформація про досконалу транзакцію знову передається до Google Analytics, і у звіті ви побачите кілька одних і тих самих транзакцій:
Вірним способом уникнути цього стане виконання коду транзакції лише один раз на сторінці. Це можна реалізувати як на стороні сервера, так і на стороні клієнта.
Google Analytics визначає відвідувану сторінку по повній URL-адресі, включаючи параметри, що передаються. Розглянемо одну й ту саму сторінку, відкриту з різними параметрами:
Google Analytics визначить ці два відвідування як відвідування двох різних сторінок: about.php?a=123 та about.php?a=456. У статистиці це буде виглядати, як відвідування безлічі різних сторінок, хоча насправді це та сама сторінка:
Якщо параметри, що передаються в URL, не змінюють контент сторінки, то необхідно виключати ці параметри в налаштуваннях подання:
Після цього всі відвідування у статистиці Google Analytics будуть стосуватися однієї сторінки:
Вибрано неправильний тип відповідності з метою
При налаштуванні цілей важливо враховувати тип відповідності: «Рівне», «Починається з» та «Регулярний вираз». Навіть якщо у вас сторінка мети вказана правильно, але відповідність вибрана некоректно, ціль фіксуватися не буде.
Необхідно чітко розуміти відмінності типів відповідності цілей та вибирати коректну відповідність. Якщо ви використовуєте регулярні вирази, майте на увазі, що вони мають свій синтаксис, який необхідно використовувати. Наприклад, всі точки повинні бути екрановані зворотним слішем:
Дуже низький показник відмов
Коженвласник сайту повинен прагнути зменшити показник відмов, проте надто низький показник відмов (менше 10%) може говорити про проблему відстеження на сайті. Особливо це виявляється вірним, коли відбувається різке зниження показника відмов, наприклад, з 60% до 5% після технічних робіт на сайті. Це може бути викликано тим, що на сторінці випадково було встановлено другий лічильник Google Analytics, що дублює відправлення даних у той самий ресурс. Наприклад, спочатку лічильник міг бути встановлений усередині тега HEAD, а програміст, який вносив зміни на сайті, його не помітив і встановив ще один лічильник усередині тега BODY.
Друга поширена причина різкого падіння показника відмов – відправлення автоматичних подій у лічильник. Це можуть бути події, які налаштовані на виконання через якийсь час, наприклад, через 5 секунд після відкриття сторінки, або пересування курсору мишки і т.д. Google Analytics сприйматиме ці події як дії користувача на сайті і як наслідок показник відмов знизиться.
Перевірте, чи не встановлено код лічильника двічі на сторінці та видаліть дублюючий код.
Якщо це викликано автоматичною передачею подій, то встановіть у події значення поля nonInteraction у true. У цьому випадку Google Analytics не сприйматиме ці події як дії користувача.