Como construir análises de descoberta conscientes da privacidade para uma loja de criadores


A análise pode ajudar os criadores a compreender como os visitantes descobrem o seu trabalho, mas a recolha de mais dados não produz automaticamente melhores decisões. Uma vitrine pequena geralmente precisa de respostas para um conjunto limitado de perguntas: quais canais atraem visitantes? Quais produtos chamam a atenção? Onde os potenciais compradores saem da jornada de compra?

Os desenvolvedores podem responder a essas perguntas sem criar sistemas de rastreamento invasivos ou armazenar históricos de navegação completos. A chave é definir um modelo de evento pequeno, coletar apenas as informações necessárias e agregar os resultados em métricas úteis.

Neste tutorial, construiremos a base de um sistema de análise de descoberta próprio usando JavaScript.

1. Decida o que você realmente precisa medir

Comece com questões comerciais em vez de dados disponíveis do navegador. Para uma loja de criadores, perguntas úteis podem incluir:

  • Quais páginas de destino atraem visitantes orgânicos?

  • Quais categorias de produtos geram mais visualizações?

  • Com que frequência uma visualização de produto leva a um evento de adição ao carrinho?

  • Quais fontes de descoberta produzem pedidos concluídos?

  • Os visitantes estão encontrando produtos por meio de pesquisas, coleções ou referências externas?

Essas perguntas geralmente podem ser respondidas com uma pequena coleção de eventos:

  • page_view

  • product_view

  • search

  • add_to_cart

  • checkout_started

  • purchase_completed

Evite coletar informações simplesmente porque elas estão disponíveis. Impressões digitais de dispositivos, URLs de referência completos, localizações precisas e identificadores pessoais desnecessários apresentam riscos de privacidade e segurança sem necessariamente melhorar sua análise.

A análise primária não torna automaticamente um aplicativo compatível com a privacidade. Os desenvolvedores ainda devem considerar o consentimento, as políticas de retenção, as solicitações de exclusão de usuários e as leis aplicáveis ​​aos seus usuários.

2. Crie um esquema de evento mínimo

Cada evento deve seguir a mesma estrutura previsível. Isso torna os eventos mais fáceis de validar no servidor e mais simples de consultar posteriormente.

function cleanValue(value, maximumLength = 80) {
  if (typeof value !== "string") {
    return null;
  }

  return value.trim().slice(0, maximumLength) || null;
}

function getReferrerOrigin() {
  if (!document.referrer) {
    return null;
  }

  try {
    return new URL(document.referrer).origin;
  } catch {
    return null;
  }
}

function createAnalyticsEvent(type, properties = {}) {
  const currentUrl = new URL(window.location.href);

  return {
    type: cleanValue(type, 40),
    path: currentUrl.pathname,
    referrerOrigin: getReferrerOrigin(),
    campaign: {
      source: cleanValue(currentUrl.searchParams.get("utm_source")),
      medium: cleanValue(currentUrl.searchParams.get("utm_medium")),
      name: cleanValue(currentUrl.searchParams.get("utm_campaign"))
    },
    properties,
    occurredAt: new Date().toISOString()
  };
}

A função registra o caminho atual, mas exclui a string de consulta completa. Isso ajuda a evitar que endereços de e-mail, termos de pesquisa, tokens de acesso ou outros valores confidenciais cheguem acidentalmente ao banco de dados analítico.

Também reduz o referenciador à sua origem. Em vez de armazenar uma página de referência completa, como:

Antes de aceitar propertiesdefina quais campos cada evento pode conter. UM product_view evento pode permitir um ID de produto e categoria, enquanto um search O evento pode registrar o número de resultados sem reter a frase de pesquisa completa do visitante.

3. Registre as fontes de descoberta com cuidado

Os dados de atribuição explicam como um visitante chegou ao aplicativo. Pode vir de parâmetros UTM, de um domínio de referência ou de uma visita direta.

Não trate a atribuição como evidência perfeita. Navegadores, ferramentas de privacidade, redirecionamentos e aplicativos podem remover informações de referência. Um referenciador ausente deve, portanto, ser representado como tráfego desconhecido ou direto, em vez de atribuído a um canal de marketing conveniente.

Se você precisar de uma implementação de atribuição mais completa, o guia do SitePoint para construindo um sistema de rastreamento de atribuição de campanha explica como capturar valores de campanha, retê-los por um período razoável e conectá-los a conversões sem inventar atribuição quando faltam informações.

A descoberta orgânica merece uma categoria própria. Os criadores podem ser encontrados por meio de pesquisa no mercado, tags de produtos, cobertura editorial, compartilhamento social ou visitas repetidas, em vez de publicidade paga. Esta discussão de vender impressões artísticas no Etsy e ser encontrado sem pagar por anúncios ilustra por que a análise de vitrine deve distinguir a descoberta orgânica do tráfego de campanha paga.

O artigo externo é útil como contexto do produto, mas sua implementação ainda deve contar com dados coletados de seu próprio aplicativo.

4. Envie eventos sem bloquear a navegação

As solicitações de análise não devem atrasar o visitante nem impedir a navegação. A API Beacon é útil para pequenas cargas de eventos, principalmente quando um visitante está saindo de uma página.

function sendAnalyticsEvent(event) {
  const payload = JSON.stringify(event);
  const endpoint = "/api/analytics/events";

  if ("sendBeacon" in navigator) {
    const body = new Blob((payload), {
      type: "application/json"
    });

    const queued = navigator.sendBeacon(endpoint, body);

    if (queued) {
      return Promise.resolve();
    }
  }

  return fetch(endpoint, {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: payload,
    credentials: "same-origin",
    keepalive: true
  }).then(response => {
    if (!response.ok) {
      throw new Error(`Analytics request failed: ${response.status}`);
    }
  });
}

