Medir o uso off-line

Como rastrear o uso off-line do seu site para que você possa justificar por que ele precisa de uma experiência off-line melhor.

Stephan Giesau

Martin Schierle

Saiba como rastrear o uso off-line do seu site para que você possa justificar por que ele precisa de um modo off-line melhor. Entender quais armadilhas e problemas evitar ao implementar análises de uso off-line.

As armadilhas dos eventos de navegador on-line e off-line

A solução óbvia para rastrear o uso off-line é criar listeners de eventos para os eventos online e offline (que são compatíveis com muitos navegadores) e colocar sua lógica de rastreamento de análise nesses listeners. Infelizmente, há vários problemas e limitações com essa abordagem:

• Em geral, rastrear todos os eventos de status de conexão de rede pode ser excessivo e contraproducente em um mundo centrado na privacidade, em que o mínimo de dados possível deve ser coletado. Além disso, os eventos online e offline podem ser acionados por apenas uma fração de segundo de perda de rede, o que um usuário provavelmente nem veria ou notaria.
• O acompanhamento de análise da atividade off-line não chega ao servidor de análise.
• O rastreamento local de um carimbo de data/hora quando um usuário fica off-line e o envio da atividade off-line ao servidor de análise quando o usuário volta a ficar on-line dependem de o usuário acessar seu site novamente. Se o usuário sair do site devido à falta de um modo off-line e nunca mais voltar, não será possível rastrear isso. A capacidade de rastrear desistências off-line é um dado essencial para criar um caso sobre por que seu site precisa de um modo off-line melhor.
• O evento online não é muito confiável, porque só sabe sobre o acesso à rede, não o acesso à internet. Portanto, um usuário ainda pode estar off-line, e o envio do ping de rastreamento ainda pode falhar.
• Mesmo que o usuário permaneça na página atual enquanto estiver off-line, nenhum dos outros eventos de análise (por exemplo, eventos de rolagem, cliques etc.) será rastreado, o que pode ser a informação mais relevante e útil.
• Estar off-line não é muito significativo. É provável que o mais importante seja saber quais recursos não carregam. Isso é especialmente relevante para aplicativos de página única (SPAs), em que uma conexão de rede interrompida pode não levar a uma página de erro off-line do navegador, que os usuários entendem. Em vez disso, é provável que partes aleatórias e dinâmicas da página falhem silenciosamente.

Ainda é possível usar essa solução para entender o uso off-line, mas as muitas desvantagens e limitações precisam ser consideradas com cuidado.

Uma abordagem melhor: o service worker

A solução que ativa o modo off-line também é uma solução melhor para acompanhar o uso off-line. É possível armazenar pings de análise no IndexedDB enquanto o usuário estiver off-line e reenviá-los quando ele ficar on-line novamente. No Google Analytics, isso já está disponível em um módulo do Workbox, mas lembre-se de que os hits enviados com mais de quatro horas de atraso podem não ser processados.

Na forma mais simples, ele pode ser ativado em um service worker baseado no Workbox com estas duas linhas:

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

googleAnalytics.initialize();

Isso rastreia todos os eventos e pings de visualização de página atuais enquanto o usuário está off-line, mas você não saberia que eles aconteceram off-line, já que são reproduzidos como estão. É possível manipular solicitações de rastreamento com o Workbox adicionando uma flag offline ao ping do Analytics, usando uma dimensão personalizada:

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

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

E se o usuário sair da página por estar off-line, antes que uma conexão de Internet retorne? Normalmente, isso coloca o service worker em suspensão, já que ele não pode enviar os dados quando a conexão é restabelecida. No entanto, o módulo do Google Analytics do Workbox usa a API Background Sync. A sincronização em segundo plano envia os dados de análise quando a conexão é restabelecida, mesmo que o usuário feche a guia ou o navegador.

