1. Direct трафік в Google Analytics - причини виникнення і як його зменшити Матеріали для скачування...
2. Чи не передається реферер
3. обриви сесії
4. Інші причини, які спотворюють дані по direct трафіку
5. Короткі рекомендації по пошуку проблем
6. використані інструменти
7. Причини, за якими GA визначає сесії в direct трафік
8. Чи не передається реферер
9. обриви сесії
10. Інші причини, які спотворюють дані по direct трафіку
11. Короткі рекомендації по пошуку проблем
12. використані інструменти
13. Причини, за якими GA визначає сесії в direct трафік
14. Чи не передається реферер
15. обриви сесії
16. Інші причини, які спотворюють дані по direct трафіку
17. Короткі рекомендації по пошуку проблем

Direct трафік в Google Analytics - причини виникнення і як його зменшити

Матеріали для скачування

Гайд: як перевірити трафік

Якщо ваш direct трафік Сеанси, коли користувач ввів URL сайту в адресному рядку або використовував ятати вище 30%, не поспішайте відкривати шампанське і відзначати приголомшливу впізнаваність компанії. Цілком можливо, що Google Analytics визначив в direct трафік відвідування сайту, які насправді до нього не відносяться.

Чому так відбувається? Причини можуть бути технічними (обриви сесій, редіректи і т.д.) і технологічними (переходи на сайт з мобільних додатків, email, месенджерів і т.д.).

До якої проблеми це призводить? Неможливо правильно оцінити ефективність джерел трафіку, які помилково записуються в direct.

У цій статті ви дізнаєтеся:

Причини, за якими GA визначає сесії в direct трафік

Google Analytics шукає інформацію про джерела трафіку в наступній послідовності:

1. Спочатку GA перевіряє наявність Adwords / DoubleClick тегів (gclid параметр для автоматичного позначки AdWords. Додається в URL цільової сторінки, коли користувач натискає на оголошення / gclsrc параметр для автоматичного позначки DoubleClick Search).
2. Потім - наявність UTM-міток Змінна, яка додається в URL і дозволяє системі веб-аналітики отримати додаткову інформацію про джерело трафіку (UTM_source / UTM_medium і т.д.). Детальніше про UTM-мітках читайте в нашій статті .
3. Після шукає HTTP referrer У протоколі HTTP один із заголовків запиту клієнта. Містить URL джерела запиту.
4. І нарешті, Google Analytics намагається ідентифікувати користувача по clientID або userID, перевіряючи збіг за останні 4 години, і прив'язати дані про хіті до останньої сесії користувача. Наприклад, користувач перейшов на сайт з рекламного оголошення і через 2 години купив товар в офлайн-магазині. Якщо дані про покупку відправляються в Google Analytics через Measurement Protocol і користувача вдається розпізнати по userID, хіт (досконала транзакція) буде зарахований в останню онлайн-сесію користувача, у якої вже є джерело трафіку (в нашому прикладі - google / cpc).

Щоб визначити джерело трафіку, досить одного з цих параметрів. Якщо нічого з перерахованого не знайдено, GA записує джерело трафіку - direct.

Детальна схема обробки даних описана в довідці GA.

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

Чи не передається реферер

HTTP Referer - в протоколі HTTP один із заголовків запиту клієнта. Містить URL джерела запиту. Якщо перейти з однієї сторінки на іншу, то referer другої сторінки буде містити адресу першої сторінки.

Реферер не передається в таких випадках:

