Configuração avançada do GA4: guia completo de eventos e funis de conversão

Em 1 de julho de 2023, o Google encerrou de vez a coleta de dados do Universal Analytics. Naquela manhã, abri o painel, vi a linha de dados do UA parar de repente e só consegui pensar em uma coisa: afinal, como é que se usa esse tal de GA4 direito?

Se você, como eu, migrou do UA, instalou apenas o código básico e ficou encarando a interface do GA4 sem saber por onde começar, calma: você não está sozinho. Muitos donos de site estão operando no escuro. As visualizações de página aparecem, mas os dados que realmente importam ficam de fora: em quais botões os usuários clicam, quanto do artigo eles leem, em qual etapa eles abandonam o fluxo.

Este texto não vai explicar o que é GA4 do zero. A ideia é ir para o que interessa: como usar rastreamento de eventos para enxergar o comportamento do usuário, como usar funis de conversão para encontrar pontos de abandono e, se você precisar de análise mais profunda, como exportar os dados para o BigQuery e consultar tudo com SQL. Vamos começar pelos três tipos de evento.

1. Os três tipos de rastreamento de eventos no GA4

A lógica central do GA4 é completamente diferente da do UA. O UA usava um modelo de “sessão + visualização de página”. O GA4 usa a ideia de que “tudo é evento”.

Você provavelmente já ouviu essa frase várias vezes, mas o que ela significa na prática? Simples: visualização de página é evento, clique em botão é evento, reprodução de vídeo é evento, rolagem até o fim da página também é evento. Todo comportamento do usuário no GA4 vira um registro independente de evento.

Mas isso não quer dizer que você deva criar eventos de qualquer jeito. O Google divide os eventos em três categorias, cada uma com usos e limites próprios.

1. Eventos automáticos: Enhanced Measurement pronto para uso

Este é o “almoço grátis” do GA4. Ao criar um fluxo de dados, o Enhanced Measurement costuma vir ativado por padrão e rastreia automaticamente 7 tipos de interação:

• Visualização de página (page_view)
• Rolagem (scroll), mas apenas quando o usuário chega a 90% de profundidade
• Clique externo (click)
• Busca interna (search)
• Interação com vídeo (video_start, video_progress, video_complete)
• Download de arquivo (file_download)
• Interação com formulário (form_start, form_submit)

Parece bem completo, certo? Mas há uma pegadinha: o rastreamento de rolagem só registra quando o usuário chega a 90% da página. Se você quer saber quantas pessoas terminaram o artigo ou acompanhar pontos como 50% e 75% de leitura, o Enhanced Measurement não resolve. Você vai precisar configurar isso por conta própria, normalmente com GTM.

Minha recomendação: mantenha o Enhanced Measurement ativado, mas não espere demais dele. Ele entrega os dados básicos. Os comportamentos de usuário realmente valiosos ainda exigem configuração manual.

2. Eventos recomendados: siga o roteiro do Google

O Google já definiu um conjunto de “eventos recomendados” para diferentes setores. No e-commerce, por exemplo, existem add_to_cart, begin_checkout e purchase. Para sites de conteúdo, entram nomes como sign_up, login e share.

A vantagem dos eventos recomendados é simples: ao usar o nome e os parâmetros corretos, o GA4 consegue gerar relatórios correspondentes automaticamente. Se você usa o evento purchase, por exemplo, o GA4 entende a intenção e estrutura os relatórios associados.

Mas atenção: eventos recomendados não disparam sozinhos. Você ainda precisa adicionar código ao site ou configurar tudo no GTM. A diferença é que o nome do evento e os parâmetros precisam seguir rigorosamente o padrão do Google.

Um exemplo com eventos recomendados comuns em blogs:

No meu próprio blog, configurei o evento sign_up para rastrear inscrições. No começo, escrevi o nome como signUp, em camelCase. Resultado: o GA4 simplesmente não reconheceu como evento recomendado. Para eventos recomendados, use snake_case. Uma letra fora do padrão já atrapalha.

3. Eventos personalizados: rastreie o que quiser, mas aceite o custo