Ainda há uma desvantagem: embora isso permita que o rastreamento atual funcione off-line, é provável que você não veja muitos dados relevantes até implementar um modo off-line básico. Os usuários ainda sairiam do site rapidamente quando a conexão fosse interrompida. Mas agora você pode pelo menos medir e quantificar isso, comparando a duração média da sessão e o engajamento do usuário para usuários com a dimensão off-line aplicada em relação aos usuários normais.

SPAs e carregamento lento

Se os usuários que visitam uma página criada como um site de várias páginas ficarem off-line e tentarem navegar, a página off-line padrão do navegador vai aparecer, ajudando os usuários a entender o que está acontecendo. No entanto, as páginas criadas como aplicativos de página única funcionam de maneira diferente. O usuário permanece na mesma página, e o novo conteúdo é carregado dinamicamente pelo AJAX sem nenhuma navegação no navegador. Os usuários não veem a página de erro do navegador ao ficarem off-line. Em vez disso, as partes dinâmicas da página são renderizadas com erros, entram em estados indefinidos ou simplesmente deixam de ser dinâmicas.

Efeitos semelhantes podem acontecer em sites de várias páginas devido ao carregamento lento. Por exemplo, talvez o carregamento inicial tenha acontecido on-line, mas o usuário ficou off-line antes de rolar a tela. Todo o conteúdo de carregamento lento abaixo da dobra vai falhar silenciosamente e ficar ausente.

Como esses casos são muito irritantes para os usuários, faz sentido rastreá-los. Os service workers são o lugar perfeito para capturar erros de rede e, por fim, rastreá-los usando análises. Com o Workbox, um gerenciador de captura global pode ser configurado para informar à página sobre solicitações com falha enviando um evento de mensagem:

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();

  }());
});

Em vez de detectar todas as solicitações com falha, outra maneira é capturar erros apenas em rotas específicas. Por exemplo, se quisermos relatar erros que ocorrem apenas em rotas para /products/*, podemos adicionar uma verificação em setCatchHandler que filtra o URI com uma expressão regular.

Uma solução mais limpa é implementar registerRoute com um gerenciador personalizado. Isso encapsula a lógica de negócios em uma rota separada, com melhor capacidade de manutenção em service workers mais complexos:

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();
    }
  }
);

Como etapa final, a página precisa detectar o evento message e enviar o ping de análise. Novamente, armazene em buffer as solicitações de análise que ocorrem off-line no service worker. Conforme descrito anteriormente, inicialize o plug-in workbox-google-analytics para o suporte integrado do Google Analytics.

O exemplo a seguir usa o Google Analytics, mas pode ser aplicado da mesma forma para outros fornecedores de análise.

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
      });
    }
  });
}

Isso vai rastrear os carregamentos de recursos com falha no Google Analytics, onde eles podem ser analisados com relatórios. O insight derivado pode ser usado para melhorar o armazenamento em cache do service worker e o tratamento de erros em geral, tornando a página mais robusta e confiável em condições de rede instáveis.

Próximas etapas

Você aprendeu diferentes maneiras de rastrear o uso off-line, com as vantagens e desvantagens de cada uma. Embora isso possa ajudar a quantificar quantos usuários ficam off-line e têm problemas por causa disso, é apenas um começo. Se o site não oferecer um modo off-line bem construído, você obviamente não verá muito uso off-line no Google Analytics.

Recomendamos que você configure o rastreamento completo e, em seguida, amplie os recursos off-line em iterações, com foco no rastreamento. Comece com uma página de erro off-line. É simples criar isso com o Workbox, e é uma prática recomendada de UX semelhante às páginas 404 personalizadas. Em seguida, trabalhe para criar substitutos off-line mais avançados e, por fim, para criar conteúdo off-line real. Anuncie e explique isso bem aos usuários para aumentar o uso. Afinal, todo mundo fica off-line de vez em quando.

Confira Como informar métricas e criar uma cultura de desempenho e Corrigir a velocidade do site de forma multifuncional para receber dicas sobre como convencer as partes interessadas multifuncionais a investir mais no seu site. Embora essas postagens se concentrem no desempenho, elas devem ajudar você a ter ideias gerais sobre como envolver as partes interessadas.