Custom dimensions e metrics no GA4: decisões que evitam arrependimento
Custom dimensions e custom metrics no GA4 são finitos, caros em cardinalidade e permanentes na prática — registrar “só para testar” enche (other), esgota slots e amarra taxonomia errada por anos. Decisões de escopo (event, user, item), naming, registro e mapeamento dataLayer→GA4 precisam acontecer antes do deploy, não depois que o dashboard já pediu “mais um campo”. Planejamento evita arrependimento e retrabalho em GTM, BQ e BI.
Quantos slots existem e por que isso importa?
GA4 limita custom dimensions e metrics por property (varia free vs 360). Há cotas de event-scoped, user-scoped e item-scoped. Uma vez registrada, mudar escopo ou reutilizar nome com semântica diferente confunde histórico. Trate registro como change control, não clique impulsivo.
Priorize slots para dimensões que cruzam com receita, segmentação operacional e integrações ads. Campos “nice to have” vão para parâmetros de evento não registrados (visíveis em BQ) ou para warehouse — não ocupam slot precioso na UI.
Event, user ou item scope: como escolher?
Event scope: atributo da ocorrência (tipo de plano no clique, categoria de erro, experiment_id na sessão). User scope: atributo persistente do usuário (customer_tier, account_type, first_campaign) — set_user_properties ou parâmetro user-scoped. Item scope: atributo de produto no ecommerce (collection, margin_band).
Erro clássico: colocar tudo em event quando marketing precisa segmentar usuários, ou user scope para dado que muda a cada hit (preço dinâmico). Escopo errado quebra explorações e export BQ.
- Event: comportamento pontual e parâmetros de hit
- User: segmentação e cohort de perfil estável
- Item: merchandising e performance por SKU/atributo
- Não registrar PII em custom dimension
- Documentar escopo no glossário antes do registro
Cardinalidade: o assassino silencioso de relatórios?
Dimensão com milhares de valores únicos (URL completa, order_id, session_id, e-mail hash mal pensado) gera (other), estoura limites e torna UI inutilizável. Antes de registrar, pergunte: quantos valores distintos por mês? precisa na UI ou só no BQ?
Técnicas: bucketização (price_band), normalização (lowercase, trim), agrupamento (landing_page_group), hash truncado só se necessário. IDs de transação são para dedup e BQ — não para breakdown diário em GA4 UI.
| Dimensão candidata | Cardinalidade | Registrar? | Alternativa |
|---|---|---|---|
| campaign_group (<50 valores) | Baixa | Sim | UI + ads |
| full URL | Altíssima | Não | page_group custom ou BQ |
| transaction_id | Altíssima | Não como dim UI | Parâmetro evento + BQ |
| customer_tier | Baixa | Sim (user scope) | Audiences |
| product_sku (catálogo grande) | Alta | Item scope selecionado | Top N no BQ |
Custom metrics: contagem, moeda e cálculo?
Custom metrics podem ser standard (sum, count) vinculadas a parâmetro numérico. Registre métricas que a UI precisa somar (margin_value, lifetime_points) — não recrie receita se purchase value já existe. Duplicata de metric gera dashboards conflitantes.
Valide tipo: integer vs currency vs float. Moeda exige currency parameter no evento de receita. Métricas derivadas complexas (ROAS custom) frequentemente pertencem ao BI/BQ, não ao GA4.
Como mapear dataLayer → parâmetro → registro GA4?
Fluxo documentado: dataLayer key → variável GTM → parâmetro event/user → registro admin GA4 → aparece em explorations/BQ. Quebra em qualquer elo vira (not set). Use planilha ou data contract com owner engenharia + analytics.
Naming: snake_case consistente, prefixo de domínio (crm_, prod_, exp_). Evite renomear parâmetro live — prefira versionar evento ou campo novo com sunset do antigo.
Governança: quem aprova novo custom field?
Processo mínimo: solicitação com pergunta de negócio, escopo, cardinalidade estimada, owner, sunset plan. Comitê leve (analytics lead + eng) semanal. Emergency slot só com post-mortem.
Audite slots trimestralmente: dimensões sem uso em 90 dias candidatas a deprecação. GA4 não “desregistra” histórico limpo — deprecar significa parar de enviar e migrar dashboards.
- Formulário de solicitação com cardinalidade e escopo
- Inventário vivo de slots usados/disponíveis
- Review trimestral de dimensões zumbis
- Proibido PII e IDs ultra-cardinais na UI
- Sunset documentado ao trocar semântica
GA4 vs BigQuery: o que fica onde?
UI GA4: dimensões baixa/média cardinalidade que marketing usa semanalmente. BigQuery: IDs, paths completos, joins com CRM, atributos voláteis. Registrar tudo no GA4 é desperdício; registrar nada empobrece audiences e explorations operacionais.
Regra DataScroll: se aparece no weekly business review e tem <200 buckets estáveis, candidate a custom dimension registrada. Se só analista de dados usa, BQ view.
Checklist prático
- Inventário de slots disponíveis por escopo
- Glossário com escopo e cardinalidade por campo
- Processo de aprovação antes de registrar
- Mapeamento dataLayer→GTM→GA4 documentado
- Proibição explícita de PII em custom dimensions
- Bucketização para URLs, IDs e textos livres
- Review trimestral de dimensões/metrics não usadas
- Plano BQ para alta cardinalidade
Erros comuns
- Registrar transaction_id como dimensão de análise
- Esgotar slots com testes abandonados
- User scope para atributo que muda a cada pageview
- Renomear parâmetro sem versionar evento
- Duplicar revenue em custom metric desnecessária
- Ignorar item scope no ecommerce de catálogo grande
Dimensão custom virou lixo de cardinalidade?
A DataScroll define custom dimensions/metrics com escopo, naming e governança — antes de registrar tudo errado.