Medir o uso off-line

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

Stephan Giesau

Martin Schierle

Este artigo mostra como rastrear o uso off-line do seu site para ajudar você a justificar por que seu site precisa de um modo off-line melhor. Ela também explica armadilhas e problemas a serem evitados ao implementar a Análise de uso off-line.

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

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

• Em geral, o rastreamento de todos os eventos de status de conexão de rede pode ser excessivo e contraproducente em um mundo centrado na privacidade, em que o objetivo é coletar o menor número possível de dados. Além disso, os eventos online e offline podem ser acionados por apenas uma fração de segundo de perda de rede, que um usuário provavelmente nem notaria.
• O rastreamento analítico da atividade off-line nunca chega ao servidor de análise porque o usuário está... bem, off-line.
• O rastreamento de um carimbo de data/hora local quando um usuário fica off-line e o envio da atividade off-line para o servidor de análise quando o usuário volta on-line depende de ele visitar seu site novamente. Se o usuário sair do seu site devido à falta de um modo off-line e nunca retornar, você não terá como acompanhar isso. A capacidade de acompanhar as desistências off-line é um dado essencial para criar um caso de uso sobre por que seu site precisa de um modo off-line melhor.
• O evento online não é muito confiável, porque só conhece 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 continue 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 em si também não é muito significativo em geral. Como desenvolvedor de sites, pode ser mais importante saber que tipos de recursos falharam ao carregar. Isso é especialmente relevante no contexto de SPAs, em que uma conexão de rede perdida pode não levar a uma página de erro do navegador off-line (que os usuários entendem), mas é mais provável que partes dinâmicas aleatórias da página falhem silenciosamente.

Você ainda pode usar essa solução para entender o uso off-line, mas é preciso considerar cuidadosamente as muitas desvantagens e limitações.

Uma abordagem melhor: o service worker

A solução que ativa o modo off-line é a melhor para rastrear o uso off-line. A ideia básica é armazenar pings de análise no IndexedDB, desde que o usuário esteja off-line, e reenviá-los quando o usuário ficar on-line novamente. Para o Google Analytics, isso já está disponível por meio de um módulo de caixa de trabalho, mas lembre-se de que os hits enviados por mais de quatro horas em adiamento talvez não sejam processados. Na forma mais simples, ele pode ser ativado em um worker de serviço 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 está off-line, mas você não saberia que eles acontecem off-line, já que são apenas reproduzidos como estão. Para isso, você pode manipular solicitações de rastreamento com o Workbox adicionando uma flag offline ao ping de análise usando uma dimensão personalizada (cd1 no exemplo de código abaixo):

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

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

E se o usuário sair da página por estar off-line, antes que a conexão de Internet seja reestabelecida? Embora isso normalmente coloque o worker do serviço em suspensão (porque ele não consegue enviar os dados quando a conexão volta), o módulo do Google Analytics do Workbox usa a API de sincronização em segundo plano, que envia os dados de análise mais tarde, quando a conexão volta, mesmo que o usuário feche a guia ou o navegador.

Ainda há uma desvantagem: embora isso torne o rastreamento atual compatível com o modo off-line, provavelmente você não vai receber muitos dados relevantes até implementar um modo básico off-line. Os usuários ainda sairiam do seu 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 dos usuários com a dimensão off-line aplicada em comparação com os usuários regulares.

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 quando ficam 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 com 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 falhará silenciosamente e vai desaparecer.

Como esses casos são muito irritantes para os usuários, faz sentido rastreá-los. Os service workers são o local perfeito para detectar erros de rede e, eventualmente, rastreá-los usando análises. Com o Workbox, um gerenciador de captura global pode ser configurado para informar a página sobre solicitações com falhas 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 é detectar erros apenas em rotas específicas. Por exemplo, se quisermos informar erros que acontecem em rotas apenas 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 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 da análise. Novamente, certifique-se de armazenar em buffer as solicitações de análise que acontecem off-line no service worker. Conforme descrito anteriormente, inicialize o plug-in workbox-google-analytics para 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 cache do service worker e o processamento de erros em geral, tornando a página mais robusta e confiável em condições de rede instáveis.

Próximas etapas

Neste artigo, mostramos diferentes maneiras de acompanhar 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 enfrentam problemas por isso, isso ainda é apenas o começo. Enquanto o site não oferecer um modo off-line bem desenvolvido, você não vai notar muito uso off-line no Analytics.

Recomendamos que você configure o acompanhamento completo e, em seguida, amplie seus recursos off-line em iterações, observando os números de acompanhamento. Primeiro, comece com uma página de erro off-line simples (com o Workbox é simples fazer) e precisa ser considerada uma prática recomendada de UX semelhante às páginas 404 personalizadas. Depois, avance para alternativas off-line mais avançadas e, por fim, para conteúdo off-line real. Anuncie e explique isso bem aos seus usuários, e você vai notar um aumento no uso. Afinal, todo mundo fica off-line de vez em quando.

Confira Como gerar relatórios de métricas e criar uma cultura de performance e Como corrigir a velocidade do site de forma interfuncional para receber dicas sobre como convencer as partes interessadas interfuncionais a investir mais no seu site. Embora essas postagens se concentrem na performance, elas podem ajudar você a ter ideias gerais sobre como envolver as partes interessadas.

Foto principal de JC Gellidon no Unsplash.