Пошаговая инструкция: как анализировать статьи в блоге
Веб-аналитика эволюционирует, и в последнее время, все быстрее. Появляются новые потребности и задачи по более глубокому пониманию качества взаимодействия пользователей с вашим сайтом. И анализ статей в блоге не исключение.
Зачем все это надо?
Все начиналось с анализа показателя отказов и среднего времени на странице, но эти данные, в связи со спецификой их расчета (по сути, если пользователь просмотрел только одну статью, то отказы будут 100%), не дают однозначного понимания того, как пользователи читали ваш контент.
Затем, с появлением GTM, специалисты придумывают новые способы лучше увидеть в цифрах (не берем карты скроллинга и кликов, так как данные, как правило визуальные, а не в цифрах) качество чтения. Как пример, это материал Анастасии Тимошенко, про скроллинг. Хороший подход, но по сути, это анализ всей страницы, а не содержимого, чего в наших реалиях, уже маловато.
А вот хороший пример рекламной кампании, пользователь читает мою статью про возможности работать с сырыми данными из Google Analytics, и пристально изучает раздел с интеграцией с bigQuery, а я же, это как раз и помогаю настраивать. И я делаю ремаркетинг только на тех, кому действительно интересна именно эта услуга.
Или другой пример, в блоге интернет-магазина вышел материал о новинках мобильных телефонов, и пользователь уделил пристальное внимание телефону Xiaomi Redmi Note 5, и что делает магазин, ну вы уже догадались.
А еще круто, это будет работать в разных сервисах, SaaS и тп., где с обзорной статьи про функции продукта, мы можем привлекать на тематический вебинар тех, кто заинтересовался какой-то конкретной функцией.
Затем, с появлением GTM, специалисты придумывают новые способы лучше увидеть в цифрах (не берем карты скроллинга и кликов, так как данные, как правило визуальные, а не в цифрах) качество чтения. Как пример, это материал Анастасии Тимошенко, про скроллинг. Хороший подход, но по сути, это анализ всей страницы, а не содержимого, чего в наших реалиях, уже маловато.
А вот хороший пример рекламной кампании, пользователь читает мою статью про возможности работать с сырыми данными из Google Analytics, и пристально изучает раздел с интеграцией с bigQuery, а я же, это как раз и помогаю настраивать. И я делаю ремаркетинг только на тех, кому действительно интересна именно эта услуга.
Или другой пример, в блоге интернет-магазина вышел материал о новинках мобильных телефонов, и пользователь уделил пристальное внимание телефону Xiaomi Redmi Note 5, и что делает магазин, ну вы уже догадались.
А еще круто, это будет работать в разных сервисах, SaaS и тп., где с обзорной статьи про функции продукта, мы можем привлекать на тематический вебинар тех, кто заинтересовался какой-то конкретной функцией.
Как это работает
Когда я думал над этой задачей, основная проблема заключалась в том, что большинство решений не являлись достаточно универсальными, так как верстка на каждом сайте своя. Например, в некоторых статьях, каждый логический блок помещен внутри div с своим классом, а в других, все идет сплошным текстом, с заголовками, но в одном <p>.
Но почти у всех материалов, есть особенность — заголовки, которые, разделяют логические блоки, вот их мы и возьмем за основу.
CSS selectors
Да, и с помощью css селекторов, мы можем просто их взять. А кому не просто, вот вам пару материалов про то, как с ними работать (это единственная часть решения, которая будет индивидуально настраиваться):
https://www.w3schools.com/cssref/css_selectors.asp — это просто обзор всех вариантов, у меня эта вкладка открыта постоянно
https://www.simoahava.com/gtm-tips/10-useful-css-selectors/ — кто не знает Simo? Все его знают и он молодец, и материал хороший
Element Visibility
А еще в GTM у нас есть триггер типа element visibility, которые срабатывает в тот момент, когда нужные вам элемент попадает в видимую область экрана пользователя (вообще крутая штука, можем отслеживать попапы, thank you state, успешное выполнение форм и все такое). Настраивается он, как раз по селектору:
Но почти у всех материалов, есть особенность — заголовки, которые, разделяют логические блоки, вот их мы и возьмем за основу.
CSS selectors
Да, и с помощью css селекторов, мы можем просто их взять. А кому не просто, вот вам пару материалов про то, как с ними работать (это единственная часть решения, которая будет индивидуально настраиваться):
https://www.w3schools.com/cssref/css_selectors.asp — это просто обзор всех вариантов, у меня эта вкладка открыта постоянно
https://www.simoahava.com/gtm-tips/10-useful-css-selectors/ — кто не знает Simo? Все его знают и он молодец, и материал хороший
Element Visibility
А еще в GTM у нас есть триггер типа element visibility, которые срабатывает в тот момент, когда нужные вам элемент попадает в видимую область экрана пользователя (вообще крутая штука, можем отслеживать попапы, thank you state, успешное выполнение форм и все такое). Настраивается он, как раз по селектору:
Но если, внимательно присмотреться к тому, что этот триггер отправляет в dataLayer, то можно увидеть интересные переменные:
А именно, gtm.visibilityFirstTime и gtm.visibilityLastTime, которые считают время начала просмотра элемента и окончания. Вот мы их и возьмем для решения.
Посчитав разницу времени с окончания видимости элемента со следующим, можем оценить время прочтения блока.
Local Storage и beforeunload
А еще круто было бы хранить данные о прочтении каждого блока, и затем перед выходом преобразовывать эти данные и загружать в google analytics или facebook.
Для хранения данных, подойдет localStorage (почитать о использовании). А используя вот такую конструкцию: jQuery(window).bind('beforeunload', function(){}), мы можем отлавливать момент, когда пользователь уходит со страницы.
Алгоритм
Итак, общий алгоритм следующий:
Посчитав разницу времени с окончания видимости элемента со следующим, можем оценить время прочтения блока.
Local Storage и beforeunload
А еще круто было бы хранить данные о прочтении каждого блока, и затем перед выходом преобразовывать эти данные и загружать в google analytics или facebook.
Для хранения данных, подойдет localStorage (почитать о использовании). А используя вот такую конструкцию: jQuery(window).bind('beforeunload', function(){}), мы можем отлавливать момент, когда пользователь уходит со страницы.
Алгоритм
Итак, общий алгоритм следующий:
- Как только заголовок попадает в видимую область экрана, мы считаем время в секундах прочтения блока, как разницу с предыдущим заголовком.
- Записываем секунды и название заголовков в localStorage
- При выходе со страницы, записываем для последнего заголовка время (из расчета чтения всего документа)
- Преобразовываем данные в нужный формат
- Отправляем в систему аналитики
Настраиваем!
Переменные
Нам нужны три переменные типа DataLayer:
gtm.element:
Нам нужны три переменные типа DataLayer:
gtm.element:
gtm.visibleFirstTime:
gtm.visibleLastTime:
Триггеры
Нужно два триггера, один простой DOM Readу, при необходимости, вы можете добавить туда правило, чтобы он срабатывал, только для статей блога.
И Element Visibility:
Нужно два триггера, один простой DOM Readу, при необходимости, вы можете добавить туда правило, чтобы он срабатывал, только для статей блога.
И Element Visibility:
Тут важно настроить:
Selection Method — CSS Selector (но если у вас каждый заголовок имеет id, то вам повезло, и можно использовать id)
Element Selector — туда пишем сам селектор, проще всего что-то типа h1, h2, h3, но проверьте свою верстку
When to fire this trigger — Every time … (т.е. триггер будет срабатывать каждый раз, когда заголовок будет попадать в видимую область экрана)
Остальное, не столь важно.
Тэги
Для нашей задачи нужно два тэга (оба типа Custom HTML), один, который будет слушать время и складывать в localStorage (код на pastebin):
Selection Method — CSS Selector (но если у вас каждый заголовок имеет id, то вам повезло, и можно использовать id)
Element Selector — туда пишем сам селектор, проще всего что-то типа h1, h2, h3, но проверьте свою верстку
When to fire this trigger — Every time … (т.е. триггер будет срабатывать каждый раз, когда заголовок будет попадать в видимую область экрана)
Остальное, не столь важно.
Тэги
Для нашей задачи нужно два тэга (оба типа Custom HTML), один, который будет слушать время и складывать в localStorage (код на pastebin):
Где триггер активации будет:
И второй, который будет слушать факт ухода со страницы и отправлять данные (код на pastebin):
Триггер активации — Dom Ready.
Во втором триггере отправка данных в Google Analytics я делаю через autoEvent (почитать о том, как его можно настроить autoEvent), а в facebook, кастомными параметрами:
Во втором триггере отправка данных в Google Analytics я делаю через autoEvent (почитать о том, как его можно настроить autoEvent), а в facebook, кастомными параметрами:
// send autoEvents to GA for each header
newArraySeries.forEach(function(e) {
dataLayer.push({'event': 'autoEvent', 'eventCategory': 'AO — scrollBlocks', 'eventAction': document.title, 'eventLabel': e.name, 'eventValue': Math.round(e.data)});
fbq('track', 'AO — scrollBlocks', {
'eventAction': document.title,
'eventLabel': e.name,
'eventValue': Math.round(e.data)
});
})Заключение
Остается рассказать о том, как работать с этими данными. По сути время прочтения каждого блока и говорит о заинтересованности в том или ином разделе статьи.
Для анализа можно использовать custom report (ссылка на шаблон отчета):
Для анализа можно использовать custom report (ссылка на шаблон отчета):
И если нажать на конкретную статью:
В поле Avg. Value будет среднее время в секундах.
Также, мы можем строить сегменты и делать аудитории ремаркетинга по конкретным материалам и блокам/разделам внутри статей.
В планах, я думаю еще посчитать символы в разделах/блоках и вместе со временем считать качество чтение глубже, также можно накрутить переход по ссылкам внутри блоков, просмотр видео и нажатие на картинки.
