Работа с офлайн-пользователями в Google Analytics

Переводная статья блестящего Дэвида Вальехо о том, как отследить действия мобильных пользователей на сайте, если  постоянно обрывается мобильный интернет.

Мобильный трафик в России вырос на 15% по сравнению с 2016 годом, но проблемы со связью остались. Интернет обрывается везде: в метро, туннелях, поездках за город. Однако даже после обрыва интернета страницы могут прогружаться, а информация отправляться пользователю. Но как отслеживать события в момент обрыва соединения? В такой ситуации просмотры засчитаются, а события нет, ведь браузеры не переотправляют HTTP-запросы даже после восстановления соединения.

Если соединение оборвется, вы не узнаете какие действия предпринимал посетитель вашего сайта — куда заходил, как глубоко скроллил и т.д.

 

В этой статье мы расскажем, как отслеживать действия посетителей в офлайне. Для этого нам понадобятся:

1. Задания в Universal Analytics 
2. Веб хранилища браузеров
3. Отправка обращений с задержкой (параметр &qt)
4. Отправка собственных POST и HEAD запросов (протокол HTTP)
5. Пакетная отправка обращений (batching)

Задания в Universal Analytics

Задания собирают, проверяют и отправляют данные в Universal Analytics. Библиотека analytics.js выполняет задания по очереди каждый раз, когда команда send отправляется в ga(). Мы можем «перехватить» эти задания и модифицировать их при помощи analytics.js.

Мы сосредоточимся лишь на новом и важном типе задания — customTask. Его можно полностью настроить, оно имеет высший приоритет и первым поступает в обработку. Если хотите ознакомиться с полным списком заданий, почитайте справку Гугла.

Мы используем customTask для модификации Гугловского sendHitTask, поскольку customTask лучше работает с Диспетчером тегов Гугла. Так мы проверим, в онлайне ли посетитель. Процесс выглядит так:

[customTask] изменяет [sendHitTask] при помощи [нашего кода] прежде отправки обращения.

Для проверки соединения можно указать собственный сервер, но это ненадежно: нас интересует соединение между посетителем и серверами Гугл, а не просто качество соединения.

 

Офлайн-отслеживание

Мы отправим в Universal Analytics запрос методом HEAD . Если ответа от серверов нет, мы делаем вывод, что посетитель в офлайне, и оставляем обращение в браузере до того момента, как соединение с серверами Гугл восстановится. Такой способ страхует нас даже в том случае, когда причина не в соединении посетителя, а в подвисших серверах Гугл.

 

Статус 200 — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

 

Мы используем свойство браузера localStorage для создания очереди, но нам придется немного схитрить. Дело в том, что localStorage не имеет какой-либо структуры, а просто обрабатывает пару «ключ-значение». Поэтому для большей гибкости, мы будем использовать легкую программу, которая работает на всех браузерах — Lockr.

Lockr берет данные из sendHitTask. Если между посетителем и Гуглом нет соединения, обращение сохраняется в localStorage, а позднее падает к нам в Analytics с правильной отметкой времени запроса.

Есть также параметр &qt — время в очереди. Значение параметра — разница между моментом обращения и его отправкой. Значение должно быть больше или равно 0. Если обращение произошло 45 минут назад, параметр будет настроен так: &qt=2700000.
Не отправляйте обращения, которые совершились более четырех часов назад. Последнее обращение может быть отправлено не позже 03:59:59 следующего утра. Таким образом, максимальное значение для параметра &qt это 27 часов 59 минут 59 секунд. Получается, если вы отправите обращение ровно в полночь, оно не дойдет.

Запрос с методом HEAD

Метод HEAD возвращает значение заголовков и метаданные, без контента. Это отличный способ проверки конечной точки (серверов Гугл) без длительной проверки получения данных в ответ. Посмотрите, насколько метод HEAD лучше для нашей задачи, чем методы POST и GET:

 