Quando o comportamento que você quer medir não aparece na lista recomendada do Google, o caminho é criar um evento personalizado. Eu, por exemplo, queria rastrear quando um usuário terminava de ler um artigo, então criei o evento article_read_complete.

Eventos personalizados dão bastante liberdade, mas trazem alguns limites:

1. Limite de parâmetros: cada evento aceita no máximo 25 parâmetros personalizados. Simo Ahava, uma das referências em GA4, testou que dados com mais de 25 parâmetros ainda podem ser exportados para o BigQuery, mas são ignorados nos relatórios nativos do GA4.

2. Padrão de nomes: use apenas letras, números e sublinhado, sempre começando por uma letra. Recomendo snake_case, para manter consistência com os eventos recomendados.

3. Atraso nos relatórios: depois de configurar um evento personalizado, ele pode levar de 24 a 48 horas para aparecer nos relatórios do GA4. Não conclua imediatamente que a configuração está errada. Espere um pouco.

Prioridade de configuração: uma árvore de decisão simples

Se você não tem certeza de qual tipo de evento usar, siga esta ordem:

1. Veja primeiro se o Enhanced Measurement já cobre o caso: vem pronto e poupa trabalho
2. Depois confira a lista de eventos recomendados: siga o padrão e aproveite os relatórios automáticos
3. Só personalize quando não houver alternativa: a liberdade é maior, mas o custo de manutenção também

Falando de forma direta, a maioria dos blogs funciona bem com Enhanced Measurement e alguns eventos recomendados. Eventos personalizados são para quem realmente precisa de análise mais profunda.

2. Configuração prática do rastreamento de eventos

Depois de entender os três tipos de evento, vem a parte prática: configurar.

Existem duas formas comuns de configurar eventos no GA4: usar o Google Tag Manager, o GTM, ou escrever código gtag.js diretamente na página. Eu recomendo GTM. A curva de aprendizado é um pouco maior, mas a manutenção fica muito mais simples depois. Mudar uma condição de disparo não exige novo deploy do código.

Configurando eventos do GA4 com GTM em quatro passos

Vamos supor que você queira rastrear o comportamento “leitura concluída de um artigo do blog”. O fluxo completo fica assim:

Passo 1: crie uma GA4 Event Tag

Abra o GTM, crie uma nova Tag e escolha o tipo Google Analytics: GA4 Event. Informe seu Measurement ID e preencha o nome do evento como article_read_complete.

Passo 2: configure o Trigger

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Aqui você diz ao GTM: “quando este evento deve disparar?”

Para “leitura concluída”, costumo usar rolagem: o evento dispara quando o usuário chega a 90% da página. Crie um novo Trigger, escolha o tipo Scroll Depth e defina Vertical Scroll Depths como 90%.

Mas há um detalhe. Se seu blog tem uma barra de progresso de leitura ou algo parecido, ela pode interferir no rastreamento de rolagem do GTM. Já caí nessa armadilha: havia uma barra no topo da página, os eventos de rolagem disparavam sem parar e os dados viraram ruído. A solução foi adicionar uma restrição: o mesmo usuário, no mesmo artigo, dispara o evento apenas uma vez.

Passo 3: adicione Event Parameters

Parâmetros são a alma do evento. Saber que alguém terminou um artigo não basta. Você precisa saber qual artigo, qual categoria e quem é o autor.

Na configuração da Tag, adicione Event Parameters:

Mantenha o tipo dos valores consistente. Se reading_time é numérico, continue enviando número. Não envie 5 hoje e "5 minutos" amanhã. O GA4 pode tratar isso como valores de naturezas diferentes e bagunçar os relatórios.

Passo 4: valide com Debug

Depois de configurar, não publique na pressa. Use o modo Preview do GTM: abra uma página do blog, role até 90% e confira se o evento aparece no GA4 DebugView.

O DebugView fica em Configure > DebugView no painel do GA4. Se o evento não aparecer, verifique as condições do Trigger. Se o evento aparecer sem parâmetros, revise a configuração das Variables.

