GA4 e Teste A/B: o Guia Completo de Integração

O GA4 (Google Analytics 4) não decide sozinho quem venceu um teste A/B. Ele mede, com detalhe, o comportamento e a receita de cada variante que você mostrou para os visitantes, mas a decisão de “isso foi sorte ou foi real” exige um cálculo estatístico que o GA4 não faz de forma nativa. Este guia mostra exatamente onde o GA4 entrega valor real para quem testa variações (eventos, funis, receita, segmentação), onde ele para (significância, sorteio de visitantes, poder estatístico) e como fechar essa lacuna com uma estrutura de eventos correta, o BigQuery e uma calculadora de significância honesta.

Ele nasce de uma pergunta que aparece toda semana em equipes de growth e CRO: “o Google Optimize acabou, o GA4 virou o centro de tudo, então dá para testar A/B só com o GA4?”. A resposta curta é: dá para medir só com o GA4, mas não dá para decidir só com ele. A resposta longa está nas próximas seções, com números reais, exemplo trabalhado e as fontes que sustentam cada limite técnico citado aqui.

O que o GA4 faz bem em teste A/B (e o que ele não faz)

O GA4 é, hoje, provavelmente a ferramenta de comportamento mais usada do mercado, e isso não é acidente: ela é gratuita, integra com o Google Ads, com o BigQuery e com o Tag Manager, e tem um modelo de dados baseado em eventos que se encaixa bem em qualquer coisa que você queira medir, incluindo variantes de um teste.

O que o GA4 faz bem:

• Registra comportamento com granularidade de evento. Cliques, visualizações de página, scroll, envio de formulário, cada um vira um evento com parâmetros, e você decide quais parâmetros importam.
• Segmenta por praticamente qualquer dimensão. Dispositivo, canal de aquisição, localização, e, se você configurar direito, a variante de um teste que o visitante viu.
• Conecta comportamento à receita. O evento purchase (ou o key event equivalente) carrega valor monetário, e o GA4 cruza isso com qualquer outra dimensão que você tenha marcado, inclusive a variante do teste.
• Serve de fonte única de verdade para funis. Um relatório de exploração de funil mostra queda etapa a etapa, o que ajuda a decidir onde vale a pena testar, mesmo antes de rodar qualquer experimento.
• Alimenta o BigQuery com dados brutos. É a porta de saída para qualquer análise estatística mais rigorosa do que os relatórios padrão permitem.

O que o GA4 não faz, e que times acostumados com o antigo Google Optimize sentem falta:

• Não sorteia visitantes entre variações. Isso é trabalho de uma ferramenta de teste A/B (ou de um sistema de feature flag com bucketing) que decide, para cada visitante, qual versão ele vê e mantém essa atribuição estável.
• Não calcula significância estatística nativamente. O relatório padrão mostra a diferença bruta entre dois números. Ele não informa se essa diferença é estatisticamente confiável ou apenas ruído de amostra pequena.
• Não controla poder estatístico nem tamanho de amostra. O GA4 não avisa “você precisa de mais 4 mil visitantes para essa diferença ser confiável”. Isso fica por conta de quem está analisando.
• Não corrige peeking. Se você olhar o relatório todo dia e parar assim que “parecer” que uma variante ganhou, o GA4 não vai te alertar que essa prática infla o falso positivo.

A tabela resume a divisão de trabalho:

Tarefa	O GA4 faz nativamente	Precisa de outra peça
Contar visitantes, eventos e conversões por variante	Sim
Segmentar receita por variante	Sim (via dimensão customizada)
Sortear e manter o visitante na mesma variante		Sim, ferramenta de teste A/B
Calcular valor-p, intervalo de confiança e poder		Sim, calculadora estatística
Alertar sobre amostra insuficiente ou peeking		Sim, disciplina + ferramenta
Exportar dados brutos sem amostragem	Sim, via BigQuery Export

Guarde essa divisão: ela é o fio condutor do resto deste guia.

Um cenário real ilustra bem a confusão: um time de growth troca o texto do botão principal de uma página, olha o GA4 duas semanas depois e vê a variante nova com 8% mais conversões. A reação natural é comemorar e implementar em definitivo. O problema é que o GA4 nunca disse que esses 8% eram estatisticamente confiáveis, apenas que essa foi a diferença observada naquele recorte de tempo. Sem rodar o mesmo par de números numa calculadora de significância, o time não tem como saber se está diante de um ganho real ou de uma flutuação de amostra que teria desaparecido numa segunda leva de tráfego.

