Públicos no Google Analytics 4: criação e uso para entender comportamento recorrente

O que são Públicos (Audiences) no GA4 e por que eles ajudam a entender recorrência

No Google Analytics 4, Públicos (Audiences) são grupos de usuários definidos por regras. Essas regras podem usar dimensões (ex.: página, origem/mídia, país, dispositivo), eventos (ex.: page_view, purchase, generate_lead) e propriedades do usuário (quando existirem). O GA4 passa a “marcar” usuários que atendem às condições e mantém esse grupo atualizado ao longo do tempo.

Na prática, públicos servem para: (1) observar comportamento recorrente (quem volta, quem engaja repetidamente, quem abandona), (2) comparar desempenho entre grupos dentro dos relatórios e (3) ativar esses grupos em integrações (por exemplo, mídia), quando aplicável. Aqui o foco é entender comportamento e leitura de relatórios.

Como pensar a lógica de um público (antes de criar)

Uma regra de público normalmente combina três decisões:

• Quem entra? (condições de inclusão: eventos, páginas, fonte, etc.)
• Quando entra? (no momento em que cumpre a condição; alguns públicos dependem de sequência)
• Por quanto tempo fica? (duração de associação/membership duration)

Exemplo de raciocínio: “Quero ver usuários que visitaram a página de preços e voltaram nos últimos 14 dias”. Isso vira um público com condição de visita à página + critério de recorrência (quando disponível) e duração de 14 dias.

Onde criar Públicos no GA4

Caminho típico: Admin > (coluna Property) > Audiences > New audience.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Você verá opções como criar a partir de um template (quando disponível) ou criar um público personalizado. Para aprender a lógica, o mais útil é Custom audience, porque você controla as regras.

Passo a passo: criando um Público personalizado (regras simples)

1) Defina o objetivo e a janela de tempo

Escreva em uma frase o que você quer observar e em quanto tempo isso faz sentido. Exemplos:

• “Usuários engajados nos últimos 30 dias”
• “Visitantes da página /precos nos últimos 14 dias”
• “Iniciaram checkout mas não compraram nos últimos 7 dias”
• “Usuários recorrentes nos últimos 28 dias”

Essa janela geralmente vira a membership duration (duração do público). Se você quer analisar comportamento recente, use 7, 14 ou 30 dias. Se quer um grupo mais amplo, use 60–90 dias (com cuidado para não “misturar” intenções antigas).

2) Escolha o tipo de condição

Em públicos personalizados, você costuma trabalhar com:

• Include users when: condições para entrar (ex.: evento ocorreu, página foi vista).
• Exclude users when: condições para remover/evitar entrada (ex.: quem comprou não deve estar no público de abandono).
• Sequência (quando disponível): para exigir ordem de eventos (ex.: iniciou checkout e depois não comprou).

3) Use dimensões e eventos já existentes

Para regras simples, prefira dimensões e eventos padrão do GA4, como:

• Eventos: page_view, session_start, first_visit, purchase, generate_lead, add_to_cart, begin_checkout (se existirem no seu site/app).
• Dimensões comuns: Page path and screen class, Page location, Source, Medium, Device category, Country.

Se você não tiver certeza do nome exato do evento (por exemplo, se existe begin_checkout), confirme antes em relatórios de eventos. Evite criar públicos baseados em eventos que não aparecem com frequência, porque eles podem demorar a popular.

Exemplo 1: Público de “Usuários engajados”

Objetivo: separar usuários com sinais de qualidade para comparar comportamento e resultados.

Regra prática (simples)

Uma forma direta é usar a dimensão/condição de engajamento quando disponível no construtor de público (por exemplo, usuários com sessão engajada). Se o construtor permitir, use algo equivalente a: Engaged sessions > 0 ou condição de usuário engajado.

Quando essa opção não estiver disponível de forma clara no construtor, uma alternativa prática é usar eventos que indicam engajamento real, como:

• user_engagement (quando disponível)
• ou combinação de eventos como scroll + page_view (se o seu GA4 coleta scroll)

Passo a passo

• Admin > Audiences > New audience > Custom audience
• Nome: Usuários engajados (30d)
• Include users when: evento user_engagement ocorreu (ou condição equivalente disponível)
• Membership duration: 30 days
• Salvar

Dica: se você usar scroll como proxy, lembre que nem todo site mede scroll de forma consistente (depende da configuração de medição aprimorada e do tipo de página). Prefira a opção de engajamento nativa quando existir.

Exemplo 2: Público de “Visitantes de uma página específica”

Objetivo: entender o que acontece com quem demonstrou interesse em um conteúdo/etapa do funil (ex.: página de preços, página de produto, página de contato).

Regra recomendada

Use o evento page_view com a dimensão de caminho/URL.

Passo a passo (página por caminho)

• Admin > Audiences > New audience > Custom audience
• Nome: Visitou /precos (14d)
• Include users when: event_name equals page_view
• Adicionar condição: Page path and screen class equals /precos (ou contém /precos se houver variações)
• Membership duration: 14 days
• Salvar

Cuidados comuns

• Query strings: se você usar Page location (URL completa), parâmetros como ?utm= podem fragmentar a regra. Para evitar isso, prefira Page path and screen class quando possível.
• Barra final: /precos vs /precos/. Use “contém” se seu site alterna.

Exemplo 3: Público “Iniciou mas não concluiu uma conversão” (abandono inferível)

Objetivo: identificar usuários que demonstraram intenção (iniciaram um processo) mas não chegaram ao evento-chave final. Isso é “inferível” quando você tem um evento de início e um evento de conclusão.

Cenário A: E-commerce (begin_checkout sem purchase)

Se seu GA4 registra begin_checkout e purchase, você pode criar um público de abandono de checkout.