1. Переходи по посиланнях з офлайнових документів: PDF, Word, Power Point і т.д.
2. Переходи з мобільних і стаціонарних додатків: Skype, Viber, Facebook, VK, Google Search і т.д.
3. Переходи з Email: Microsoft Outlook, Thunderbird і т.д.
4. Відправка даних по Measurement Protocol без вказівки source / medium.
5. Редіректи без передачі HTTP заголовка або UTM-міток на засланні. Наприклад, користувач зайшов за посиланням site.com, але система перенаправила його на site.ru. Якщо при редирект не передавати HTTP заголовок (в т.ч. реферер, який привів відвідувача на сайт, наприклад, facebook.com) або UTM-мітку в кінцевій посиланням (google.ru/?UTM_source=facebook&UTM_medium=cpc), то даний трафік потраплятиме в direct. Найчастіше ця помилка виникає, якщо ви робите редіректи на стороні клієнта (за допомогою javascript).
6. Переходи c HTTPS на HTTP сторінки (згідно п. 5.5.2 в стандартах роботи Web). Наприклад, якщо у вас сайт на HTTP, то переходи без UTM-міток c https://www.youtube.com/ будуть зараховуватися в direct, тому що зашифрований протокол передачі даних HTTPS залишають поза передачею реферер.
7. Відвідувач включив налаштування приватності браузера (режим інкогніто) і доповнення для блокування скриптів на кшталт ScriptSafe (встановити можна тут ) та інших.
8. Помилки в коді. Іноді помилки в скриптах можуть оновлювати куки, і цей трафік буде записуватися в direct. Також при вказівці в коді посилання <а href = ..> атрибута 'rel = noreferrer' реферер передаватися не буде.
9. Помилки, коли браузер не передає реферер. Наприклад в IE8 втрачається реферер при використанні редирект методу Javascript: location.href і Meta refresh - 0. Також Internet Explorer втрачає реферер, коли користувач натискає на посилання, яка використовує JS метод window.open або коли користувач натискає на лінк, вставлений у Flash додаток .
10. Неправильна UTM-розмітка кампанії (наприклад, UTMSource замість UTM_source). Якщо у посилання є UTM-мітка, то GA ігнорує реферер. У тих випадках, де розмітка посилання не відповідає довідці, візити будуть записувати в direct.

обриви сесії

Призначені для користувача сесії можуть обриватися в наступних випадках:

1. Відсутність GA / GTM коду на посадочних сторінках сайту. При переході з посадкової сторінки без GA коду на наступну сторінку вашого сайту в реферер запишеться власний URL і UTM-міток вже не буде. GA запише цю сесію в direct (якщо власний домен доданий в «Список виключаються джерел переходу») або в referral (якщо не доданий).
2. Авторизація через соціальну мережу з повним переходом на неї замість авторизації через спливаюче вікно.
3. Повільно завантажується код GA - користувач переходить на наступну сторінку сайту до завантаження коду.
4. Відправка хіта вагою понад 8 кбайт на посадкової сторінці. Хіт не буде відправлятися в GA, відповідно сесія буде обриватися.
5. Некоректна настройка крос-доменного відстеження.

Інші причини, які спотворюють дані по direct трафіку

Відвідування сайту співробітниками компанії. Їх можна виключати по IP адресами, спеціальним cookies на корпоративних / проміжних сторінках, за допомогою розширень в браузерах або фільтрів в Google Analytics.

Відвідування сайту ботами. Знайти IP-адреси ботів можна в логах сайту або за допомогою OWOX BI Pipeline , Зібравши дані про активність на сайті в Google BigQuery. Обчислювати ботів рекомендуємо:

1. По поведінці на сайті. Наприклад, час візиту до 2 секунд, відсутність транзакцій, високий показник відмов і т.д.
2. За User Agent (браузери, провайдери, локація, пристрої). Наприклад, один провайдер (site.ru), один регіон (Москва, Росія).

Короткі рекомендації по пошуку проблем

Визначивши проблеми з direct трафіком, ви зможете виправити статистику за джерелами трафіку і, відповідно, точніше оцінювати ROAS.

Як вирішити проблеми з передачею referrer:

• Проставити UTM-мітки на всіх посиланнях (як розмічати кампанії, описано в статті «Що таке UTM-мітки і як їх застосовувати» ).
• Створити користувацький параметр рівня хіта і записувати в нього значення referrer, а потім аналізувати дані в спеціальних звітах .