O vazio que o fim do Google Optimize deixou

Até 30 de setembro de 2023, o Google Optimize (e sua versão paga, o Optimize 360) era a ferramenta gratuita que muita gente usava para testar variações de página integradas ao então Universal Analytics. O Google anunciou o encerramento em 20 de janeiro de 2023, dando um prazo de cerca de oito meses para migração, conforme registrado por veículos do setor no momento do anúncio (Search Engine Roundtable, 2023).

O motivo declarado do encerramento foi o Google concentrar esforço de engenharia na integração de terceiros com o GA4, deixando o papel de “motor de experimentação” para ferramentas dedicadas, enquanto o GA4 vira a camada de medição e machine learning por trás delas. Na prática, isso deixou duas escolhas para quem quer continuar testando variações com rigor:

1. Usar uma ferramenta de teste A/B dedicada (client-side ou server-side) que já sorteia visitantes e, idealmente, já embute a estatística, enviando os eventos relevantes para o GA4 como camada de medição e receita.
2. Montar o sorteio na mão (via feature flag, cookie de bucketing ou lógica no backend) e usar o GA4 só para coletar os números, calculando a significância à parte, com uma calculadora como a calculadora de significância deste blog.

As duas opções passam pelo mesmo ponto: o GA4 precisa saber, para cada visitante e cada conversão, qual variante estava em jogo. É disso que trata a próxima seção.

Como estruturar eventos customizados para marcar variante e experimento

A prática mais usada, e recomendada pela própria documentação de integração de experimentos do GA4 para frameworks próprios (fora de uma ferramenta de teste de terceiros), é dedicar um evento à exposição do experimento e carregar nele os parâmetros que identificam qual teste e qual variante o visitante viu (Google for Developers, “Create an experiment integration with Google Analytics”). Um padrão comum:

• Nome do evento: view_experiment (ou experiment_impression, o nome importa menos que a consistência).
• Parâmetro experiment_id: um identificador estável do teste, por exemplo cta_cor_botao_jul26.
• Parâmetro variant_id: qual variante o visitante viu, por exemplo controle ou variante_b.

Depois de disparar o evento com esses parâmetros, o passo que costuma ser esquecido é registrar os parâmetros como dimensões customizadas no GA4 (Admin, na seção de definições customizadas). Sem esse passo, o parâmetro chega no evento bruto, mas não aparece como coluna disponível em relatórios e explorações.

Duas decisões de escopo importam:

• Escopo de evento: o valor vale só para aquele evento específico. Funciona bem para view_experiment, mas se você quiser filtrar o evento purchase pela variante, o parâmetro de variante precisa estar presente também no evento de compra, ou você usa o próximo escopo.
• Escopo de usuário: grava a variante como uma propriedade do usuário (user property), válida para toda a sessão (e sessões futuras, se o mesmo identificador persistir). É a forma mais robusta de garantir que o evento purchase, que acontece minutos ou dias depois da exposição, ainda carregue a informação de qual variante aquele visitante viu.

A tabela resume a convenção sugerida:

Elemento	Nome sugerido	Escopo no GA4	Onde aparece
Evento de exposição	view_experiment	Evento	Toda vez que uma variante é mostrada
Parâmetro do teste	experiment_id	Dimensão customizada de evento	Relatórios e explorações
Parâmetro da variante	variant_id	Dimensão customizada de evento	Relatórios e explorações
Propriedade persistente	experiment_bucket	Dimensão customizada de usuário	Qualquer evento da mesma sessão/usuário, inclusive purchase

Se você quiser o passo a passo completo de implementação, incluindo o disparo via Google Tag Manager e a validação no DebugView, veja o guia dedicado Como Rastrear Eventos de Teste A/B no GA4, que é o complemento prático deste pilar.

Um detalhe que evita retrabalho: combine a convenção de nomes antes de o primeiro teste ir ao ar, e documente-a num lugar visível para toda a equipe (marketing, produto e quem mexe no GTM). Times que deixam cada pessoa escolher o próprio nome de evento ou parâmetro (exp_view numa campanha, experiment_seen noutra) acabam com dimensões customizadas duplicadas e relatórios que não conversam entre si, além de gastar cota de dimensões customizadas à toa.

