Отслеживание использования в офлайн-режиме

Как отслеживать использование вашего сайта в автономном режиме, чтобы вы могли обосновать, почему вашему сайту нужен лучший автономный режим.

Stephan Giesau

Martin Schierle

Узнайте, как отслеживать использование вашего сайта в автономном режиме, чтобы вы могли обосновать, почему вашему сайту нужен лучший офлайн-режим. Узнайте, каких ошибок и проблем следует избегать при внедрении аналитики использования в офлайн-режиме.

Подводные камни событий браузера в сети и в автономном режиме

Очевидное решение для отслеживания использования в офлайн-режиме – создать прослушиватели событий online и offline (поддерживаются многими браузерами) и поместить в них логику отслеживания аналитики. К сожалению, у этого подхода есть несколько проблем и ограничений:

• В целом отслеживание каждого события, связанного со статусом сетевого подключения, может быть избыточным и контрпродуктивным в мире, ориентированном на конфиденциальность, где должно собираться как можно меньше данных. Кроме того, события online и offline могут срабатывать при кратковременном отключении сети, которое пользователь может даже не заметить.
• Данные об офлайн-действиях не поступают на сервер аналитики.
• Если вы будете локально отслеживать временные метки, когда пользователь находится в офлайн-режиме, и отправлять данные о действиях офлайн на сервер аналитики, когда пользователь снова подключится к интернету, то это будет зависеть от того, вернется ли пользователь на ваш сайт. Если пользователь покидает ваш сайт из-за отсутствия офлайн-режима и больше не возвращается, у вас нет возможности это отследить. Возможность отслеживать уходы в офлайн – это критически важные данные для обоснования того, почему вашему сайту нужен лучший офлайн-режим.
• Событие online не очень надежно, поскольку оно сообщает только о доступе к сети, а не о доступе к интернету. Поэтому пользователь может по-прежнему быть офлайн, и отправка пинга отслеживания может не удаться.
• Даже если пользователь останется на текущей странице, находясь в офлайн-режиме, другие события аналитики (например, прокрутка, клики и т. д.) также не будут отслеживаться, хотя они могут содержать более релевантную и полезную информацию.
• Просто быть офлайн – не слишком осмысленно. Скорее всего, важнее всего знать, какие ресурсы не загружаются. Это особенно важно для одностраничных приложений, где потеря сетевого подключения может не привести к появлению понятной пользователям страницы с сообщением об ошибке. Вместо этого, скорее всего, будут незаметно сбоить случайные динамические части страницы.

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

Более эффективный подход: сервис-воркер

Решение, которое позволяет использовать офлайн-режим, также лучше подходит для отслеживания использования в офлайн-режиме. Вы можете хранить пинги аналитики в IndexedDB, пока пользователь находится в автономном режиме, и повторно отправлять их, когда пользователь снова выходит в сеть. Для Google Аналитики это уже доступно в модуле Workbox, но имейте в виду, что обращения, отправленные с задержкой более четырех часов, могут не обрабатываться.

В самом простом случае его можно активировать в сервис-воркере на основе Workbox с помощью этих двух строк:

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize();

В этом случае будут отслеживаться все события и просмотры страниц, произошедшие в офлайн-режиме, но вы не узнаете, что они произошли офлайн, поскольку они будут воспроизведены как есть. Вы можете управлять запросами отслеживания с помощью Workbox, добавив флаг offline в запрос Google Аналитики, используя специальный параметр:

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize({
  parameterOverrides: {
    customDimension1: 'offline',
  },
});

Что если пользователь покинет страницу из-за отсутствия подключения к интернету до того, как оно восстановится? Обычно в таких случаях сервис-воркер переходит в спящий режим, поскольку не может отправить данные при восстановлении подключения. Однако модуль Google Аналитики в Workbox использует Background Sync API. Фоновая синхронизация отправляет данные аналитики, когда соединение восстанавливается, даже если пользователь закрывает вкладку или браузер.

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

Одностраничные приложения и отложенная загрузка

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

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

