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

Este artigo mostra como acompanhar o uso off-line do seu site para ajudar você a argumentar por que o site precisa de um modo off-line melhor. Ele também explica armadilhas e problemas a evitar ao implementar análise de dados 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 eventos para os online e offline (qual suporte para vários navegadores) e colocar o acompanhamento do Google Analytics lógica nesses listeners. Infelizmente, há vários problemas e limitações nesse caso, abordagem:

• Em geral, o rastreamento de cada evento de status de conexão de rede pode ser excessivo e contraprodutivo em um mundo centrado na privacidade, em que o mínimo de dados possível coletados. Além disso, os eventos online e offline podem ser disparados por apenas uma fração de segundo do a perda de rede, que um usuário provavelmente não veria ou perceberia.
• O rastreamento analítico da atividade off-line nunca chegava ao servidor de análise porque o usuário está... off-line.
• Rastrear localmente um carimbo de data/hora quando um usuário fica off-line e enviar a atividade off-line para quando o usuário fica on-line novamente, isso depende da visita do usuário ao site. Se o usuário sair do site devido à falta do modo off-line e nunca acessar novamente, você tem não há como rastrear isso. A capacidade de acompanhar as desistências off-line é um dado fundamental para a criação sobre por que seu site precisa de um modo off-line melhor.
• O evento online não é muito confiável porque só sabe sobre acesso à rede, e não acesso à Internet. Portanto, é possível que um usuário ainda esteja off-line, e o envio do ping de rastreamento pode ainda não funcionam.
• Mesmo que o usuário permaneça na página atual enquanto está off-line, do Google Analytics (por exemplo, eventos de rolagem, cliques etc.) são acompanhados, o que pode ser relevantes e úteis.
• Estar off-line, por si só, também não é muito significativo em geral. Como desenvolvedor de sites, pode seria mais importante saber que tipos de recursos falharam ao carregar. Isso é especialmente relevante, no contexto de SPAs, nos quais uma conexão de rede perdida pode não levar a um navegador off-line página de erro (que os usuários entendem), mas é mais provável que partes dinâmicas aleatórias da página falhem em silêncio.

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

Uma abordagem melhor: o service worker

A solução que ativa o modo off-line acaba sendo a melhor solução para acompanhamento off-line uso. A ideia básica é armazenar pings de análise no IndexedDB, desde que o usuário esteja off-line, e apenas reenviá-las quando o usuário estiver online novamente. Para o Google Analytics, isso já está disponível disponibilizado com um módulo "Caixa de trabalho", mas tenha em mente que os hits enviaram mais de quatro horas adiadas podem não ser processados. Na forma mais simples, ele pode ser ativado em um serviço baseado no Workbox worker com estas duas linhas:

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

googleAnalytics.initialize();

Isso acompanha todos os eventos e pings de visualização de página existentes enquanto está off-line, mas você não saberia que elas aconteceram off-line (já que são reproduzidas no estado em que se encontram). Para isso É possível manipular solicitações de rastreamento com o Workbox adicionando uma flag offline ao ping da análise, usando uma dimensão personalizada (cd1 no código exemplo 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 ter uma conexão de Internet de volta? Mesmo que isso normalmente coloque o service worker em espera (porque ele não pode enviar os dados quando a conexão for restabelecida), o módulo do Google Analytics na caixa de trabalho usará o recurso Sincronização em segundo plano API, que envia os dados de análise mais tarde, quando a conexão for 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 vão receber muitos dados relevantes até implementar um modo off-line básico. Os usuários ainda saem do site rapidamente quando a conexão é interrompida. Mas agora você pode pelo menos medir quantificar isso, comparando a duração média da sessão e o engajamento do usuário para usuários com a 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 com várias páginas ficarem off-line e tentarem navegar, o navegador página off-line padrão aparece, ajudando os usuários a entender o que está acontecendo. No entanto, as páginas criadas como os aplicativos de página única funcionam de forma diferente. O usuário permanece na mesma página e novos conteúdos são carregados dinamicamente por AJAX sem qualquer navegação no navegador. Os usuários não veem o erro do navegador quando estiver off-line. Em vez disso, as partes dinâmicas da página são renderizadas com erros. indefinidos ou apenas deixam de ser dinâmicos.

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

Como esses casos são muito irritantes para os usuários, faz sentido acompanhá-los. Os service workers são 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 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 em rotas específicas. . Por exemplo, se quisermos informar erros ocorridos em trajetos apenas para /products/*, podemos adicione 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 o 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 o Google Analytics integrado suporte.

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

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 acompanhar os carregamentos de recursos com falha no Google Analytics, onde eles podem ser analisados com geração de relatórios. O insight derivado pode ser usada 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 redes 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 usuários ficam off-line e têm problemas por causa disso, isso ainda é apenas o começo. Contanto que seu site não ofereça um modo off-line bem desenvolvido, e, obviamente, não verá muito uso off-line no Analytics.

Recomendamos que você implemente o acompanhamento completo e amplie seus recursos off-line em iterações, com foco nos números de rastreamento. Comece com uma página de erro off-line simples Com a caixa de trabalho, é fácil fazem e deve ser considerada uma prática recomendada de UX semelhante às páginas 404 personalizadas. Depois trabalhe do seu jeito para substitutos off-line mais avançados e, por fim, conteúdo off-line real. Anuncie e explique isso aos usuários. e você verá um uso cada vez maior. 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 multifuncional para ver dicas em convencer as partes interessadas multifuncionais a investir mais no seu site. Embora essas postagens estão focados no desempenho, eles devem ajudar você a ter ideias gerais sobre como interagir com as partes interessadas.

Foto principal de JC Gellidon no Unsplash.