Os limites reais do GA4 que todo experimentador precisa conhecer

Antes de desenhar sua taxonomia de eventos, vale conhecer os tetos técnicos do GA4, porque eles mudam com o tempo e variam entre propriedade padrão (gratuita) e GA4 360 (paga). Os números abaixo foram conferidos na documentação oficial do Google Analytics em julho de 2026; como esses limites são atualizados pelo próprio Google periodicamente, confirme o valor vigente na fonte antes de planejar algo que dependa deles no limite.

Recurso	Propriedade padrão	GA4 360
Dimensões customizadas (escopo de evento)	50	125
Dimensões customizadas (escopo de usuário)	25	100
Dimensões customizadas (escopo de item)	10	25
Métricas customizadas	50	125
Retenção de dados de usuário	2 ou 14 meses	2 ou 14 meses
Retenção de dados de evento	2 ou 14 meses	2, 14, 26, 38 ou 50 meses
Amostragem em Explorations (por consulta)	a partir de ~10 milhões de eventos	a partir de ~100 milhões (até ~1 bilhão)
BigQuery Export diário (lote)	1 milhão de eventos/dia	20 bilhões de eventos/dia

Segundo a documentação oficial de definições customizadas do Google Analytics, propriedades padrão têm 50 dimensões customizadas de escopo de evento, 25 de escopo de usuário e 10 de escopo de item, mais 50 métricas customizadas, com os tetos de propriedades GA4 360 bem acima disso (Google Analytics Help, “Sobre dimensões e métricas personalizadas”). Isso raramente é um problema para um programa de testes A/B comum, mas times que rodam dezenas de experimentos simultâneos com muitos parâmetros por evento podem se aproximar do limite, principalmente no escopo de usuário.

Sobre retenção: por padrão, o GA4 mantém dados de usuário e de evento por 2 meses. Numa propriedade padrão você pode estender isso para até 14 meses em Admin, na seção de coleta e modificação de dados. Propriedades GA4 360 (pagas) têm opções adicionais de 26, 38 e 50 meses para dados de evento (Google Analytics Help, “Sobre a retenção de dados”). Esse ajuste importa especialmente para testes A/B de ciclo longo (por exemplo, testes que medem retenção de assinatura ao longo de vários meses): se a retenção estiver no padrão de 2 meses, os dados de exploração mais antigos simplesmente somem antes de você conseguir analisá-los.

Sobre amostragem: os relatórios de exploração do GA4 aplicam amostragem quando uma consulta ultrapassa a cota de eventos da propriedade, cerca de 10 milhões de eventos por consulta em propriedades padrão, e uma cota inicial bem maior (até cerca de 100 milhões, com teto de até 1 bilhão) em propriedades GA4 360 (Google Analytics Help, “Sobre a amostragem de dados”). Um ícone de qualidade de dados avisa quando o resultado que você está vendo é amostrado e qual porcentagem dos dados foi usada. Para um teste A/B de alto tráfego, isso importa: se você está lendo a significância diretamente de uma Exploration amostrada, o valor-p que você calcular por cima de números já amostrados carrega um erro adicional que a calculadora não tem como corrigir sozinha.

BigQuery export: a saída para análise sem amostragem

A forma mais robusta de fugir da amostragem é exportar os eventos brutos do GA4 para o BigQuery e rodar você mesmo o cálculo estatístico em cima dos dados completos, sem passar pela camada de relatórios do GA4. A configuração é gratuita para propriedades padrão (Admin, na seção de integrações de produto), com uma ressalva importante: a exportação diária em lote tem um limite de 1 milhão de eventos por dia; se a propriedade passar disso de forma consistente, o Google pode pausar a exportação (Google Analytics Help, “Configurar a exportação do BigQuery”). Sites de alto tráfego que precisam de mais do que isso normalmente migram para a exportação em streaming, que não tem esse teto, ou para uma conta GA4 360.

Uma vez com os eventos brutos no BigQuery, o fluxo para validar um teste A/B fica assim:

1. Filtrar os eventos view_experiment (ou o nome que você escolheu) pelo experiment_id do teste em questão, separando por variant_id.
2. Contar visitantes únicos por variante (a unidade de aleatorização, normalmente user_pseudo_id).
3. Contar conversões por variante, cruzando com o evento de conversão relevante (purchase, sign_up, ou o key event definido para aquele teste).
4. Rodar o mesmo cálculo de duas proporções que uma calculadora de significância estatística usa (a fórmula do escore z para duas proporções), seja via SQL no próprio BigQuery, seja exportando os quatro números (visitantes e conversões de cada lado) para uma calculadora como a deste blog.

É exatamente esse último passo, os quatro números saindo do BigQuery (ou até de um relatório padrão do GA4, sem amostragem, quando o volume é baixo) e entrando numa calculadora de significância, que a seção de exemplo trabalhado abaixo demonstra na prática.

Google Tag Manager como camada de disparo

Na prática, a maior parte das implementações não escreve o evento view_experiment direto no código da página. Ele é disparado pelo Google Tag Manager (GTM), com uma tag configurada para ler a variante ativa (normalmente exposta pela ferramenta de teste A/B como uma variável de JavaScript ou um data layer push) e enviar isso como evento do GA4, com experiment_id e variant_id como parâmetros da tag.

Essa camada intermediária tem uma vantagem prática: se você trocar de ferramenta de teste A/B no futuro, ou rodar o sorteio por conta própria via feature flag, só precisa ajustar o gatilho e a variável dentro do GTM, sem tocar no evento que chega no GA4 nem na taxonomia de dimensões customizadas que você já configurou. A implementação detalhada de tags, gatilhos e variáveis para esse cenário específico foge do escopo deste pilar, mas é um tema que merece (e vai ganhar) um guia dedicado próprio neste blog.

Client-side, server-side, ou tag server-side

O mesmo evento view_experiment pode chegar ao GA4 por três caminhos diferentes, e a escolha afeta a confiabilidade do dado, não só a implementação. Pelo GTM no navegador (client-side), a implementação é rápida, mas fica sujeita a bloqueadores de anúncio e a atrasos de carregamento. Direto do backend (server-side), o disparo é mais robusto e imune a bloqueio no navegador, o padrão recomendado para testes em produto e SaaS. Um container de GTM server-side fica no meio do caminho: centraliza a lógica de disparo num servidor que você controla, reduzindo a dependência do navegador do visitante sem exigir que cada evento seja escrito à mão no backend da aplicação. Nenhuma das três opções resolve significância estatística, isso continua sendo tarefa da calculadora, mas a escolha errada pode enviesar a contagem de eventos entre variantes antes mesmo de o cálculo começar.

Como atribuir receita ao vencedor de um teste no GA4

A pergunta que decide o teste raramente é “qual variante teve mais cliques”, é “qual variante gerou mais receita, ou mais das conversões que pagam a conta”. O GA4 já sabe fazer essa conta, desde que o evento de conversão (purchase, com o parâmetro value preenchido, ou o key event equivalente para um SaaS) carregue também a dimensão de variante, seja diretamente ou via a propriedade de usuário experiment_bucket descrita na seção de eventos.

Com essa segmentação em mãos, um relatório de exploração de funil (ou uma tabela livre com a dimensão de variante e a métrica de receita) já mostra, lado a lado, quanto cada variante converteu e quanto cada variante faturou. É aqui, especificamente, que o GA4 entrega valor que nenhuma calculadora sozinha entrega: o cruzamento entre variante, etapa do funil e valor monetário, com toda a segmentação adicional (dispositivo, canal, novo x recorrente) que o resto da ferramenta já oferece.

O que o GA4 continua sem entregar, mesmo com a receita corretamente segmentada, é a resposta para “essa diferença de receita é estatisticamente confiável, ou dá pra explicar por sorte de amostra”. Para isso, os quatro números do funil (visitantes e conversões de cada lado) alimentam a calculadora de significância, exatamente como no exemplo a seguir.

Um exemplo trabalhado: do GA4 à significância estatística

Imagine que você exportou do GA4 (de uma Exploration de funil segmentada pela dimensão variant_id, sem amostragem porque o volume está abaixo do teto de 10 milhões de eventos) os seguintes números de um teste A/B de checkout:

• Controle (A): 12.000 visitantes que viram view_experiment, 480 compras (purchase).
• Variante (B): 12.000 visitantes, 540 compras.