Поскольку такие случаи действительно раздражают пользователей, имеет смысл их отслеживать. Сервис-воркеры – идеальное место для отслеживания ошибок сети и их последующего анализа. С помощью Workbox можно настроить глобальный обработчик catch, который будет сообщать странице о неудачных запросах, отправляя событие сообщения:

import { setCatchHandler } from 'workbox-routing';

setCatchHandler(({ event }) => {
  // https://developer.mozilla.org/docs/Web/API/Client/postMessage
  event.waitUntil(async function () {
    // Exit early if we don't have access to the client.
    // Eg, if it's cross-origin.
    if (!event.clientId) return;

    // Get the client.
    const client = await clients.get(event.clientId);
    // Exit early if we don't get the client.
    // Eg, if it closed.
    if (!client) return;

    // Send a message to the client.
    client.postMessage({
      action: "network_fail",
      url: event.request.url,
      destination: event.request.destination
    });

    return Response.error();

  }());
});

Вместо того чтобы прослушивать все неудачные запросы, можно отлавливать ошибки только на определенных маршрутах. Например, если мы хотим сообщать об ошибках, возникающих только на маршрутах к /products/*, мы можем добавить в setCatchHandler проверку, которая фильтрует URI с помощью регулярного выражения.

Более аккуратное решение – реализовать registerRoute с помощью собственного обработчика. Это инкапсулирует бизнес-логику в отдельный маршрут, что упрощает обслуживание более сложных сервисных работников:

import { registerRoute } from 'workbox-routing';
import { NetworkOnly } from 'workbox-strategies';

const networkOnly = new NetworkOnly();
registerRoute(
  new RegExp('https:\/\/example\.com\/products\/.+'),
  async (params) => {
    try {
      // Attempt a network request.
      return await networkOnly.handle(params);
    } catch (error) {
      // If it fails, report the error.
      const event = params.event;
      if (!event.clientId) return;
      const client = await clients.get(event.clientId);
      if (!client) return;

      client.postMessage({
        action: "network_fail",
        url: event.request.url,
        destination: "products"
      });

      return Response.error();
    }
  }
);

На последнем этапе страница должна прослушивать событие message и отправлять сигнал аналитики. Повторим, что запросы аналитики, которые происходят в офлайн-режиме, должны буферизоваться в сервис-воркере. Как описано выше, инициализируйте плагин workbox-google-analytics для встроенной поддержки Google Аналитики.

В примере ниже используется Google Аналитика, но вы можете использовать и другие сервисы.

if ("serviceWorker" in navigator) {
  // ... SW registration here

  // track offline error events
  navigator.serviceWorker.addEventListener("message", event => {
    if (gtag && event.data && event.data.action === "network_fail") {
      gtag("event", "network_fail", {
        event_category: event.data.destination,
        // event_label: event.data.url,
        // value: event.data.value
      });
    }
  });
}

Это позволит отслеживать сбои при загрузке ресурсов в Google Аналитике, где их можно анализировать с помощью отчетов. Полученные данные можно использовать для улучшения кеширования сервис-воркера и обработки ошибок в целом, чтобы сделать страницу более надежной и стабильной в условиях нестабильной сети.

Дальнейшие действия

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

Рекомендуем сначала настроить полное отслеживание, а затем постепенно расширять возможности офлайн-режима, уделяя особое внимание отслеживанию. Начните со страницы ошибки при отсутствии подключения к интернету. Ее легко создать с помощью Workbox. Это стандартная практика UX, похожая на создание собственных страниц 404. Затем переходите к более сложным резервным страницам и, наконец, к настоящему офлайн-контенту. Убедитесь, что вы рекламируете и объясняете это своим пользователям, и вы увидите рост использования. В конце концов, каждый время от времени уходит в офлайн.

Ознакомьтесь со статьями Как создавать отчеты о показателях и культуру эффективности и Как повысить скорость сайта, работая в команде. В них вы найдете советы о том, как убедить заинтересованных лиц инвестировать в ваш сайт. Хотя эти публикации посвящены эффективности, они должны помочь вам получить общее представление о том, как вовлечь заинтересованные стороны.