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

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

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 в пинг аналитики, используя настраиваемое измерение ( cd1 в примере кода ниже):

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

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

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

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

SPA и ленивая загрузка

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

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

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

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

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

Героическое фото Джей Си Геллидона на Unsplash .