Як знайти проблеми з обривами сесій:

• За допомогою консолі розробника і GA debugger .
• За допомогою записів сесій в Google Tag Assistant .
• Перевірити наявність GA / GTM коду на сторінках сайту, використовуючи Screaming Frog або інші сервіси.

Ми підготували наочне керівництво, як знайти проблеми з direct трафіком, і готові поділитися. вкажіть email , На який вам його відправити.

використані інструменти

Direct трафік в Google Analytics - причини виникнення і як його зменшити

Матеріали для скачування

Гайд: як перевірити трафік

Якщо ваш direct трафік Сеанси, коли користувач ввів URL сайту в адресному рядку або використовував ятати вище 30%, не поспішайте відкривати шампанське і відзначати приголомшливу впізнаваність компанії. Цілком можливо, що Google Analytics визначив в direct трафік відвідування сайту, які насправді до нього не відносяться.

Чому так відбувається? Причини можуть бути технічними (обриви сесій, редіректи і т.д.) і технологічними (переходи на сайт з мобільних додатків, email, месенджерів і т.д.).

До якої проблеми це призводить? Неможливо правильно оцінити ефективність джерел трафіку, які помилково записуються в direct.

У цій статті ви дізнаєтеся:

Причини, за якими GA визначає сесії в direct трафік

Google Analytics шукає інформацію про джерела трафіку в наступній послідовності:

1. Спочатку GA перевіряє наявність Adwords / DoubleClick тегів (gclid параметр для автоматичного позначки AdWords. Додається в URL цільової сторінки, коли користувач натискає на оголошення / gclsrc параметр для автоматичного позначки DoubleClick Search).
2. Потім - наявність UTM-міток Змінна, яка додається в URL і дозволяє системі веб-аналітики отримати додаткову інформацію про джерело трафіку (UTM_source / UTM_medium і т.д.). Детальніше про UTM-мітках читайте в нашій статті .
3. Після шукає HTTP referrer У протоколі HTTP один із заголовків запиту клієнта. Містить URL джерела запиту.
4. І нарешті, Google Analytics намагається ідентифікувати користувача по clientID або userID, перевіряючи збіг за останні 4 години, і прив'язати дані про хіті до останньої сесії користувача. Наприклад, користувач перейшов на сайт з рекламного оголошення і через 2 години купив товар в офлайн-магазині. Якщо дані про покупку відправляються в Google Analytics через Measurement Protocol і користувача вдається розпізнати по userID, хіт (досконала транзакція) буде зарахований в останню онлайн-сесію користувача, у якої вже є джерело трафіку (в нашому прикладі - google / cpc).

Щоб визначити джерело трафіку, досить одного з цих параметрів. Якщо нічого з перерахованого не знайдено, GA записує джерело трафіку - direct.

Детальна схема обробки даних описана в довідці GA.

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

Чи не передається реферер

HTTP Referer - в протоколі HTTP один із заголовків запиту клієнта. Містить URL джерела запиту. Якщо перейти з однієї сторінки на іншу, то referer другої сторінки буде містити адресу першої сторінки.

Реферер не передається в таких випадках:

1. Переходи по посиланнях з офлайнових документів: PDF, Word, Power Point і т.д.
2. Переходи з мобільних і стаціонарних додатків: Skype, Viber, Facebook, VK, Google Search і т.д.
3. Переходи з Email: Microsoft Outlook, Thunderbird і т.д.
4. Відправка даних по Measurement Protocol без вказівки source / medium.
5. Редіректи без передачі HTTP заголовка або UTM-міток на засланні. Наприклад, користувач зайшов за посиланням site.com, але система перенаправила його на site.ru. Якщо при редирект не передавати HTTP заголовок (в т.ч. реферер, який привів відвідувача на сайт, наприклад, facebook.com) або UTM-мітку в кінцевій посиланням (google.ru/?UTM_source=facebook&UTM_medium=cpc), то даний трафік потраплятиме в direct. Найчастіше ця помилка виникає, якщо ви робите редіректи на стороні клієнта (за допомогою javascript).
6. Переходи c HTTPS на HTTP сторінки (згідно п. 5.5.2 в стандартах роботи Web). Наприклад, якщо у вас сайт на HTTP, то переходи без UTM-міток c https://www.youtube.com/ будуть зараховуватися в direct, тому що зашифрований протокол передачі даних HTTPS залишають поза передачею реферер.
7. Відвідувач включив налаштування приватності браузера (режим інкогніто) і доповнення для блокування скриптів на кшталт ScriptSafe (встановити можна тут ) та інших.
8. Помилки в коді. Іноді помилки в скриптах можуть оновлювати куки, і цей трафік буде записуватися в direct. Також при вказівці в коді посилання <а href = ..> атрибута 'rel = noreferrer' реферер передаватися не буде.
9. Помилки, коли браузер не передає реферер. Наприклад в IE8 втрачається реферер при використанні редирект методу Javascript: location.href і Meta refresh - 0. Також Internet Explorer втрачає реферер, коли користувач натискає на посилання, яка використовує JS метод window.open або коли користувач натискає на лінк, вставлений у Flash додаток .
10. Неправильна UTM-розмітка кампанії (наприклад, UTMSource замість UTM_source). Якщо у посилання є UTM-мітка, то GA ігнорує реферер. У тих випадках, де розмітка посилання не відповідає довідці, візити будуть записувати в direct.

обриви сесії

Призначені для користувача сесії можуть обриватися в наступних випадках:

1. Відсутність GA / GTM коду на посадочних сторінках сайту. При переході з посадкової сторінки без GA коду на наступну сторінку вашого сайту в реферер запишеться власний URL і UTM-міток вже не буде. GA запише цю сесію в direct (якщо власний домен доданий в «Список виключаються джерел переходу») або в referral (якщо не доданий).
2. Авторизація через соціальну мережу з повним переходом на неї замість авторизації через спливаюче вікно.
3. Повільно завантажується код GA - користувач переходить на наступну сторінку сайту до завантаження коду.
4. Відправка хіта вагою понад 8 кбайт на посадкової сторінці. Хіт не буде відправлятися в GA, відповідно сесія буде обриватися.
5. Некоректна настройка крос-доменного відстеження.

Інші причини, які спотворюють дані по direct трафіку

Відвідування сайту співробітниками компанії. Їх можна виключати по IP адресами, спеціальним cookies на корпоративних / проміжних сторінках, за допомогою розширень в браузерах або фільтрів в Google Analytics.

Відвідування сайту ботами. Знайти IP-адреси ботів можна в логах сайту або за допомогою OWOX BI Pipeline , Зібравши дані про активність на сайті в Google BigQuery. Обчислювати ботів рекомендуємо:

1. По поведінці на сайті. Наприклад, час візиту до 2 секунд, відсутність транзакцій, високий показник відмов і т.д.
2. За User Agent (браузери, провайдери, локація, пристрої). Наприклад, один провайдер (site.ru), один регіон (Москва, Росія).

Короткі рекомендації по пошуку проблем

Визначивши проблеми з direct трафіком, ви зможете виправити статистику за джерелами трафіку і, відповідно, точніше оцінювати ROAS.

Як вирішити проблеми з передачею referrer:

• Проставити UTM-мітки на всіх посиланнях (як розмічати кампанії, описано в статті «Що таке UTM-мітки і як їх застосовувати» ).
• Створити користувацький параметр рівня хіта і записувати в нього значення referrer, а потім аналізувати дані в спеціальних звітах .

Як знайти проблеми з обривами сесій:

• За допомогою консолі розробника і GA debugger .
• За допомогою записів сесій в Google Tag Assistant .
• Перевірити наявність GA / GTM коду на сторінках сайту, використовуючи Screaming Frog або інші сервіси.