Não quer usar GTM? Configure direto com gtag.js

Se seu blog usa um gerador de site estático, como Astro ou Hugo, e você não quer adicionar a complexidade do GTM, também dá para escrever o código gtag.js diretamente.

// Executa depois que a página termina de carregar
window.addEventListener('load', function() {
  // Dispara quando a rolagem chega a 90%
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

Esse código faz a mesma coisa que a configuração no GTM: quando o usuário chega a 90% da página, envia o evento article_read_complete. A diferença é que o código fica fixo na página. Qualquer mudança futura exige novo deploy.

Pegadinhas comuns, todas já vistas na prática

Pegadinha 1: nome de evento fora do padrão

articleReadComplete, article-read-complete e article_read_complete são três eventos diferentes para o GA4. Use snake_case em tudo e mantenha o padrão oficial do Google.

Pegadinha 2: tipo de parâmetro inconsistente

Hoje você envia reading_time: 5, amanhã reading_time: "5 minutes" e depois reading_time: true. O GA4 pode tratar isso como dados diferentes, e o relatório vira uma mistura difícil de interpretar.

Pegadinha 3: Consent Mode v2 filtrando eventos

Se seu site atende usuários da União Europeia e usa Google Consent Mode v2, alguns eventos podem não ser enviados quando o usuário recusa cookies. Isso não é erro de configuração, mas os relatórios ficam menores. Não confunda essa perda de dados com falha no GTM.

Pegadinha 4: uso de nomes reservados em eventos e parâmetros

page_view, session_start e first_visit são eventos reservados do GA4. Não use esses nomes para eventos personalizados. Parâmetros também têm listas de nomes reservados, então confira a documentação antes de configurar.

Exemplo prático para blogs

Para o cenário de blog, estes são alguns eventos úteis:

Depois de configurar esses eventos, você começa a enxergar no GA4 o comportamento real dos usuários dentro do blog. O próximo passo é analisar esses dados, e é aí que entram os funis de conversão.

3. Configuração e análise de funil de conversão

Com o rastreamento de eventos configurado, chega a hora de responder uma pergunta central: do momento em que o usuário chega pela primeira vez até completar seu objetivo, quantas pessoas se perdem no caminho?

É isso que o funil de conversão resolve.

O relatório Funnel Exploration do GA4 é muito mais forte que o funil do UA. No UA, o funil era rígido e limitado. No GA4, você define cada etapa, adiciona comparações por segmento e analisa o tempo de abandono. Na prática, muita coisa que antes parecia recurso de ferramenta paga entrou no produto gratuito.

Criando seu primeiro funil de conversão

Abra o GA4 e acesse Explore > Funnel Exploration. Você verá um modelo de funil vazio.

O primeiro passo é definir as etapas do funil. O limite é de até 10 etapas, mas para blogs, na prática, 4 ou 5 costumam bastar.

Um exemplo de funil de inscrição em blog:

1. Primeira etapa: visualização de página de artigo: event: page_view, condição: page_location contém /posts/
2. Segunda etapa: visita à página de inscrição: event: page_view, condição: page_location contém /subscribe
3. Terceira etapa: envio do formulário de inscrição: event: newsletter_signup
4. Quarta etapa: abertura do e-mail de confirmação: event: email_opened; esta etapa precisa de rastreamento no sistema de e-mail

Ao definir as etapas, use uma regra simples: mantenha cada condição clara e objetiva. Combinações complexas tornam o funil difícil de interpretar.

Análise do funil: encontre os pontos de abandono

Depois de configurar o funil, você verá a taxa de conversão e o número de usuários perdidos em cada etapa.

Suponha que os dados do meu funil de inscrição sejam estes:

Dá para ver de cara: o primeiro ponto de abandono é “página do artigo → página de inscrição”. Só 8% dos usuários chegam à página de inscrição. Isso indica que a entrada para inscrição não está visível o bastante ou está no lugar errado.

O segundo ponto é “página de inscrição → envio do formulário”, com taxa de conversão de 30%. Talvez o formulário esteja longo demais, ou o valor da inscrição não esteja claro.

Depois de encontrar os pontos de abandono, o próximo passo é comparar segmentos e procurar padrões.

Comparação por segmentos: descubra quem está abandonando

O Funnel Exploration permite adicionar segmentos para comparar a conversão entre grupos diferentes.

Dimensões comuns para segmentar:

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

• Novos usuários vs usuários recorrentes: novos usuários geralmente convertem menos, porque ainda não conhecem o valor do seu conteúdo
• Celular vs desktop: a experiência de preencher formulários no celular costuma ser pior
• Canal de origem: usuários vindos de mecanismos de busca vs usuários vindos de redes sociais

Um exemplo: comparei novos usuários e usuários recorrentes no funil de inscrição:

Usuários recorrentes convertem melhor em todas as etapas. Isso é normal: eles já confiam no conteúdo. Mas a etapa “página do artigo → página de inscrição” entre novos usuários tinha apenas 5%. Isso mostrava que novos usuários nem percebiam a entrada de inscrição.

Com base nessa descoberta, adicionei um cartão de inscrição mais visível no fim dos artigos. A conversão de novos usuários subiu de 5% para 12%.

Open Funnel: analise caminhos menos lineares

Por padrão, o Funnel Exploration trabalha como um “funil linear”: o usuário precisa completar as etapas em ordem para ser contado na conversão.

Mas o comportamento real dos usuários não é tão arrumado. Alguns pulam a página de inscrição e enviam o formulário direto no rodapé do artigo. Outros abrem o e-mail de confirmação e voltam ao artigo para ler de novo.

O GA4 oferece o modo “Open Funnel”: ele não força a ordem. Se o usuário completa uma etapa, entra naquela etapa do funil.

O Open Funnel ajuda a descobrir caminhos não típicos. No meu caso, 15% dos usuários inscritos enviavam o formulário diretamente pelo fim do artigo, sem passar pela página dedicada de inscrição. Isso mostrava que a entrada no fim do artigo era mais eficiente que a página de inscrição. O melhor uso do meu tempo era melhorar a experiência no rodapé dos artigos, não mexer só na página dedicada.

Erros comuns na análise de funil

Erro 1: olhar apenas para a conversão final

A taxa total, da primeira à última etapa, é importante. Mas os pontos intermediários de abandono são o que orienta a melhoria. Não olhe só para “1,8% dos usuários completaram a inscrição”. Veja qual etapa perdeu 92% dos usuários.

Erro 2: ignorar a dimensão de tempo

O Funnel Exploration permite configurar tempo de conversão: quanto tempo o usuário levou da primeira etapa até a última. Se seu funil é “leitura → compra → pagamento” e o usuário leva 7 dias da leitura ao pagamento, o ciclo de decisão é longo. Talvez você precise reforçar confiança ou criar pontos de contato de acompanhamento.

Erro 3: analisar com poucos dados

Análise de funil precisa de volume suficiente. Se uma etapa tem apenas algumas dezenas de usuários, a taxa de conversão oscila muito e a conclusão pode não ser confiável. Recomendo esperar chegar a algumas centenas de usuários antes de fazer análise profunda.

4. Exportação de dados para BigQuery na prática

Até aqui, tudo acontece dentro da interface do GA4. Mas os relatórios nativos têm uma limitação: quando o volume de dados é grande, eles podem usar amostragem. Se seu blog tem 500 mil usuários ativos por mês, por exemplo, um relatório do GA4 pode ser gerado com base em apenas 10% dos dados.

Amostragem não é necessariamente ruim. Ela acelera o carregamento dos relatórios. Mas se você precisa calcular taxas de conversão com precisão ou cruzar muitas dimensões, o resultado amostrado deixa de ser confiável.

Nesse caso, a exportação para BigQuery vira uma peça essencial.

Configuração da exportação para BigQuery em três passos

BigQuery é o serviço de data warehouse do Google. Ao exportar dados do GA4 para o BigQuery, você consulta o conjunto completo com SQL, sem depender da amostragem dos relatórios.

O processo é simples:

Passo 1: crie um projeto no BigQuery

No Google Cloud Console, crie um projeto e ative a BigQuery API. Novos usuários têm cota gratuita: 10GB de armazenamento por mês e 1TB de processamento de consultas, mais do que suficiente para a maioria dos blogs.

Passo 2: configure a exportação no GA4

Abra o GA4 Admin e encontre BigQuery Linking. Clique em Link, selecione seu projeto do BigQuery e escolha a frequência de exportação:

• Daily: exporta uma vez por dia os dados do dia anterior
• Streaming: exporta quase em tempo real, permitindo ver dados do próprio dia em poucas horas

Minha sugestão é ativar as duas. A exportação Daily tem estrutura mais estável e é melhor para análises de longo prazo. A Streaming é útil para acompanhar dados do dia.

Passo 3: espere os dados começarem a fluir

Depois da configuração, o GA4 costuma começar a exportar dados em até 24 horas. Mas há uma armadilha importante: a exportação para BigQuery não preenche histórico. Se você configurar hoje, começa a receber dados de hoje em diante. Os dados de GA4 dos últimos dois anos não entram automaticamente.

Então, se você tem necessidade de análise profunda, configure a exportação para BigQuery cedo. Não espere precisar do histórico para descobrir que já é tarde.

Estrutura dos dados no BigQuery: o básico para não travar

Os dados do GA4 exportados para o BigQuery chegam em tabelas diárias. O formato do nome é events_YYYYMMDD. Por exemplo, events_20260429 guarda os eventos de 29 de abril de 2026.

Cada registro representa um evento. Os campos incluem:

O ponto em que muita gente trava no começo é event_params. Ele é um campo aninhado, não uma coluna simples. Para consultar valores de parâmetros, você precisa usar UNNEST.

Algumas consultas SQL úteis

Consultar o número de usuários de um evento:

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

Essa consulta calcula quantos usuários únicos concluíram a leitura de artigos em abril.

Consultar a distribuição de um parâmetro de evento:

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

Essa consulta expande event_params e conta usuários que concluíram a leitura em diferentes categorias de artigo.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

BigQuery vs relatórios nativos do GA4: quando usar cada um?

Resumindo: para olhar relatórios no dia a dia, use a interface do GA4. Para análise profunda, use BigQuery.

Controle de custos no BigQuery

O BigQuery cobra pelo volume de dados processado nas consultas. Em blogs, o volume costuma ser pequeno e o custo tende a ser controlável. Mesmo assim, vale adotar alguns cuidados:

1. Use _TABLE_SUFFIX para limitar o intervalo de datas: não consulte todas as tabelas se você só precisa de um período
2. Filtre cedo com WHERE: quanto antes você reduz o conjunto, menos dados são processados
3. Crie visões materializadas: dados consultados com frequência podem ser pré-agregados

No meu blog, o volume mensal fica perto de 1GB e as consultas não passam de 100GB por mês. Isso fica totalmente dentro da cota gratuita. Sites maiores precisam acompanhar custos, mas blogs pequenos e médios geralmente não precisam se preocupar.

5. GA4 vs UA: diferenças que quem migrou precisa entender

Se você veio do UA e já cuidava de um site há algum tempo, esta seção é para você.

A diferença entre GA4 e UA não é só uma interface nova. A lógica de base mudou completamente. Muitos conceitos que pareciam óbvios no UA não existem mais no GA4 ou ganharam outra definição.

Modelo de eventos vs modelo de sessões

O centro do UA era a “sessão”: o usuário chegava, navegava por um tempo e saía. Isso era uma sessão. Uma sessão podia conter várias visualizações de página e vários eventos.

No GA4, o centro é o “evento”: cada comportamento do usuário é uma unidade atômica independente. A sessão vira um conjunto de eventos, não o ponto de partida da análise.

O que isso muda?

No UA, você se acostumou a olhar “número de sessões” e “visualizações de página por sessão”. No GA4, esses conceitos perdem espaço para “número de eventos” e “número de usuários”.

O GA4 ainda tem o conceito de sessão, mas ele enfatiza menos a sessão e mais a jornada do usuário. Um usuário pode abrir seu blog de manhã e voltar à tarde. No UA, isso aparece como duas sessões. No GA4, é o mesmo usuário com múltiplas visitas.

Taxa de engajamento vs taxa de rejeição

A “taxa de rejeição” do UA era quase uma obsessão para muitos donos de site: quanto menor, melhor, porque parecia indicar que o usuário ficou.

No GA4, a taxa de rejeição deixou de ser a métrica central. O destaque passou para a “taxa de engajamento”.

Por quê? Porque a definição de rejeição do UA tinha um problema. Se o usuário via uma única página e saía, isso contava como rejeição. Mas se esse usuário passava 10 minutos lendo o artigo inteiro, o UA ainda podia contar aquilo como rejeição.

A definição do GA4 é mais razoável: uma sessão conta como engajada se o usuário fica mais de 10 segundos no site, ou gera pelo menos um evento de conversão, ou visualiza mais de 2 páginas. Taxa de engajamento = sessões engajadas / total de sessões.

Por isso, não compare diretamente a taxa de engajamento do GA4 com a taxa de rejeição do UA. Elas não são conceitos opostos. São formas diferentes de medir comportamento.

Data Streams vs Views

O UA tinha o conceito de “Views”: você podia criar várias visões, cada uma com filtros diferentes. Uma visão só para tráfego doméstico, outra excluindo IP interno, e assim por diante.

O GA4 não tem Views. No lugar, usa “Data Streams”: Web, iOS App e Android App, cada um com seu fluxo de dados.

E os filtros? O GA4 substitui isso por “Property Filters”, mas com menos flexibilidade que as Views do UA. Dá para filtrar tráfego interno e tráfego indesejado, mas não criar múltiplas visões independentes como no UA para separar dados em diferentes recortes.

Se você usava Views do UA para isolar dados por dimensão, vai precisar repensar a arquitetura ao migrar para GA4. Uma opção é exportar para BigQuery e filtrar por conta própria. Outra é criar múltiplas visualizações de relatório no Looker Studio.

UA Goals precisam ser mapeados de novo

Os “Goals” do UA viraram “eventos de conversão” no GA4.

A forma de configurar também mudou. No UA, um Goal podia ser “visitar determinada página”, “ficar mais de X minutos” ou “disparar determinado evento”. No GA4, uma conversão precisa ser um evento. Se você quer rastrear a visita a uma página como conversão, primeiro precisa configurar um evento page_view com as condições corretas e depois marcar esse evento como conversão.

Na migração, liste todos os UA Goals e mapeie cada um para um evento de conversão no GA4. É um processo trabalhoso, mas necessário. Sem isso, os dados históricos de conversão não têm continuidade prática.

Para fechar

Depois de tudo isso, a ideia se resume a quatro pontos:

1. Rastreamento de eventos: entenda os três tipos, automáticos, recomendados e personalizados, e configure por prioridade
2. Funil de conversão: encontre pontos de abandono, compare segmentos e use Open Funnel para descobrir caminhos não típicos
3. Exportação para BigQuery: se você precisa de análise profunda, configure cedo; dados históricos não são preenchidos depois
4. Mentalidade de migração: não force métricas do UA dentro do GA4. Adapte-se à nova lógica

Se você terminou este artigo e quer fazer uma ação agora, minha sugestão é simples: abra o GA4, confira se o Enhanced Measurement está ativado e crie um funil de 3 ou 4 etapas para analisar o fluxo de inscrição do seu blog.

Os dados não entregam a resposta sozinhos, mas mostram onde está o problema. O resto é decidir como resolver.

Referências

• Set up events | Google Analytics | Google for Developers — documentação oficial do GA4 para configuração de eventos
• Recommended events - Analytics Help — lista de eventos recomendados
• Enhanced measurement events - Analytics Help — explicação dos eventos automáticos
• Funnel Exploration Report in GA4 - Analytics Mania — explicação detalhada do relatório de funil
• GA4 BigQuery Export Schema Tutorial - Optimize Smart — tutorial de exportação para BigQuery