Como acompanhar o uso off-line do seu site para que você possa argumentar por que ele precisa de uma melhor experiência off-line.
Este artigo mostra como acompanhar o uso off-line do seu site para ajudar você a argumentar por que ele precisa de um modo off-line melhor. Ele também explica armadilhas e problemas que devem ser evitados 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
(compatíveis com
muitos navegadores) e colocar sua lógica de rastreamento
de análise nesses listeners. Infelizmente, essa abordagem tem vários problemas e limitações:
- 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
eoffline
podem ser acionados por apenas um segundo de perda de rede, que um usuário provavelmente não veria nem perceberia. - O rastreamento analítico de atividade off-line nunca chegaria ao servidor de análise porque o usuário está... off-line.
- Rastrear um carimbo de data/hora localmente quando um usuário fica off-line e enviar a 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 por falta de modo off-line e nunca mais acessa, você não tem como acompanhar isso. A capacidade de rastrear desistências é 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ó conhece o acesso à rede, não o acesso à Internet. Portanto, o usuário ainda pode estar off-line, e o envio do ping de rastreamento pode falhar. - Mesmo que o usuário ainda permaneça na página atual enquanto estiver off-line, nenhum dos outros eventos de análise (por exemplo, eventos de rolagem, cliques etc.) também será rastreado, o 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 não foram carregados. Isso é especialmente relevante no contexto de SPAs, em que uma queda de conexão de rede pode não levar a uma página de erro off-line do navegador (que os usuários entendem), mas mais propensas a falhas silenciosas em partes dinâmicas aleatórias da página.
Você ainda pode usar essa solução para ter um entendimento básico 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 ativa o modo off-line é a melhor solução para rastrear o uso off-line. A ideia básica é armazenar pings de análise no IndexedDB enquanto o usuário estiver off-line e reenviá-los quando ficar on-line novamente. Para o Google Analytics, isso já está disponível com o uso de um módulo do Workbox. No entanto, os hits enviados com mais de quatro horas adiados não serão 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 existentes enquanto você está off-line, mas não sabe que eles aconteceram off-line, já que são apenas repetidos no estado em que se encontram. Para isso, você pode manipular solicitações de rastreamento com o Workbox
adicionando uma sinalização 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 de a conexão de Internet voltar? Embora isso normalmente coloque o service worker em suspensão (por não ser capaz de enviar os dados quando a conexão volta), o módulo do Google Analytics da Workbox usa a API Background Sync, que envia os dados de análise mais tarde quando a conexão volta a ser feita, mesmo que o usuário feche a guia ou o navegador.
Ainda há uma desvantagem: embora isso permita o rastreamento off-line, você provavelmente não verá muitos dados relevantes até implementar um modo off-line básico. Os usuários ainda abandonariam seu site rapidamente quando a conexão falhar. 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 relação aos usuários normais.
SPAs e carregamento lento
Se os usuários que acessam uma página criada como um site com várias páginas ficarem off-line e tentarem navegar, a página off-line padrão do navegador será mostrada, ajudando os usuários a entender o que está acontecendo. No entanto, 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 a 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 apenas 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 ficado off-line antes de rolar a tela. Todo o conteúdo com carregamento lento abaixo da dobra vai falhar e ficar ausente.
Como esses casos são realmente irritantes para os usuários, faz sentido monitorá-los. Os service workers são o local perfeito para detectar erros de rede e, finalmente, 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 somente 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.
Mais uma vez, certifique-se de armazenar em buffer solicitações de análise que acontecem off-line no service worker. Conforme descrito anteriormente, inicialize o plug-in workbox-google-analytics
para ter suporte integrado do Google Analytics.
O exemplo a seguir usa o Google Analytics, mas pode ser aplicado da mesma maneira 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 as cargas de recursos com falha no Google Analytics, onde elas podem ser analisadas com a geração de 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 acompanhar o uso off-line com suas vantagens e desvantagens. Embora isso possa ajudar a quantificar quantos usuários ficam off-line e enfrentam problemas por causa disso, isso ainda é apenas o começo. Desde que seu site não ofereça um modo off-line bem criado, obviamente, você não verá muito uso off-line na análise.
Recomendamos implementar o rastreamento completo e, em seguida, ampliar seus recursos off-line em iterações de olho nos números de rastreamento. Comece com uma página de erro off-line simples, com o Workbox, que é simples de fazer. Além disso, deve ser considerada uma prática recomendada de UX semelhante às páginas 404 personalizadas. Em seguida, trabalhe em busca de substitutos off-line mais avançados e, por fim, do conteúdo off-line real. Anuncie e explique isso bem aos usuários para perceber um uso cada vez maior. Afinal, todo mundo fica off-line de vez em quando.
Confira Como relatar métricas e criar uma cultura de performance e Como corrigir a velocidade do site multifuncional para dicas sobre como persuadir 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 engajar as partes interessadas.
Foto principal de JC Gellidon no Unsplash.