Core/Dash Dimension: Rótulos Personalizados e Segmentação
Meça a performance onde realmente importa: por variante A/B, tipo de página de negócio e estado de login, não apenas por URL.
Trusted by market leaders · Client results
Segmentação Personalizada 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 de janela no seu próprio código antes da execução do CoreDash.
Essa mudança do automático para o intencional é o ponto principal. Sua aplicação sabe coisas que o navegador não consegue inferir: qual variante de checkout um 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 seu negócio realmente funciona.
Page Label (lb)
A dimensão Page Label permite agrupar páginas por função de negócio em vez de estrutura de 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 é importante
A análise baseada em URL tem um problema fundamental de escala. Um grande site de 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 são o mesmo template, a mesma função de negócio, o mesmo alvo de otimização. Analisá-las uma URL de cada 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 servem diferentes orçamentos de performance (performance budgets). Uma página de checkout tem um limite de LCP aceitável porque gera receita direta. Um post de blog tem uma tolerância diferente. Uma landing page com tráfego pago tem tolerância zero para um LCP lento, porque cada milissegundo custa dinheiro em anúncios.
Depois de rotular as páginas por função de negócio, você pode definir diferentes limites de alerta no CoreDash por rótulo e rotear os alertas certos para as equipes certas.
A/B Test (ab)
A dimensão A/B Test contém um rótulo que você atribui à variante atual que o usuário está experimentando. Defina-a assim:
window.__CWAB = 'my page version';
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 é importante
Os testes A/B são uma das fontes mais comuns de regressões de performance não intencionais. A Variante B traz um novo carrossel de imagens 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 sua ferramenta de experimentação quase certamente não mede.
A maioria das plataformas de experimentação rastreia taxas de conversão e receita. Elas não rastreiam o p75 de LCP ou INP. Se a variante B converte 2% melhor, mas carrega 400ms mais devagar no mobile, você precisa saber disso antes de lançá-la para 100% do tráfego. O custo de performance pode apagar o ganho de conversão no próximo trimestre, à medida que os usuários perdem a paciência.
Com o __CWAB definido, abra o CoreDash, filtre por ab = variant-b e compare o 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 do que o controle porque carregava uma fonte mais pesada. A equipe de negócios viu o aumento na conversão; eles não viram a regressão de performance. É isso que esta dimensão evita.
Logged In Status (li)
A dimensão Logged In Status registra se o usuário atual está autenticado. Defina-a assim:
window.__CWVLI = 1; // autenticado window.__CWVLI = 0; // não autenticado
Por que isso é importante
Usuários autenticados recebem uma página fundamentalmente diferente dos visitantes anônimos. Suas requisições ignoram muitas camadas de cache de CDN. O servidor executa 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 lado do servidor adiciona diretamente ao TTFB.
No frontend, páginas autenticadas frequentemente carregam mais JavaScript: widgets de conta, sistemas de notificação, reatividade do carrinho de compras. Elas também podem pular o pré-processamento ou o cache de borda (edge caching) que torna as páginas anônimas rápidas. O resultado é que os usuários autenticados muitas vezes veem uma performance mais lenta do que os usuários anônimos, mas os usuários autenticados são tipicamente seus clientes de maior valor. Eles já converteram. Eles são os que você mais precisa reter.
Sem a dimensão li, a performance lenta de usuários autenticados se esconde dentro de seus números agregados. Seu LCP anônimo pode ser 1.8s, enquanto seu LCP autenticado é 3.4s. O agregado aparece como 2.3s e parece aceitável. Ao dividir por li, a imagem muda completamente.
Implementação
Todas as três dimensões usam o mesmo padrão: definir uma variável de janela antes da execução do snippet do CoreDash. Coloque-as em uma tag de script no cabeçalho do documento ou no código de inicialização da sua aplicação:
// Defina os três com base no estado do seu app window.__CWVL = 'checkout'; // rótulo da página window.__CWAB = 'variant-b'; // variante de teste A/B window.__CWVLI = 1; // autenticado
Os valores de rótulo são strings (exceto __CWVLI, que recebe 1 ou 0). Mantenha-os consistentes em toda a sua base de código. Se você usar product-detail in um template e productDetail em outro, o CoreDash os tratará como dois segmentos separados e seus dados ficarão fragmentados. Escolha uma convenção e siga-a.
Combinando os três
O real valor aparece quando você empilha essas dimensões. Você está executando um teste A/B na sua página de checkout para usuários autenticados. Você quer saber se a variante B torna a experiência de checkout autenticado mais rápida ou mais lenta.
No CoreDash, filtre por ab = variant-b mais lb = checkout mais li = 1. Isso fornece a performance da sua variante de checkout especificamente para usuários autenticados. Nenhuma outra ferramenta de monitoramento oferece essa combinação sem um trabalho de engenharia personalizado do seu lado.
Dimensões técnicas padrão dizem o que o navegador experimentou. Dimensões personalizadas dizem o que o negócio experimentou. Uma regressão de 400ms no LCP significa algo muito diferente em uma landing-page com tráfego pago em comparação com um post de blog. Essas distinções são importantes para a priorização, e a priorização é onde o trabalho de performance prospera ou trava.