Registrar dimensões personalizadas sem estourar a cardinalidade

Com o contrato de eventos implementado, cada evento chega ao GA4 carregando parâmetros. A propriedade recebe todos e mostra quase nenhum: um parâmetro só aparece em relatório e em exploração depois de registrado como dimensão ou métrica personalizada, e a propriedade padrão tem 50 vagas de escopo de evento para isso.

O custo de registrar sem critério aparece em duas semanas. Vagas ocupadas por parâmetros que ninguém consulta, e uma dimensão com identificador único por linha que faz o relatório inteiro desabar na linha (other), a linha em que o GA4 agrupa tudo o que não coube na tabela. Depois disso, a resposta para "qual segmento pediu mais orçamentos" vira "(other): 61 por cento".

Registrar bem é uma sequência de decisões: o que é parâmetro de evento e o que é propriedade do usuário, qual escopo cada um recebe, quais viram métrica, e o que nunca deve ser registrado. A Verde Vivo fechou aqui um dicionário de dados de 16 definições, depois de perder um relatório inteiro para a cardinalidade.

Parâmetro de evento e propriedade do usuário respondem a perguntas diferentes. O parâmetro descreve o acontecimento: em qual página o WhatsApp foi clicado, qual segmento pediu o orçamento, qual planta foi consultada. A propriedade do usuário (user property, o atributo que fica gravado na pessoa e acompanha todos os eventos seguintes) descreve quem: o plano do clube, o estágio do relacionamento, se é cliente B2B. Cada evento aceita até 25 parâmetros na propriedade padrão, e cada propriedade tem até 25 propriedades de usuário.

A definição personalizada (custom definition, o registro que liga um nome de parâmetro a uma dimensão ou métrica visível) é feita no Admin, e o escopo é a decisão irreversível dela. Escopo de evento para parâmetros que mudam a cada evento; escopo de usuário para as propriedades da pessoa; escopo de item para o que descreve produto dentro do array items. Registrar segmento como escopo de usuário quando ele vem em cada orçamento faz o valor mais recente sobrescrever o anterior.

Disponibilidade e processamento entram no planejamento. A dimensão registrada só recebe dados a partir do registro, e o histórico anterior não é reprocessado; o parâmetro que estava sendo enviado há meses sem registro não volta. Quando uma definição é excluída para abrir vaga, a tabela oficial de limites diz que é preciso esperar 48 horas para criar outra no lugar, o que transforma uma limpeza apressada em dois dias sem a dimensão.

A métrica personalizada registra um parâmetro numérico para somar, tirar média ou dividir: o valor esperado do orçamento, a quantidade de plantas na assinatura. A métrica calculada (a fórmula que combina métricas existentes, com 5 vagas na propriedade padrão) evita a planilha para o que é conta simples: margem estimada como receita de compra vezes 0,38, ou custo por orçamento como custo de mídia dividido por generate_lead.

A cardinalidade é o número de valores diferentes que uma dimensão assume. A página oficial define alta cardinalidade como mais de 500 valores únicos por dia, e quanto mais alta, maior a chance de a tabela do relatório estourar o limite de linhas e mandar o excedente para a linha (other). A propriedade padrão tem limite de linhas menor que a 360, e pode exibir o aviso de (other) sem a linha aparecer, quando um filtro esconde o agrupamento. O BigQuery não tem (other), porque entrega o evento bruto.

O dicionário de dados é o documento que 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 do contrato de eventos do capítulo 7 e é a resposta para a pergunta que toda propriedade recebe um dia: "o que é essa dimensão e quem a criou?". Sem ele, vaga nenhuma é liberada porque ninguém sabe o que vai quebrar.

Armadilha comum: registrar o identificador do pedido ou do lead como dimensão de evento "para conferir com o CRM". Em um mês a dimensão passa de 500 valores por dia, o relatório que a usa vira uma linha (other) gigante, e o aviso de alta cardinalidade se espalha para os relatórios que combinam essa dimensão com outras. A conferência com o CRM se faz no BigQuery, onde o identificador vive sem limite.

A Verde Vivo caiu nessa. Marina registrou 14 dimensões de evento na primeira semana depois do contrato, incluindo lead_id, porque queria cruzar orçamentos com o HubSpot direto no relatório. Em 18 dias, o relatório de eventos por segmento mostrava (other) em 61 por cento das linhas, e a pergunta "qual segmento pediu mais orçamentos" ficou sem resposta na interface.

A correção levou uma semana por causa da espera. Marina excluiu lead_id e pagina (redundante com a dimensão nativa de página), aguardou as 48 horas e registrou no lugar plano_clube e estagio_b2b como propriedades de usuário, além de valor_orcamento como métrica personalizada. Criou uma métrica calculada de margem estimada (receita de compra vezes 0,38) e outra de custo por orçamento. O cruzamento com o HubSpot foi para uma consulta no BigQuery, onde lead_id não tem limite.

Em setembro, o relatório de generate_lead por segmento voltou a ter três linhas legíveis: 54 orçamentos corporativos, 26 residenciais e 12 de condomínio, sem (other). O estágio B2B como propriedade de usuário permitiu montar, no capítulo 18, um público de quem está em proposta há mais de 30 dias. E a margem estimada passou a aparecer ao lado da receita em todo relatório de e-commerce, sem planilha.

Abra hoje a lista de definições personalizadas da sua propriedade e conte as vagas de escopo de evento usadas. Para cada dimensão, pergunte quantos valores únicos ela recebe por dia; qualquer uma acima de 500, ou com identificador único, sai da lista nesta semana. Antes de o próximo capítulo ligar tudo isso ao consentimento, confira se algum parâmetro carrega e-mail, telefone ou documento: esses não podem estar no dataLayer, registrados ou não.