Автор: Том Каппер (Tom Capper) – консультант по вопросам аналитики в агентстве интернет-маркетинга Distilled (Великобритания), эксперт Moz.

Если вы когда-нибудь сравнивали данные двух аналитических инструментов на одном и том же сайте или сравнивали аналитику с отчётами и продажах, то, вероятно, замечали, что они не всегда совпадают. В этой статье я объясню, почему в статистике платформ веб-аналитики отсутствуют данные, и насколько крупными эти потери могут быть.

В рамках статьи мы сосредоточимся на Google Analytics (GA) как самом популярном аналитическом сервисе, хотя большинство аналитических платформ, внедряемых on-page, имеют те же проблемы. Сервисы, которые полагаются на журналы сервера, избегают некоторых из этих проблем, но они настолько редко используются, что мы не будем касаться их в этой статье.

Тестовые конфигурации Google Analytics в Distilled

На сайте Distilled.net у нас имеется стандартный ресурс Google Analtics, работающий из HTML-тега в Диспетчере тегов Google (Google Tag Manager, GTM). Кроме того, в последние два года я использовал три дополнительные параллельные реализации Google Analytics, предназначенные для того, чтобы измерить расхождения между разными конфигурациями.

Две из этих дополнительных реализаций – одна в GTM, а другая on-page – управляют локально хранимыми, переименованными копиями JavaScript-файла Google Analytics (www.distilled.net/static/js/au3.js вместо www.google-analytics.com/analytics.js), чтобы их было сложнее обнаружить блокировщикам рекламы.

Я также использовал переименованные JavaScript-функции («tcap» и «Buffoon» вместо стандартного «ga») и переименованные трекеры («FredTheUnblockable» и «AlbertTheImmutable»), чтобы избежать проблемы дублирования трекеров (что часто может приводить к проблемам).

Наконец, у нас имеется конфигурация «DianaTheIndefatigable», которая имеет переименованный трекер, но использует стандартный код и реализована на уровне страницы.

Все наши конфигурации отражены в таблице ниже:

Я протестировал их функциональность в разных браузерах и блокировщиках рекламы, анализируя просмотры страниц, появляющиеся в инструментах разработчика браузера:

Причины потери данных

  1. Блокировщики рекламы

Блокировщики рекламы, преимущественно в виде браузерных расширений, получают всё большее распространение. Изначально основной причиной их использования было улучшение производительности и опыта взаимодействия на сайтах с большим количеством рекламы. В последние годы возрос акцент на конфиденциальности данных, что также способствовало росту популярности адблокеров.

Влияние блокировщиков рекламы

Некоторые адблокеры блокируют платформы веб-аналитики по умолчанию, другие могут быть дополнительно настроены для выполнения этой функции. Я протестировал сайт Distilled с помощью Adblock Plus и uBlock Origin – двух самых популярных десктопных браузерных расширений для блокировки рекламы, но стоит отметить, что адблокеры также всё чаще используются и на смартфонах.

Были получены следующие результаты (все цифры относятся к апрелю 2018 года):

Как видно из таблицы, изменённые настройки GA не сильно помогают противостоять блокировщикам.

Потеря данных из-за блокировщиков рекламы: ~10%

Использование адблокеров может находиться на уровне 15-25% в зависимости от региона, но многие из этих установок – это AdBlock Plus с настройками по умолчанию, при которых, как мы видели выше, отслеживание не блокируется.

Доля AdBlock Plus на рынке блокировщиков рекламы варьируется в диапазоне 50-70%. По последним оценкам, эта цифра ближе к 50%. Поэтому, если допустить, что не более 50% установленных адблокеров блокируют аналитику, то мы получим потерю данных на уровне примерно 10%.

  1. Функция «Do Not Track» в браузерах

Это ещё одна функция, использование которой мотивировано защитой конфиденциальности. Но на этот раз речь идёт не о надстройке, а о функции самих браузеров. Выполнение запроса «Не отслеживать» не является обязательным для сайтов и платформ, но, например, Firefox предлагает более сильную функцию под одним и тем же набором параметров, что я также решил протестировать.

Влияние «Do Not Track»

Большинство браузеров теперь предлагают опцию отправки сообщения «Не отслеживать». Я протестировал последние выпуски браузеров Firefox и Chrome для Windows 10.

Опять же, похоже, что здесь изменённые настройки также не сильно помогают.

Потеря данных из-за «Do Not Track»: <1%

Тестирование показало, что только функция Tracking Protection в браузере Firefox Quantum влияет на трекеры. Firefox занимает 5% браузерного рынка, но защита от отслеживания не включена по умолчанию. Поэтому запуск этой функции не оказал влияния на тренды Firefox-трафика на Distilled.net.

  1. Фильтры

Фильтры, которые вы настраиваете в системе аналитики, могут преднамеренно или непреднамеренно занижать объёмы получаемого трафика в отчётности.

Например, фильтр, исключающий определённые разрешения экрана, которые могут являться ботами или внутренним трафиком, явно приведёт к некоторому занижению трафика.