O relatório padrão do GA4 mostra a diferença bruta: a taxa de conversão de A é 480 ÷ 12.000 = 4,00%, a de B é 540 ÷ 12.000 = 4,50%, uma melhora relativa de +12,5%. Até aqui, é só aritmética, e é exatamente o que o GA4 já entrega sozinho, com uma cor verde animadora na variante B. É também exatamente o ponto onde muita gente comemora cedo demais.

Rodando os mesmos quatro números (visitantes e conversões de cada lado) na calculadora de significância estatística deste blog, que usa o mesmo teste de duas proporções descrito no guia de significância estatística:

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

O resultado, calculado a partir desses números: o escore z fica em aproximadamente 1,92, o que dá um valor-p bilateral de aproximadamente 0,055 (5,5%). Com o corte convencional de 5%, esse teste não é estatisticamente significativo, ainda que a variante B esteja nominalmente à frente. O intervalo de confiança de 95% da diferença vai de aproximadamente −0,01 ponto percentual a +1,01 ponto percentual, ou seja, o intervalo praticamente toca o zero.

O que fazer com um resultado assim? As opções honestas são as mesmas de qualquer teste inconclusivo: deixar rodar mais tempo até atingir a amostra que a calculadora de tamanho de amostra recomendaria para esse efeito, aceitar que o ganho real pode ser menor do que os 12,5% observados, ou tratar o resultado como aprendizado (a mudança provavelmente não é prejudicial, mas ainda não está provada) e testar a próxima hipótese do backlog. O que não é honesto é publicar “aumentamos a conversão em 12,5%” com base só no número que o relatório padrão do GA4 mostrou, sem essa checagem.

Privacidade e consentimento: Consent Mode e LGPD

Todo número que sai do GA4 depende do que o visitante consentiu em compartilhar. O Consent Mode do Google é a camada que comunica, aos tags do Google (incluindo o GA4), o que cada visitante autorizou em termos de armazenamento e uso de dados; quando o consentimento é negado, o GA4 reduz a coleta e usa modelagem estatística e comportamental para preencher parte da lacuna, em vez de simplesmente não registrar nada (Google for Developers, “Consent mode overview”).

Isso tem duas implicações diretas para quem lê um resultado de teste A/B no GA4:

• A contagem bruta de eventos por variante pode divergir levemente do comportamento real, principalmente em mercados ou segmentos com alta taxa de recusa de cookies, porque parte dos números que você vê já passou por modelagem, não são todos observados diretamente.
• A implementação do Consent Mode precisa ser consistente entre as variantes. Se a variante B, por exemplo, mudar o posicionamento do banner de consentimento (algo comum em testes de layout), isso pode alterar a taxa de aceite de cookies entre A e B, contaminando a comparação com uma variável que não tem nada a ver com a hipótese original.

No Brasil, a LGPD exige base legal e transparência para o tratamento de dados pessoais, o que na prática se traduz, na maior parte dos sites, em obter consentimento explícito antes de disparar tags de analytics e publicidade, de forma equivalente ao que o GDPR exige na Europa (onde o Consent Mode se tornou, desde março de 2024, obrigatório para quem usa recursos de anúncios do Google com tráfego do Espaço Econômico Europeu). Trate a implementação de consentimento como parte do desenho do teste, não como um detalhe de compliance à parte: um teste A/B rodado sobre uma base de consentimento inconsistente entre variantes carrega um viés que nenhuma calculadora de significância consegue corrigir depois.

Uma checagem simples, e barata, resolve boa parte do risco: antes de olhar o resultado do teste em si, compare a taxa de aceite do banner de consentimento entre o grupo que viu A e o grupo que viu B. Se as duas taxas forem parecidas, o consentimento não é uma variável de confusão relevante para aquele teste. Se divergirem de forma expressiva, vale investigar se algo na variante (posição do banner, ordem de carregamento de scripts, até a cor do botão de aceite) mudou o comportamento de consentimento antes de confiar em qualquer diferença de conversão entre os dois lados.

Os erros mais comuns ao usar o GA4 para decidir um teste A/B

Nenhum dos erros abaixo é exótico, e é por isso que eles aparecem tanto: cada um parece uma economia de tempo razoável no dia a dia, até o momento em que a decisão errada custa caro (uma mudança revertida meses depois, ou pior, uma mudança ruim que ficou no ar porque “o GA4 mostrou que subiu”).

