Dimensões e métricas personalizadas: o que merece aparecer no relatório

Com a especificação implementada, cada evento chega ao Analytics carregando parâmetros, os detalhes como segmento, planta ou valor. A propriedade recebe todos e mostra poucos: um parâmetro só vira coluna de relatório depois de registrado como dimensão ou métrica personalizada, e cada propriedade tem cota para isso.

Registrar sem critério cobra em duas semanas. As vagas se enchem de parâmetros que ninguém consulta, e uma dimensão com valores demais faz o relatório agrupar quase tudo na linha (other). A regra do capítulo é simples de dizer: registra-se o que responde a uma decisão recorrente e ainda não existe como campo nativo.

Antes de registrar, procure o campo que já existe

O Analytics já traz centenas de dimensões e métricas prontas, como página, número do pedido, dispositivo e cidade. A própria ajuda do Google recomenda usá-las sempre que possível e avisa que registrar um parâmetro que já tem campo nativo gasta cota sem ganho. A lista pública de campos da interface de programação serve de catálogo para essa conferência.

Evento ou pessoa: o escopo decide como o valor se comporta

Parâmetro de evento descreve o acontecimento: em qual página o WhatsApp foi clicado, qual segmento pediu o orçamento. Propriedade do usuário descreve a pessoa e acompanha os eventos seguintes dela: o plano do clube, o estágio no relacionamento B2B. Há ainda o escopo de item, para o que descreve um produto dentro da lista de itens de uma compra.

O escopo é a decisão que não se desfaz. Registrar segmento como propriedade do usuário quando ele vem em cada orçamento faz a pessoa carregar o valor mais recente nos eventos seguintes: quem pediu um orçamento residencial e depois um corporativo passa a aparecer como corporativa dali em diante, e o segmento deixa de descrever cada pedido. Por isso o segmento acompanha cada evento. A dimensão também só recebe dados a partir do registro: o parâmetro enviado há meses sem registro não volta aos relatórios.

Cardinalidade é o número de etiquetas da gaveta

Cardinalidade é a quantidade de valores diferentes que uma dimensão assume. Pense num arquivo com gavetas: segmento do orçamento tem três etiquetas e cabe numa gaveta organizada; o endereço completo da página, com os códigos que cada anúncio acrescenta, ganha uma etiqueta nova a cada clique. A ajuda do Google trata como alta cardinalidade a dimensão com mais de 500 valores, como orientação, e pede que propriedades padrão evitem criar dimensões assim sem necessidade.

A linha (other) é outro assunto, ligado ao tamanho das tabelas. Cada tabela que o Analytics usa para responder a um relatório tem um limite de linhas; quando a combinação de dimensões passa dele, os valores mais comuns aparecem e os demais são agrupados nessa linha. Uma dimensão de alta cardinalidade, combinada com outras, aumenta a chance de estourar o limite. Relatórios padrão com uma dimensão raramente são afetados; filtros, comparações e dimensões secundárias pedem tabelas maiores.

Métricas personalizadas e calculadas evitam a planilha

A métrica personalizada registra um parâmetro numérico para somar ou tirar média: o valor esperado do orçamento, a quantidade de plantas na assinatura. A métrica calculada é uma fórmula sobre métricas que já existem, como a margem estimada (receita de compra vezes 0,38) ou o custo por pedido de orçamento (custo de mídia dividido pelos pedidos). A propriedade padrão tem cinco vagas para fórmulas, e cada uma deve responder a uma pergunta que a diretoria faz todo mês.

O dicionário de dados junta tudo: para cada definição, o nome de exibição, o parâmetro de origem, o escopo, o tipo, os valores possíveis, um exemplo e o dono. Ele vive ao lado da especificação de eventos descrita em Taxonomia de eventos e dataLayer: o significado de cada evento e responde à pergunta que toda propriedade recebe um dia: o que é essa dimensão e quem a criou.

A Verde Vivo perdeu um relatório e refez a leitura em uma semana

Na primeira semana depois da especificação, Marina registrou 14 dimensões de evento, entre elas o endereço completo da página e o número do pedido de orçamento, que queria cruzar com o HubSpot direto no relatório. Em 18 dias, a análise de pedidos por segmento com o endereço como dimensão secundária agrupava 61% dos pedidos de orçamento na linha (other). O endereço com códigos de campanha era o culpado: ganhava valores novos a cada clique de anúncio.

A correção começou por um levantamento, e não por exclusão em massa. Para cada dimensão candidata a sair, Marina conferiu quais análises, públicos e painéis a usavam, avisou os donos e só então excluiu o endereço completo, a página registrada em duplicidade e o número do pedido. Depois das 48 horas de espera, registrou plano do clube e estágio B2B como propriedades do usuário, o valor do orçamento como métrica e duas métricas calculadas. O cruzamento com o HubSpot foi para uma consulta no BigQuery.

Em setembro, com a nova consulta limitada às semanas posteriores à correção, o relatório de pedidos de orçamento por segmento voltou a ter três linhas legíveis: 54 corporativos, 26 residenciais e 12 de condomínio, sem (other). As semanas anteriores continuam agrupadas, porque excluir uma definição não reprocessa o passado. O estágio B2B como propriedade do usuário permitiu montar um público de quem está em proposta há mais de 30 dias, contados a partir da data em que o CRM registrou a mudança para a etapa de proposta, e a margem estimada passou a aparecer ao lado da receita sem planilha. Os painéis nativos, disponíveis desde 9 de setembro de 2026, usam as mesmas definições: dimensão que não foi registrada também não vira cartão de painel.

O que pedir à equipe

Peça a lista de definições personalizadas com o uso de cada uma e as vagas livres. Para cada dimensão, pergunte quantos valores diferentes ela recebe e se existe campo nativo equivalente; as que não passam no teste entram num levantamento de uso antes de sair. Confira também se algum parâmetro carrega e-mail, telefone ou documento: esses dados não podem ir para o Analytics, registrados ou não.

Alguns detalhes descrevem a pessoa, e a pessoa nem sempre é reconhecível entre aparelhos e domínios. O capítulo User-ID e vários domínios: limites de identidade entre sites e aplicativos trata desses limites.