Dimensão Core/Dash: Labels Customizadas e Segmentação

Segmentação Customizada no CoreDash

Dimensões técnicas como país e tipo de dispositivo são construídas a partir de sinais do navegador. O CoreDash as coleta automaticamente. As três dimensões abordadas aqui são diferentes: Page Label, A/B Test e Logged In Status são definidas pelo usuário. Você as define atribuindo uma variável window no seu próprio código antes do CoreDash rodar.

Essa mudança do automático para o intencional é o grande ponto. Sua aplicação sabe de coisas que o navegador não consegue inferir: qual variante de checkout o usuário está vendo, se a URL atual é uma página de detalhes do produto ou uma landing page, se o usuário está autenticado. Passar esse contexto para o CoreDash significa que seus dados de performance refletem como o seu negócio realmente funciona.

Page Label (lb)

A dimensão Page Label permite agrupar páginas pela função de negócios em vez da estrutura da URL. Defina-a assim:

window.__CWVL = 'mypagelabel';

Valores típicos: checkout, product-detail, landing-page, category, search-results, account. O valor é uma string arbitrária que você controla.

Por que isso importa

A análise baseada em URL tem um problema fundamental de escala. Um grande e-commerce pode ter 50.000 páginas de detalhes de produtos. Suas URLs se parecem com /products/blue-widget-32oz e /products/red-gadget-xl. Elas usam o mesmo template, a mesma função de negócios, o mesmo alvo de otimização. Analisá-las uma URL por vez não é útil. Agrupá-las sob product-detail fornece um único perfil de performance para todo o catálogo de produtos.

O Page Label também separa páginas que atendem a diferentes orçamentos de performance. Uma página de checkout tem um limite aceitável de LCP porque carrega receita direta. Um post de blog tem uma tolerância diferente. Uma landing page rodando tráfego pago tem tolerância zero para um LCP lento porque cada milissegundo custa seu investimento em anúncios.

Quando você marca páginas por função de negócios, pode definir limites de alerta diferentes no CoreDash por label e rotear os alertas certos para os times certos.

Teste A/B (ab)

A dimensão Teste A/B guarda uma label que você atribui à variante atual que o usuário está experimentando. Defina-a assim:

window.__CWAB = 'minha versao da pagina';

O valor é arbitrário. variant-a e variant-b são escolhas óbvias, mas você pode usar qualquer string que mapeie para os identificadores de variante da sua plataforma de experimentação.

Por que isso importa

Testes A/B são uma das fontes mais comuns de regressões de performance não intencionais. A variante B entrega um novo carrossel de imagens no hero. A variante B carrega um widget de recomendação de terceiros. A variante B inclui uma rodada extra de hidratação do React. Tudo isso carrega um custo de performance que as suas ferramentas de experimentação quase certamente não medem.

A maioria das plataformas de experimentação rastreia taxas de conversão e receita. Elas não rastreiam o p75 do LCP ou do INP. Se a variante B converte 2% melhor, mas carrega 400ms mais lenta no mobile, você precisa saber disso antes de distribuí-la para 100% do tráfego. O custo de performance pode apagar o ganho de conversão ao longo do próximo trimestre, à medida que os usuários perdem a paciência.

Com __CWAB definido, abra o CoreDash, filtre por ab = variant-b e compare os Core Web Vitals lado a lado com o controle. Já vi testes A/B em que a variante vencedora tinha um p75 de LCP 600ms pior que o controle porque carregava uma fonte mais pesada. O time de negócios viu o aumento na conversão; eles não viram a regressão de performance. É isso que essa dimensão previne.

Estado de Login (li)

A dimensão Estado de Login registra se o usuário atual está autenticado. Defina-a assim:

window.__CWVLI = 1; // logado
window.__CWVLI = 0; // deslogado

Por que isso importa

Usuários logados recebem uma página fundamentalmente diferente da de visitantes anônimos. Suas requisições ignoram muitas camadas de cache da CDN. O servidor roda consultas no banco de dados para conteúdo personalizado: o carrinho do usuário, seu histórico de pedidos, seus itens salvos. Esse trabalho no servidor soma diretamente ao TTFB.

No frontend, páginas autenticadas geralmente carregam mais JavaScript: widgets de conta, sistemas de notificação, reatividade do carrinho de compras. Elas também podem pular o pré-render ou o edge caching que torna as páginas anônimas rápidas. O resultado é que usuários logados frequentemente veem uma performance mais lenta do que usuários anônimos, mas usuários logados são tipicamente os seus clientes de maior valor. Eles já converteram. Eles são os que você mais precisa reter.

Sem a dimensão li, uma performance autenticada lenta se esconde dentro dos seus números agregados. Seu LCP anônimo pode ser 1,8s, enquanto seu LCP logado é 3,4s. O agregado aparece como 2,3s e parece aceitável. Divida por li e a figura muda completamente.

Implementação

Todas as três dimensões usam o mesmo padrão: defina uma variável window antes que o snippet do CoreDash execute. Coloque-as em uma tag script no head do seu documento ou no código de inicialização da sua aplicação:

// Defina as três com base no estado da sua aplicação
window.__CWVL  = 'checkout';      // label da página
window.__CWAB  = 'variant-b';     // variante do teste A/B
window.__CWVLI = 1;               // logado

Os valores de label são strings (exceto __CWVLI, que aceita 1 ou 0). Mantenha-os consistentes em toda a sua base de código. Se você usa product-detail em um template e productDetail em outro, o CoreDash os trata como dois segmentos separados e seus dados se fragmentam. Escolha uma convenção e force o seu uso.

Combinando as três

O verdadeiro valor aparece quando você empilha essas dimensões juntas. Você está rodando um teste A/B na sua página de checkout para usuários logados. Você quer saber se a variante B torna a experiência de checkout autenticada mais rápida ou mais lenta.

No CoreDash, filtre por ab = variant-b mais lb = checkout mais li = 1. Isso te dá a performance da sua variante de checkout especificamente para usuários autenticados. Nenhuma outra ferramenta de monitoramento exibe essa combinação sem trabalho de engenharia customizado da sua parte.

As dimensões técnicas padrão dizem a você o que o navegador experimentou. As dimensões customizadas dizem o que o negócio experimentou. Uma regressão de 400ms no LCP significa algo muito diferente em uma landing-page rodando tráfego pago versus um post de blog. Essas distinções importam para a priorização, e a priorização é onde o trabalho de performance tem sucesso ou empaca.