Код JavaScript

Код состоит из трех частей:

  • Библиотека Lockr
  • Задание customTask
  • Метод HEAD и пакетная отправка запросов

Lockr. Загрузите библиотеку Lockr на ваш сайт. Лучше всего использовать пользовательский тег в Google Tag Manager: у этого тега наивысший приоритет и он сработает на всех страницах сайта.

Вот пример минифицированного JavaScript кода.  Браузер выполнит его перед тем, как запустится проверка на офлайн трекинг:

Код длинный: убедитесь, что вы его правильно скопировали. Теперь мы готовы приступить к отслеживанию офлайн-обращений.

Счетчик офлайн-обращений в Universal Analytics. Следующий JavaScript код работает с обычным счетчиком в Universal Analytics, поэтому обращения отправятся вместе с ga(‘send’,’…’). Настройте код следующим образом:

 

А вот код для функции обратного вызова _offlineTracker:

Как только вы создадите _offlineTracker и вызовите его в команде ga(‘set’, ‘customTask’, _offlineTracker), каждое обращение, которое использует это отслеживание, будет сохранено в очереди на отправку, если соединение прервется. Как только соединение восстановится, все обращение из очереди будут отправлены.

Отслеживание офлайн-обращений в Google Tag Manager. В Tag Manager можно обойтись пользовательской JavaScript переменной. Переменная будет самодостаточна, если мы настроим ее при помощи Lockr-кода. Дайте переменной имя, например {{JS — офлайн-обращения}} и включите следующий код:

 

Зайдите в Google Tag Manager — Теги — Создать — Конфигурация тега — Universal Analytics. Далее как на скриншоте:

После этого все теги с настройкой customTask будут защищены от обрыва соединения, и как только соединение восстановится, произойдет отправка всех обращений из очереди (пакетная отправка).

 

Пакетная отправка — batching

Universal Analytics позволяет отправлять обращения группами. Смысл в том, чтобы отправить как можно больше обращений за минимальное количество HTTP-запросов, но есть и ограничения:

  • За 1 запрос можно отправить только 20 обращений.
  • Максимальный размер данных внутри обращений — 16 килобайт.
  • Максимальный размер одного обращения — 8 килобайт.
  • Запрос выполняется методом POST.

Пакетная отправка срабатывает, когда количество сохраненных обращений превышает 1. Если обращений много, они делятся и отправляются по очереди.

 

Как улучшить код

Можно отказаться от части кода с originalSendTask и полностью переписать sendHitTask. Таким образом, можно пропустить запрос HEAD, потому что можно просто проверить, успешно ли выполнено изначальное обращение.

Если вы захотите переписать sendHitTask, вам нужно воспроизвести логику доставки запроса (transport). Библиотека analytics.js поддерживает три способа совершения запроса:

1. image — используется метод GET, который отправляет пиксель в конечную точку. Максимальный размер данных — 2 килобайта.
2. xhr — используется метод POST, максимальный размер — 8 килобайт.
3. beacon — метод POST используется с navigator.sendBeacon(), чтобы удостовериться, что запросы дойдут даже в том случае, если посетитель ушел со страницы.
Можно добавить специальные параметры и показатели для всех данных в очереди. Параметр можно назвать как угодно, а значение выставить true для отслеживания всех обращений, поступивших в момент обрыва соединения.

 

Применение

Если на ваш сайт часто заходят с телефонов, решение отслеживать офлайн-пользователей вам пригодится. Задания, представленные Google, очень интересны, поскольку помогают управлять способом доставки данных через сайт. С добавлением задания customTask стало легче отслеживать задания в Диспетчере тегов Google.

Если у вас есть приложение, которое может быть использовано активно в офлайне, вы сможете отслеживать офлайн-обращения с помощью библиотеки sw-offline-google-analytics.

Оригинал статьи: Track Users Who Are Offline In Google Analytics