Ми підготували наочне керівництво, як знайти проблеми з direct трафіком, і готові поділитися. вкажіть email , На який вам його відправити.

використані інструменти

Direct трафік в Google Analytics - причини виникнення і як його зменшити

Матеріали для скачування

Гайд: як перевірити трафік

Якщо ваш direct трафік Сеанси, коли користувач ввів URL сайту в адресному рядку або використовував ятати вище 30%, не поспішайте відкривати шампанське і відзначати приголомшливу впізнаваність компанії. Цілком можливо, що Google Analytics визначив в direct трафік відвідування сайту, які насправді до нього не відносяться.

Чому так відбувається? Причини можуть бути технічними (обриви сесій, редіректи і т.д.) і технологічними (переходи на сайт з мобільних додатків, email, месенджерів і т.д.).

До якої проблеми це призводить? Неможливо правильно оцінити ефективність джерел трафіку, які помилково записуються в direct.

У цій статті ви дізнаєтеся:

Причини, за якими GA визначає сесії в direct трафік

Google Analytics шукає інформацію про джерела трафіку в наступній послідовності:

1. Спочатку GA перевіряє наявність Adwords / DoubleClick тегів (gclid параметр для автоматичного позначки AdWords. Додається в URL цільової сторінки, коли користувач натискає на оголошення / gclsrc параметр для автоматичного позначки DoubleClick Search).
2. Потім - наявність UTM-міток Змінна, яка додається в URL і дозволяє системі веб-аналітики отримати додаткову інформацію про джерело трафіку (UTM_source / UTM_medium і т.д.). Детальніше про UTM-мітках читайте в нашій статті .
3. Після шукає HTTP referrer У протоколі HTTP один із заголовків запиту клієнта. Містить URL джерела запиту.
4. І нарешті, Google Analytics намагається ідентифікувати користувача по clientID або userID, перевіряючи збіг за останні 4 години, і прив'язати дані про хіті до останньої сесії користувача. Наприклад, користувач перейшов на сайт з рекламного оголошення і через 2 години купив товар в офлайн-магазині. Якщо дані про покупку відправляються в Google Analytics через Measurement Protocol і користувача вдається розпізнати по userID, хіт (досконала транзакція) буде зарахований в останню онлайн-сесію користувача, у якої вже є джерело трафіку (в нашому прикладі - google / cpc).

Щоб визначити джерело трафіку, досить одного з цих параметрів. Якщо нічого з перерахованого не знайдено, GA записує джерело трафіку - direct.

Детальна схема обробки даних описана в довідці GA.

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

Чи не передається реферер

HTTP Referer - в протоколі HTTP один із заголовків запиту клієнта. Містить URL джерела запиту. Якщо перейти з однієї сторінки на іншу, то referer другої сторінки буде містити адресу першої сторінки.

Реферер не передається в таких випадках:

1. Переходи по посиланнях з офлайнових документів: PDF, Word, Power Point і т.д.
2. Переходи з мобільних і стаціонарних додатків: Skype, Viber, Facebook, VK, Google Search і т.д.
3. Переходи з Email: Microsoft Outlook, Thunderbird і т.д.
4. Відправка даних по Measurement Protocol без вказівки source / medium.
5. Редіректи без передачі HTTP заголовка або UTM-міток на засланні. Наприклад, користувач зайшов за посиланням site.com, але система перенаправила його на site.ru. Якщо при редирект не передавати HTTP заголовок (в т.ч. реферер, який привів відвідувача на сайт, наприклад, facebook.com) або UTM-мітку в кінцевій посиланням (google.ru/?UTM_source=facebook&UTM_medium=cpc), то даний трафік потраплятиме в direct. Найчастіше ця помилка виникає, якщо ви робите редіректи на стороні клієнта (за допомогою javascript).
6. Переходи c HTTPS на HTTP сторінки (згідно п. 5.5.2 в стандартах роботи Web). Наприклад, якщо у вас сайт на HTTP, то переходи без UTM-міток c https://www.youtube.com/ будуть зараховуватися в direct, тому що зашифрований протокол передачі даних HTTPS залишають поза передачею реферер.
7. Відвідувач включив налаштування приватності браузера (режим інкогніто) і доповнення для блокування скриптів на кшталт ScriptSafe (встановити можна тут ) та інших.
8. Помилки в коді. Іноді помилки в скриптах можуть оновлювати куки, і цей трафік буде записуватися в direct. Також при вказівці в коді посилання <а href = ..> атрибута 'rel = noreferrer' реферер передаватися не буде.
9. Помилки, коли браузер не передає реферер. Наприклад в IE8 втрачається реферер при використанні редирект методу Javascript: location.href і Meta refresh - 0. Також Internet Explorer втрачає реферер, коли користувач натискає на посилання, яка використовує JS метод window.open або коли користувач натискає на лінк, вставлений у Flash додаток .
10. Неправильна UTM-розмітка кампанії (наприклад, UTMSource замість UTM_source). Якщо у посилання є UTM-мітка, то GA ігнорує реферер. У тих випадках, де розмітка посилання не відповідає довідці, візити будуть записувати в direct.

обриви сесії

Призначені для користувача сесії можуть обриватися в наступних випадках:

1. Відсутність GA / GTM коду на посадочних сторінках сайту. При переході з посадкової сторінки без GA коду на наступну сторінку вашого сайту в реферер запишеться власний URL і UTM-міток вже не буде. GA запише цю сесію в direct (якщо власний домен доданий в «Список виключаються джерел переходу») або в referral (якщо не доданий).
2. Авторизація через соціальну мережу з повним переходом на неї замість авторизації через спливаюче вікно.
3. Повільно завантажується код GA - користувач переходить на наступну сторінку сайту до завантаження коду.
4. Відправка хіта вагою понад 8 кбайт на посадкової сторінці. Хіт не буде відправлятися в GA, відповідно сесія буде обриватися.
5. Некоректна настройка крос-доменного відстеження.

Інші причини, які спотворюють дані по direct трафіку

Відвідування сайту співробітниками компанії. Їх можна виключати по IP адресами, спеціальним cookies на корпоративних / проміжних сторінках, за допомогою розширень в браузерах або фільтрів в Google Analytics.

Відвідування сайту ботами. Знайти IP-адреси ботів можна в логах сайту або за допомогою OWOX BI Pipeline , Зібравши дані про активність на сайті в Google BigQuery. Обчислювати ботів рекомендуємо:

1. По поведінці на сайті. Наприклад, час візиту до 2 секунд, відсутність транзакцій, високий показник відмов і т.д.
2. За User Agent (браузери, провайдери, локація, пристрої). Наприклад, один провайдер (site.ru), один регіон (Москва, Росія).

Короткі рекомендації по пошуку проблем

Визначивши проблеми з direct трафіком, ви зможете виправити статистику за джерелами трафіку і, відповідно, точніше оцінювати ROAS.

Як вирішити проблеми з передачею referrer:

• Проставити UTM-мітки на всіх посиланнях (як розмічати кампанії, описано в статті «Що таке UTM-мітки і як їх застосовувати» ).
• Створити користувацький параметр рівня хіта і записувати в нього значення referrer, а потім аналізувати дані в спеціальних звітах .

Як знайти проблеми з обривами сесій:

• За допомогою консолі розробника і GA debugger .
• За допомогою записів сесій в Google Tag Assistant .
• Перевірити наявність GA / GTM коду на сторінках сайту, використовуючи Screaming Frog або інші сервіси.

Ми підготували наочне керівництво, як знайти проблеми з direct трафіком, і готові поділитися. вкажіть email , На який вам його відправити.

використані інструменти