Passo a passo

• Admin > Audiences > New audience > Custom audience
• Nome: Abandono de checkout (7d)
• Include users when: event_name equals begin_checkout
• Exclude users when: event_name equals purchase
• Membership duration: 7 days
• Salvar

Interpretação: esse público tende a capturar usuários que iniciaram checkout e, dentro do período de associação, ainda não registraram compra. Se o usuário comprar depois, ele pode sair do público (dependendo da lógica e do tempo).

Cenário B: Geração de leads (iniciou formulário sem enviar)

Se você tem um evento de início (ex.: form_start) e um evento de envio (ex.: generate_lead ou form_submit), a lógica é a mesma:

• Include: form_start
• Exclude: generate_lead (ou form_submit)

Se você não tem evento de início, uma aproximação é usar visita à página do formulário como “início” e o evento de conversão como “conclusão”. Ex.: Include visitou /contato e Exclude generate_lead.

Limitações importantes (para não interpretar errado)

• Janela de tempo: alguém pode iniciar hoje e concluir amanhã; se a membership duration for curta, você pode classificar como abandono temporário.
• Eventos ausentes: se purchase falha em registrar (por bloqueio/erro), o público pode inflar.
• Multidispositivo: o usuário pode iniciar no celular e concluir no desktop; dependendo da identificação, pode não ser reconhecido como a mesma pessoa.

Exemplo 4: Público de “Usuários recorrentes”

Objetivo: separar quem volta ao site/app para entender padrões de retenção e comportamento repetido.

Formas comuns de definir recorrência

• Por dimensão nativa: se o construtor permitir, use algo como New/established (ou equivalente) para filtrar usuários estabelecidos/retornantes.
• Por evento de retorno: em alguns casos, você pode usar a presença de mais de uma sessão/visita dentro de uma janela. Quando o construtor permitir métricas/condições de contagem, use “sessões > 1” no período.
• Por exclusão de first_visit: uma aproximação é excluir usuários que só têm first_visit como marcador recente, mas isso pode ser impreciso (cookies, consentimento e resets).

Passo a passo (quando houver dimensão de recorrência)

• Admin > Audiences > New audience > Custom audience
• Nome: Usuários recorrentes (28d)
• Include users when: condição de usuário “retornante/estabelecido” (dimensão equivalente disponível no construtor)
• Membership duration: 28 days
• Salvar

Se você não encontrar uma dimensão clara de recorrência no construtor, use um critério comportamental mais observável, como “visitou a página X” + “voltou a ver qualquer página em outro dia”, mas isso normalmente exige condições de sequência/tempo que podem não estar disponíveis em todas as propriedades.

Como usar Públicos na leitura de relatórios (sem repetir a teoria de comparações)

1) Aplicar o público como filtro/recorte

Depois de criado, o público aparece como opção de recorte em relatórios que aceitam comparações/segmentações por público. Use isso para responder perguntas como:

• “O público Visitou /precos tem taxa de conversão maior do que o restante?”
• “Usuários engajados consomem mais páginas por sessão do que usuários gerais?”
• “O público de abandono volta e conclui depois?”

2) Comparar públicos entre si

Crie dois públicos complementares para leitura mais clara. Exemplos:

• Visitou /precos (14d) vs Não visitou /precos (14d) (este segundo pode ser feito por exclusão, se fizer sentido)
• Abandono de checkout (7d) vs Compradores (7d) (público include purchase)
• Recorrentes (28d) vs Novos (28d) (se a dimensão existir)

Ao comparar, observe principalmente: eventos-chave, caminhos de páginas, origem/mídia e dispositivos. A diferença entre públicos costuma revelar gargalos (ex.: abandono maior no mobile) e oportunidades (ex.: recorrentes respondem melhor a determinado conteúdo).

3) Usar públicos para “fixar” uma definição ao longo do tempo

Uma vantagem do público é que ele padroniza a regra. Em vez de refazer filtros manuais toda vez, você cria uma definição única (ex.: “visitou /precos”) e usa sempre a mesma referência em análises futuras.

Como validar se um público está populando corretamente

1) Verifique o status e o tamanho do público

Em Admin > Audiences, cada público mostra informações de status e tamanho (quando disponível). Se o tamanho ficar zerado por muito tempo, normalmente é por: regra muito restrita, dimensão/evento inexistente, ou tráfego insuficiente.

2) Teste a regra com um “público de controle”

Crie um público propositalmente amplo para confirmar que a mecânica está funcionando. Exemplo:

• Nome: Todos com page_view (7d)
• Include: event_name equals page_view

Se esse público não cresce, há um problema mais básico (coleta, propriedade errada, ou regra mal montada).

3) Compare com contagens em relatórios de eventos/páginas

Se você criou “Visitou /precos”, confira se a página /precos realmente recebe visualizações no período. Se há visualizações mas o público não cresce, revise:

• Se você usou Page path and screen class com o valor exato correto
• Se deveria ser “contém” em vez de “igual”
• Se a página tem variações (ex.: /precos e /precos/)

4) Use um usuário de teste (quando possível) para disparar a condição

Abra o site e execute a ação que deveria te incluir no público (ex.: visitar /precos, iniciar checkout). Depois, aguarde o tempo de processamento. Públicos não são necessariamente instantâneos; pode haver atraso até aparecerem em relatórios.

5) Revise inclusão e exclusão para evitar “anular” o público

Erros comuns:

• Excluir com uma condição muito ampla (ex.: excluir page_view sem querer)
• Incluir um evento raro e excluir um evento comum, resultando em quase ninguém elegível
• Membership duration curta demais para o comportamento que você quer observar

Checklist rápido de boas práticas ao criar públicos