Потеря данных из-за фильтров: N/A

Влияние этого фактора сложно оценить, поскольку эта настройка разнится в зависимости от сайта. Но я настоятельно рекомендую иметь дублированное, «основное» представление (без фильтров), чтобы можно было оперативно увидеть потерю важной информации.

  1. GTM vs on-page vs неправильно расположенный код

В последние годы Google Tag Manager становится всё более популярным способом внедрения аналитики из-за его гибкости и лёгкости внесения изменений. Однако я давно замечаю, что этот метод реализации GA может приводить к занижению показателей в сравнении с настройкой на уровне страницы.

Мне также было любопытно, что случится, если не последовать рекомендациям Google касательно настройки кода on-page.

Сочетая собственные данные с данными с сайта моего коллеги  Дома Вудмена (Dom Woodman), который использует аналитическое расширение Drupal, а также GTM, я смог увидеть разницу между Диспетчером тегов и неправильно расположенным на странице кодом (помещённым в нижней части тега <body>). Затем я сопоставил эти данные с моими собственными GTM-данными, чтобы увидеть полную картину по всем 5 конфигурациям.

Влияние GTM и неправильно расположенного on-page кода

Трафик как процент от базовой линии (стандартная реализация с использованием Диспетчера тегов):

Основные выводы:

  • On-page код обычно регистрирует больше трафика, чем GTM;
  • Изменённый код обычно находится в пределах погрешности, кроме изменённого GTM-кода в Internet Explorer;
  • Неправильно расположенный код отслеживания будет стоить вам до 30% вашего трафика по сравнению с правильно реализованным on-page кодом, в зависимости от браузера (!);
  • Пользовательские конфигурации, призванные получать больше трафика через уклонение от блокировщиков рекламы, этого не делают.

Также стоит отметить, что пользовательские реализации по факту получают меньше трафика, чем стандартные. В случае on-page кода потери находятся в рамках погрешности, но в случае Google Tag Manager есть ещё один нюанс, который мог повлиять на итоговые данные: поскольку я использовал нефильтрованные профили для сравнения, в главном профиле находилось много бот-спама, который в основном маскировался под Internet Explorer. На сегодняшний день наш основной профиль является наиболее заспамленным, но также используется в качестве уровня, выбранного для сравнения, поэтому разница между on-page кодом и Диспетчером тегов на самом деле, вероятно, несколько больше.

Потеря данных из-за GTM: 1-5%

Потери, связанные с Диспетчером тегов Google, варьируются в зависимости от того, какие браузеры и устройства используются посетителями вашего сайта. На сайте Distilled.net разница составляет около 1,7%, наша аудитория активно использует десктопы и является технически продвинутой, Internet Explorer используется редко. В зависимости от вертикали потери могут достигать 5%.

Я также сделал разбивку по устройствам:

Потеря данных из-за неправильно расположенного on-page кода: ~10%

На Teflsearch.com из-за неправильно расположенного кода терялось около 7,5% данных, против GTM. Учитывая, что Диспетчер тегов сам по себе занижает данные, то общие потери могли легко достигать 10%.

Бонус: потери данных из каналов

Выше мы рассмотрели области, в которых вы можете терять данные в целом. Однако есть и другие факторы, ведущие к получению неполных данных. Мы рассмотрим их более кратко. Главными проблемами здесь являются «тёмный» трафик и атрибуция.

«Тёмный» трафик

«Тёмный» трафик – это direct-трафик, которые в действительности не является прямым. И это становится всё более распространённой ситуацией. Типичные причины возникновения «тёмного» трафика:

  • Непомеченные кампании email-маркетинга;
  • Непомеченные кампании в приложениях (особенно в Facebook, Twitter и т.д.);
  • Искажённый органический трафик;
  • Данные, отправляемые из-за ошибок, допущенных в процессе настройки отслеживания (могут также появляться как self-referrals);

Также стоит отметить тренд в направлении роста истинно прямого трафика, который исторически был органическим. Например, в связи с усовершенствованием функции автозаполнения в браузерах, синхронизации истории поиска на разных устройствах и т.п., люди как бы «вводят» URL, который они искали ранее.

Атрибуция

Я писал об этом более подробно здесь. В целом, сеанс в Google Analytics (и на любой другой платформе) – это довольно произвольный конструкт. Вы можете считать очевидным то, как группа обращений должна объединяться в один или больше сеансов, но в действительности, этот процесс полагается на ряд довольно сомнительных предположений. В частности, стоит отметить, что Google Analytics обычно приписывает прямой трафик (включая «тёмный» трафик) предыдущему не-direct источнику, если таковой существует.

Вместо заключения

Я был несколько удивлен некоторыми из полученных мною результатов, но я уверен, что охватил не всё, и есть и другие пути потери данных. Так что, исследования в этой области можно продолжать и дальше.

ИСТОЧНИКMoz
Редактор-переводчик. Специализируется на западном интернет-маркетинге и SEO. Освещает события в этой области с 2014 года.