O substituto usa fetch() com keepalivepermitindo que o navegador continue a solicitação quando a página estiver sendo descarregada. SitePoints introdução à API Fetch fornece informações adicionais sobre solicitações, respostas e tratamento de erros.

Lembre-se disso sendBeacon() retornando true significa apenas que o navegador aceitou os dados para entrega. Não confirma se o servidor processou ou armazenou o evento. A análise deve, portanto, ser tratada como dados aproximados e não como um registro transacional.

Registre ações comerciais importantes, como compras concluídas, no servidor, em vez de depender inteiramente de eventos do navegador.

5. Rastreie as interações do produto

Com as funções de evento compartilhado implementadas, registrar uma visualização do produto é simples:

const productView = createAnalyticsEvent("product_view", {
  productId: "print-1042",
  category: "abstract-art"
});

sendAnalyticsEvent(productView).catch(error => {
  console.debug("Analytics event was not delivered", error);
});

O ID do produto deve referir-se a um registro interno em vez de expor uma chave de banco de dados contendo informações do cliente. As categorias também devem vir de uma lista controlada para que as diferenças ortográficas não dividam uma categoria em vários grupos analíticos.

Para elementos interativos, use um atributo de dados:

<button
  type="button"
  data-analytics-event="add_to_cart"
  data-product-id="print-1042">
  Add to cart
button>

document.addEventListener("click", event => {
  const button = event.target.closest("(data-analytics-event)");

  if (!button) {
    return;
  }

  const analyticsEvent = createAnalyticsEvent(
    button.dataset.analyticsEvent,
    {
      productId: button.dataset.productId
    }
  );

  sendAnalyticsEvent(analyticsEvent).catch(() => {});
});

A delegação de eventos permite que o manipulador trabalhe dinamicamente para produtos adicionados à página. No entanto, o servidor ainda deve validar todos os valores porque os atributos HTML podem ser modificados pelos visitantes.

6. Valide eventos no servidor

Nunca insira análises geradas pelo navegador diretamente em um banco de dados. Validar:

  • O tipo de evento em relação a uma lista de permissões.

  • A forma e o tipo de dados de cada propriedade.

  • Comprimentos máximos de string e carga útil.

  • Identificadores de produto em relação aos formatos esperados.

  • Carimbos de data e hora para valores históricos ou futuros não razoáveis.

  • A taxa de solicitação para reduzir a inundação automatizada de eventos.

O servidor deve gerar seu próprio carimbo de data/hora de recebimento. O carimbo de data/hora do navegador ainda pode ser armazenado, mas não deve ser tratado como oficial.

Evite armazenar endereços IP brutos, a menos que haja uma necessidade operacional ou de segurança justificada. Se o processamento de IP de curto prazo for necessário para prevenção de abusos, mantenha-o separado das análises de longo prazo e documente o período de retenção.

7. Transforme eventos em métricas úteis

Uma grande tabela de eventos ainda não é um sistema analítico. O valor vem da agregação de eventos em métricas que respondem a perguntas específicas.

Por exemplo, a conversão de visualização de produto pode ser calculada como:

unique sessions that purchased a product
------------------------------------------
unique sessions that viewed the product

Outras medidas úteis incluem:

  • Taxa de pesquisa para visualização do produto.

  • Taxa de visualização do produto até o carrinho.

  • Taxa de conclusão de checkout.

  • Taxa de conversão por fonte de descoberta.

  • Categorias mais visualizadas com baixas vendas.

  • Landing pages que levam à exploração do produto.

Não otimize apenas para visualizações de página. Uma categoria que atrai menos visitantes pode produzir mais compras, enquanto um artigo popular pode trazer leitores que não estão comprando no momento.

Use tamanhos mínimos de amostra ao comparar canais ou produtos. Uma fonte com uma compra de dois visitantes não deve ser automaticamente considerada mais forte do que uma fonte com 100 compras de 1.000 visitantes.

8. Aplicar regras de retenção e minimização de dados

Os dados analíticos não devem ser armazenados indefinidamente por padrão. Os eventos brutos podem ser úteis para um curto período de depuração e análise, enquanto as estatísticas agregadas diárias ou mensais podem ser retidas por mais tempo.

Uma política prática poderia:

Mantenha os eventos brutos por 30 dias.

Remova ou alterne identificadores de sessão temporários.

Armazene métricas agregadas de canais e produtos.

Exclua eventos malformados e rejeitados rapidamente.

Forneça um processo para lidar com solicitações de exclusão aplicáveis.

Documente essas regras na base de código e nos procedimentos operacionais. A retenção deve ser imposta por trabalhos agendados de banco de dados, em vez de depender de alguém para se lembrar de remover registros antigos manualmente.

Considerações Finais

Um sistema útil de análise da loja do criador não precisa acompanhar cada movimento que um visitante faz. É necessário um modelo de evento consistente, atribuição cuidadosa, validação do lado do servidor e uma pequena lista de métricas vinculadas a decisões reais de produto.

Comece com visualizações de produtos, fontes de descoberta, ações no carrinho e compras concluídas. Armazene apenas as informações necessárias para avaliar esses eventos, agregue-as regularmente e remova os dados brutos quando eles não servirem mais a uma finalidade definida.

Essa abordagem produz análises mais fáceis de entender, mais seguras de operar e mais úteis do que uma grande coleção de dados de rastreamento inexplicáveis.



Source link