Medir o uso off-line

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

Stephan Giesau

Martin Schierle

Neste artigo, mostramos como acompanhar o uso off-line do seu site para ajudar você a argumentar por que seu site precisa de um modo off-line melhor. Ele 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 rastrear o uso off-line é criar listeners de eventos para os eventos online e offline (compatíveis com muitos navegadores) e colocar a lógica de acompanhamento de análises nesses listeners. Infelizmente, há vários problemas e limitações nessa abordagem:

• Em geral, o rastreamento de todos os eventos de status de conexão de rede pode ser excessivo e contraprodutivo em um mundo centrado na privacidade em que é preciso coletar o mínimo de dados possível. Além disso, os eventos online e offline podem ser disparados por apenas uma fração de segundo de perda de rede, o que um usuário provavelmente nem perceberia.
• 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 do carimbo de data/hora localmente quando um usuário fica off-line e o envio da atividade off-line ao servidor de análise quando o usuário fica on-line novamente depende da visita do usuário ao site. Se o usuário sair do site devido à falta de um modo off-line e nunca acessar novamente, não será possível acompanhá-lo. 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 sabe sobre o acesso à rede, não sobre 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 está off-line, nenhum dos outros eventos de análise (por exemplo, eventos de rolagem, cliques etc.) também é acompanhado, que pode ser a informação mais relevante e útil.
• Estar off-line, por si só, 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 off-line do navegador (o 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 ter uma compreensão básica do 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 habilita o modo off-line acaba sendo a melhor solução 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 talvez os hits enviados por mais de quatro horas em adiamento não sejam 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 está off-line, mas você não saberia que eles aconteceram off-line, já que são apenas reproduzidos como estão. Para isso, você pode manipular solicitações de rastreamento com a caixa de trabalho adicionando uma flag offline ao ping da 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 de a conexão de Internet voltar? Mesmo que isso normalmente coloque o service worker em suspensão (porque ele não consegue enviar os dados quando a conexão é retornada), o módulo do Google Analytics do Workbox usa a API Background Sync, que envia os dados de análise mais tarde quando a conexão é restabelecida, mesmo que o usuário feche a guia ou o navegador.

Ainda há uma desvantagem: embora isso faça com que o acompanhamento existente funcione off-line, você provavelmente não verá muitos dados relevantes chegando até implementar um modo off-line básico. Os usuários ainda abandonam o site rapidamente quando a conexão é interrompida. Mas agora é possível pelo menos medir e quantificar isso comparando a duração média da sessão e o engajamento do usuário com a dimensão off-line aplicada em comparação com seus usuários comuns.

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 será exibida, 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 por AJAX sem precisar navegar 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 ocorrer 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 acompanhá-los. Os service workers são o local perfeito para detectar erros de rede e, em algum momento, 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 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 é 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 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 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 receber 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 rastreia 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, para tornar a página mais robusta e confiável em condições de rede instáveis.

Próximas etapas

Este artigo mostrou diferentes maneiras de rastrear o uso off-line com suas vantagens e desvantagens. Embora isso possa ajudar a quantificar quantos dos seus usuários ficam off-line e têm problemas por causa disso, ainda é apenas o começo. Contanto que seu site não ofereça um modo off-line bem criado, você não verá muito uso off-line nas análises.

Recomendamos implementar o rastreamento completo e, em seguida, estender seus recursos off-line em iterações, prestando atenção nos números de rastreamento. Comece com uma página de erro off-line simples com o Workbox simples. De qualquer forma, ela deve ser considerada uma prática recomendada de UX semelhante às páginas 404 personalizadas. Em seguida, vá para substitutos off-line mais avançados e, por fim, para conteúdo off-line real. Anuncie bem e explique isso aos usuários. Assim, você vai usar cada vez mais. Afinal, todo mundo fica off-line de vez em quando.

Confira Como gerar relatórios de métricas e criar uma cultura de desempenho e Como corrigir a velocidade do site de forma multifuncional para ver dicas sobre como convencer as partes interessadas multifuncionais a investir mais no seu site. Embora essas postagens sejam focadas no desempenho, elas devem ajudar você a ter ideias gerais sobre como engajar as partes interessadas.

Foto principal de JC Gellidon no Unsplash.