Настройка Google Analytics: более точный расчет продолжительности просмотра

Если Вы не знаете, как считается продолжительность просмотра страницы или не уверены в своих знаниях, прочитайте сначала этот материал.

Из-за особенности работы юольшинства систем веб-аналитики (в частности, Google Analytics и Яндекс.Метрики) данные о времени нахождения посетителя на сайте и показателе отказов существенно отличаются от правды.

Как это исправить?

В интернете можно найти разные вариации решения этой проблемы.

Одно из них (наиболее адекватное) я нашёл на optimization.com.ua. Там решение описывается как более точный расчёт показателя отказов в Google Analytics, который к тому же влияет на позиции сайта в ПС Google.

С утверждениями про отказы и позиции я не согласен, но решение интересное. Хотя, оно имеет свои плюсы и минусы (последних, к сожалению, больше). Но обо всём по-порядку.

Суть решения заключается в том, чтобы автоматически создавать виртуальное событие с определённой периодичностью.

Используя Google Event Tracking API, мы сможем каждые 10 секунд (или чаще, или реже) сообщать Google Analytics о том, что посетитель Х всё ещё находится на нашем сайте. Сайт будет обновлять Google Analytics каждые 10 секунд событием категории «Time», действием «Log», а значение будет соответствовать последовательности 0:10, 0:20, 0:30, 0:40 и так далее.

Собственно сам код, который нужно добавить на каждую страницу сайта:

<script type="text/javascript">
//Google Analytics Bounce Rate
(function (tos) {
  window.setInterval(function () {
    tos = (function (t) {
      return t[0] == 50 ? (parseInt(t[1]) + 1) + ':00' : (t[1] || '0') + ':' + (parseInt(t[0]) + 10);
    })(tos.split(':').reverse());
    window.pageTracker ? pageTracker._trackEvent('Time', 'Log', tos) : _gaq.push(['_trackEvent', 'Time', 'Log', tos]);
  }, 10000);
})('00');
</script>

Тут можно задать свои обозначения:

Time – Название категории события, которую Вы найдёте в статистике Google Analytics.

Log – Название действия события, которое Вы найдёте в статистике Google Analytics.

10000 – Периодичность обновления информации о посетителе в миллисекундах. Т.е. как часто мы проверяем, с нами ли посетитель.

Какой эффект получаем?

  1. Более точный показатель «Средняя длительность просмотра страницы».
  2. Любое посещение длительностью более 10 секунд не будет считаться отказом.
  3. Много информационного шума в отчётах по событиям

С длительностью порсмотра страницы всё просто — каждые 10 секунд мы создаём новое событие, которое запоминает Google Analytics. Если оно оказывается последним, то оно участвует в расчёте длительности просмотра (см. раздел «Как считается время нахождения на странице»).

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

Что из этого следует?

Слепо добавив этот скрипт на свой сайт будьте готовы к тому, что:

  • У Вас не будет адекватной цифры, описывающей показатель отказов на сайте. 10-секундные посещения — это ведь не цель существования Вашего сайта?
  • Вы усложните себе изучение отчёта по событиям
  • В Google Analytics есть лимит на использование 500 GATC events (Google Analytics Tracking Code), т.е. отслеживаемых событий. Сюда входят и просмотры страниц, и события, которые мы сами отслеживаем. Т.е. при стандартных настройках (обновление раз в 10 секунд) этот лимит будет исчерпан примерно за 83 минуты (500 событий * 10 секунд / 60 секунд в минуту). Конечно, сложно представить среднюю сессию длиной больше часа, но это обязательно нужно учитывать.

Стоит ли использовать метод?

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

Хорошо подумайте перед тем, как использовать данный метод.

Тщательно продумайте, на каких страницах и в каком виде Вы будете его использовать.

Заранее подумайте о последствиях.

Несколько вариаций использоватия метода:

  • Создовать событие не каждые 10 секунд, а через постоянно увеличивающийся интервал времени (например: 10, 15, 25, 40, …)
  • Повесить событие на закрытие вкладки и браузера
  • Использовать аналог точного показателя отказов в Яндекс.Метрике. Т.е. создавать одно событие для одного просмотра страницы через определённый интервал времени (в Метрике — это через 15 секунд после начала просмотра страницы).
  • Создавать событие при выполнении набора обязательных действий. Например, скроллинг на 70% длины страницы + время просмотра более 40 секунд.

Если Вы всё же решили использовать метод