Erro	Por que é um problema	Correção
Confiar só na diferença percentual do relatório padrão	O GA4 mostra a diferença bruta, não se ela é estatisticamente confiável	Rodar os números numa calculadora de significância antes de declarar vencedor
Não filtrar tráfego interno e bot	Acessos da própria equipe e tráfego automatizado distorcem a taxa de conversão de cada variante, geralmente de forma desigual	Configurar filtros de dados internos no GA4 e excluir tráfego conhecido de bot
Olhar a métrica errada (engajamento em vez de negócio)	“Sessões engajadas” e “tempo médio de engajamento” são úteis, mas raramente são a métrica que paga a conta	Definir a métrica primária (compra, cadastro, trial) antes de rodar o teste, e não trocar no meio
Ler relatórios amostrados como se fossem exatos	Acima do teto de eventos por consulta, o GA4 amostra a Exploration e o ícone de qualidade avisa, mas é fácil ignorar	Checar o ícone de amostragem, ou exportar para o BigQuery quando o volume exigir precisão total
Esquecer o Consent Mode como variável de confusão	Diferença na taxa de aceite de cookies entre variantes contamina a comparação	Manter a implementação de consentimento idêntica entre controle e variação
Analisar sem ter definido a variante como dimensão de usuário	O evento de compra, que acontece depois da exposição, não carrega a variante se ela só foi marcada no escopo de evento	Usar uma propriedade de usuário (experiment_bucket) para persistir a variante durante toda a sessão

GA4 sozinho x GA4 com calculadora: o que cada um resolve

O que você precisa saber	GA4 sozinho	GA4 + calculadora/motor estatístico
Quantos visitantes viram cada variante	Sim	Sim (mesma fonte)
Quantas conversões e quanta receita por variante	Sim	Sim (mesma fonte)
Se a diferença é estatisticamente significativa	Não	Sim
Intervalo de confiança da diferença	Não	Sim
Tamanho de amostra necessário para o efeito que você quer detectar	Não	Sim
Alerta de amostra insuficiente ou peeking	Não	Depende da disciplina de quem analisa, mas a calculadora torna o número visível
Segmentação cruzada (dispositivo, canal, novo x recorrente)	Sim	Sim (mesma fonte)

A leitura direta dessa tabela é a tese deste guia inteiro: o GA4 é insubstituível como fonte de dados, e uma calculadora estatística (ou uma ferramenta de teste que já embuta uma) é insubstituível como camada de decisão. Tentar usar só um dos dois deixa metade do trabalho sem fazer.

Faça isso automático na Donnu

Você acabou de ver o trabalho manual que junta GA4 e estatística: estruturar o evento certo, registrar as dimensões customizadas, exportar para o BigQuery quando o volume exige, e só então rodar os números numa calculadora para saber se a diferença é real. A Donnu A/B fecha esse ciclo automaticamente: o snippet sorteia e mantém a variante de cada visitante, a plataforma já calcula a significância (com estatística bayesiana honesta) sem que você precise montar a conta à parte, e os eventos relevantes continuam disponíveis para você cruzar com o GA4 e o BigQuery quando quiser a visão de receita completa.

Comece um teste grátis de 14 dias e pare de decidir testes A/B só pela cor verde do relatório do GA4. Se quiser aprofundar antes, veja o que é um teste A/B do zero, como funciona a significância estatística por trás da calculadora, ou os erros comuns que invalidam um teste A/B, incluindo os que este guia cobriu em detalhe específico para o GA4.

Referências

• Google Analytics Help. Sobre dimensões e métricas personalizadas. support.google.com/analytics/answer/14240153.
• Google Analytics Help. Sobre a retenção de dados. support.google.com/analytics/answer/7667196.
• Google Analytics Help. Sobre a amostragem de dados. support.google.com/analytics/answer/13331292.
• Google Analytics Help. Configurar a exportação do BigQuery. support.google.com/analytics/answer/9358801.
• Google for Developers. Consent mode overview. developers.google.com/tag-platform/security/concepts/consent-mode.
• Google for Developers. Create an experiment integration with Google Analytics. developers.google.com/analytics/devguides/collection/ga4/integration.
• Search Engine Roundtable. Google Optimize To Sunset September 30, 2023. seroundtable.com.