Измерение использования в автономном режиме

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

Stephan Giesau

Martin Schierle

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

Недостатки онлайн- и офлайн-событий в браузере

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

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

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

Более эффективный подход: работник сферы услуг.

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

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

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

googleAnalytics.initialize();

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

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

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

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

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

СПА-сервисы и отложенная загрузка

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

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

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

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 Analytics.

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

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 Analytics, где их можно будет анализировать с помощью отчетов . Полученные данные можно использовать для улучшения кэширования Service Worker и обработки ошибок в целом, чтобы сделать страницу более надежной и устойчивой в условиях нестабильной сети.

Следующие шаги

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

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

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