В процессе изучения работы предложенного решения я нашёл способ избавиться от «шума» в отчётах по событиям.

  1. Открываем отчёт «Содержание / События / Лучшие события».
  2. Переходим в настройку отчёта
  3. Устанавливаем фильтр

    Здесь Time — это название категории, которое указано в коде костыля. Если Вы меняли название в коде, его же нужно использовать и в этом фильтре.

В итоге получаем более наглядную информацию о событиях:

Если Вы посмотрите этот же отчёт с основным параметром «Ярлык события», Вы увидите примерно следующее:

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

 

13 комментариев
  1. snegireff:

    Отличная идея!

  2. Юля:

    Сколько по времени аналитика хранит данные? какой максимальный период можно выбрать при просмотре отчётов?

  3. Dmitriy Sokolnikov:

    Я вот тоже столкнулся с данной проблемой, но планировал решать ее немного другим, более точным (имхо) способом. Дело в том, что таким способом мы отследим точное время открытия вкладки, а оно может (и часто) отличается от фактического времени активности пользователя. Я думаю выстроить алгоритм на основе событий мыши и клавиатуры, по принципу — есть события ++1 на время, активности, нет событий — счетчик не увеличиваем, и потом единым разом передаем это число в систему аналитики

    • Передаём куда именно? Насколько я знаю, в GA нельзя передать именно время просмотра страницы.

      • Dmitriy Sokolnikov:

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

        • Ну да, получится вариация на эту тему с определёнными ограничениями. Например, совместить время посещения и какую-то другую пользовательскую переменную уже будет непросто.
          Поясните, что Вы хотите делать с полученными данными? Как их использовать? Какие выводы собираетесь делать?

          • Dmitriy Sokolnikov:

            Я хочу получить фактическое чистое время реального взаимодействия пользователя со страницей. Мне оно нужно для четкого отслеживания интереса пользователя к странице для сегментации трафика, соответственного понимания какой канал нужно форсировать. Данная проблема актуальна для одностраничников и лендингов всяких. У меня например весь функционал в скриптах, перезагрузок страницы нет, и вот бывает юзер проводит на странице 5 сек, а бывает 40, и GA успешно всем им присваивает «0»!.

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

              А для анализа посетителей лучше использовать вебвизор или кликтейл. Запасайтесь попкорном )

              • Dmitriy Sokolnikov:

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

                • ок. провисания до учтутся. А как высобираетесь интерпретировать провисания после? Вариантов масса:
                  — болтал по телефону и бездумно крутил колёсиком вверх-вниз
                  — пялился на красивые картинки, не будучи заинтересованным в товаре/услуге/сервисе/…
                  — читал и думал, надо ли ему это
                  — пытался понять, что это и как он сюда попал
                  и т.д.

                  Кто-то провёл 3 минуты, кто-то 10 секунд. Никакой даже микроконверсии не было. Какие из этого выводы, если вы не знаете, что в этот момент делал человек, о чём думал?

                  Статистика крутая штука, но если её неправильно интерпретировать, она будет работать совсем не на пользу.

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

                  • Dmitriy Sokolnikov:

                    Ни в коем разе, наоборот, спасибо за беседу) По наблюдайте немного за собой, как ведете себя на сайте. Из моего опыта просмотра сотни сессий веб визора, все посещения достаточно типичны, со временем и некоторые закономерности начинаешь видеть. В общем я пришел к выводу что фактическое время активности очень важный параметр, показывающий интерес пользователя к сайту, зависимость считаю прямопропорциональной(!) и лего можно выделить группы случайных посетителей, которым содержание сайта не интересно вообще (0-3 сек), на немного вникнувших но не заитересовавшихся (3-15 сек), приценивающийся (15-60 сек) и т д.

                    С провисаниями после также проблем не вижу, сегодня написал скрипт суммирущий все микрособытия движения мыши, у кого-то 200 за сессию, у кого-то 4000, («пробег» походу по факту), теперь пытаюсь запихнуть в метрику и аналитик, но что-то фигово пока выходит

                    • С метрикой всё сложно — она не настолько гибконастраиваемая. Но м.б. это и не надо — в вебвизоре есть фильтр + степень активности посетителей.

                      С аналитиксом можно считать активное время, записывать его в свою переменную и потом присваивать пользовательскую переменную уровня страницы в момент закрытия вкладки. Я не силён в js, но видел страницы, которые выкидывают всякие всплывающие окна в момент закрытия.

Добавить комментарий для Dmitriy Sokolnikov Отменить ответ

Ваш адрес email не будет опубликован.