Como acompanhar o uso off-line do seu site para justificar por que ele precisa de uma experiência off-line melhor.
Este artigo mostra como acompanhar 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 on-line e off-line do navegador
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
eoffline
podem ser acionados por apenas uma fração de segundo de perda de rede, que um usuário provavelmente nem notaria. - O acompanhamento de análise da atividade off-line nunca chegaria ao servidor de análise porque o usuário está 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, talvez seja mais importante saber quais tipos de recursos não foram carregados. 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 acaba sendo a melhor para rastrear o uso off-line. A ideia básica é armazenar pings de análise na IndexedDB enquanto o usuário estiver off-line e reenviá-los quando ele voltar a ficar on-line. No Google Analytics, isso já está disponível pronto para uso com um módulo do Workbox, mas é importante lembrar 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 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 existentes enquanto está off-line, mas você não saberia que eles aconteceram off-line, já que são 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 tenha saído da Internet antes de rolar a tela. Todo o conteúdo carregado de forma lazy abaixo da dobra vai falhar silenciosamente e vai estar ausente.
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 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 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 acontecem off-line no service worker. Como
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, 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. Comece com uma página de erro simples e offline, com Workbox, que é fácil de fazer, e considere 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.