GA4 y Test A/B: la Guía Completa de Integración

GA4 (Google Analytics 4) no decide por sí solo quién ganó un test A/B. Mide, con detalle, el comportamiento y los ingresos de cada variante que mostraste a los visitantes, pero la decisión de “esto fue suerte o fue real” exige un cálculo estadístico que GA4 no hace de forma nativa. Esta guía muestra exactamente dónde GA4 entrega valor real a quien testea variaciones (eventos, embudos, ingresos, segmentación), dónde se detiene (significancia, reparto de visitantes, poder estadístico) y cómo cerrar esa brecha con una estructura de eventos correcta, BigQuery y una calculadora de significancia honesta.

Nace de una pregunta que aparece cada semana en equipos de growth y CRO: “Google Optimize se acabó, GA4 se volvió el centro de todo, entonces, ¿se puede testear A/B solo con GA4?”. La respuesta corta es: se puede medir solo con GA4, pero no se puede decidir solo con él. La respuesta larga está en las próximas secciones, con números reales, ejemplo trabajado y las fuentes que sostienen cada límite técnico citado aquí.

Qué hace bien GA4 en test A/B (y qué no hace)

GA4 es, hoy, probablemente la herramienta de comportamiento más usada del mercado, y eso no es casualidad: es gratuita, integra con Google Ads, con BigQuery y con Tag Manager, y tiene un modelo de datos basado en eventos que encaja bien con cualquier cosa que quieras medir, incluidas las variantes de un test.

Lo que GA4 hace bien:

• Registra comportamiento con granularidad de evento. Clics, vistas de página, scroll, envío de formulario, cada uno se convierte en un evento con parámetros, y tú decides qué parámetros importan.
• Segmenta por prácticamente cualquier dimensión. Dispositivo, canal de adquisición, ubicación y, si lo configuras bien, la variante del test que el visitante vio.
• Conecta el comportamiento con los ingresos. El evento purchase (o el key event equivalente) lleva valor monetario, y GA4 lo cruza con cualquier otra dimensión que hayas marcado, incluida la variante del test.
• Sirve de fuente única de verdad para embudos. Un informe de exploración de embudo muestra la caída etapa por etapa, lo que ayuda a decidir dónde vale la pena testear, incluso antes de correr cualquier experimento.
• Alimenta BigQuery con datos brutos. Es la puerta de salida para cualquier análisis estadístico más riguroso de lo que permiten los informes predefinidos.

Lo que GA4 no hace, y que los equipos acostumbrados al viejo Google Optimize echan de menos:

• No reparte visitantes entre variaciones. Ese es trabajo de una herramienta de test A/B (o de un sistema de feature flag con bucketing) que decide, para cada visitante, qué versión ve y mantiene esa asignación estable.
• No calcula significancia estadística de forma nativa. El informe predefinido muestra la diferencia bruta entre dos números. No informa si esa diferencia es estadísticamente confiable o solo ruido de muestra pequeña.
• No controla el poder estadístico ni el tamaño de muestra. GA4 no te avisa “necesitas 4 mil visitantes más para que esa diferencia sea confiable”. Eso queda a cargo de quien analiza.
• No corrige el peeking. Si miras el informe todos los días y paras apenas “parece” que una variante ganó, GA4 no te va a alertar de que esa práctica infla el falso positivo.

La tabla resume el reparto de trabajo:

Tarea	GA4 lo hace de forma nativa	Necesita otra pieza
Contar visitantes, eventos y conversiones por variante	Sí
Segmentar ingresos por variante	Sí (vía dimensión personalizada)
Repartir y mantener al visitante en la misma variante		Sí, herramienta de test A/B
Calcular valor p, intervalo de confianza y poder		Sí, calculadora estadística
Alertar sobre muestra insuficiente o peeking		Sí, disciplina + herramienta
Exportar datos brutos sin muestreo	Sí, vía BigQuery Export

Guarda ese reparto: es el hilo conductor del resto de esta guía.

Un escenario real ilustra bien la confusión: un equipo de growth cambia el texto del botón principal de una página, mira GA4 dos semanas después y ve la variante nueva con 8% más conversiones. La reacción natural es celebrar e implementar en definitivo. El problema es que GA4 nunca dijo que esos 8% fueran estadísticamente confiables, solo que esa fue la diferencia observada en ese recorte de tiempo. Sin pasar ese mismo par de números por una calculadora de significancia, el equipo no tiene manera de saber si está ante una ganancia real o ante una fluctuación de muestra que habría desaparecido en una segunda tanda de tráfico.

El vacío que dejó el fin de Google Optimize

Hasta el 30 de septiembre de 2023, Google Optimize (y su versión de pago, Optimize 360) era la herramienta gratuita que mucha gente usaba para testear variaciones de página integradas al entonces Universal Analytics. Google anunció el cierre el 20 de enero de 2023, dando un plazo de cerca de ocho meses para migrar, según registraron medios del sector en el momento del anuncio (Search Engine Roundtable, 2023).

El motivo declarado del cierre fue que Google concentraría el esfuerzo de ingeniería en la integración de terceros con GA4, dejando el papel de “motor de experimentación” a herramientas dedicadas, mientras GA4 se vuelve la capa de medición y machine learning detrás de ellas. En la práctica, eso dejó dos opciones para quien quiere seguir testeando variaciones con rigor:

1. Usar una herramienta de test A/B dedicada (client-side o server-side) que ya reparte visitantes y, idealmente, ya incorpora la estadística, enviando los eventos relevantes a GA4 como capa de medición e ingresos.
2. Montar el reparto a mano (vía feature flag, cookie de bucketing o lógica en el backend) y usar GA4 solo para recolectar los números, calculando la significancia aparte, con una calculadora como la calculadora de significancia de este blog.

Las dos opciones pasan por el mismo punto: GA4 necesita saber, para cada visitante y cada conversión, qué variante estaba en juego. De eso trata la próxima sección.

Cómo estructurar eventos personalizados para marcar variante y experimento

La práctica más usada, y recomendada por la propia documentación de integración de experimentos de GA4 para frameworks propios (fuera de una herramienta de test de terceros), es dedicar un evento a la exposición del experimento y llevar en él los parámetros que identifican qué test y qué variante vio el visitante (Google for Developers, “Create an experiment integration with Google Analytics”). Un patrón común:

• Nombre del evento: view_experiment (o experiment_impression, el nombre importa menos que la consistencia).
• Parámetro experiment_id: un identificador estable del test, por ejemplo cta_color_boton_jul26.
• Parámetro variant_id: qué variante vio el visitante, por ejemplo control o variante_b.

Después de disparar el evento con esos parámetros, el paso que se suele olvidar es registrar los parámetros como dimensiones personalizadas en GA4 (Admin, en la sección de definiciones personalizadas). Sin ese paso, el parámetro llega en el evento bruto, pero no aparece como columna disponible en informes y exploraciones.

Dos decisiones de ámbito importan:

• Ámbito de evento: el valor vale solo para ese evento específico. Funciona bien para view_experiment, pero si quieres filtrar el evento purchase por la variante, el parámetro de variante tiene que estar presente también en el evento de compra, o usas el siguiente ámbito.
• Ámbito de usuario: graba la variante como una propiedad del usuario (user property), válida para toda la sesión (y sesiones futuras, si el mismo identificador persiste). Es la forma más robusta de garantizar que el evento purchase, que ocurre minutos o días después de la exposición, todavía lleve la información de qué variante vio ese visitante.

La tabla resume la convención sugerida:

Elemento	Nombre sugerido	Ámbito en GA4	Dónde aparece
Evento de exposición	view_experiment	Evento	Cada vez que se muestra una variante
Parámetro del test	experiment_id	Dimensión personalizada de evento	Informes y exploraciones
Parámetro de la variante	variant_id	Dimensión personalizada de evento	Informes y exploraciones
Propiedad persistente	experiment_bucket	Dimensión personalizada de usuario	Cualquier evento de la misma sesión o usuario, incluido purchase

Si quieres el paso a paso completo de implementación, incluyendo el disparo vía Google Tag Manager y la validación en DebugView, mira la guía dedicada Cómo Rastrear Eventos de Test A/B en GA4, que es el complemento práctico de este pilar.

Un detalle que evita retrabajo: acuerda la convención de nombres antes de que el primer test salga al aire, y documéntala en un lugar visible para todo el equipo (marketing, producto y quien toque el GTM). Los equipos que dejan que cada persona elija su propio nombre de evento o parámetro (exp_view en una campaña, experiment_seen en otra) terminan con dimensiones personalizadas duplicadas e informes que no se hablan entre sí, además de gastar cuota de dimensiones personalizadas en vano.

Los límites reales de GA4 que todo experimentador necesita conocer

Antes de diseñar tu taxonomía de eventos, vale la pena conocer los techos técnicos de GA4, porque cambian con el tiempo y varían entre propiedad estándar (gratuita) y GA4 360 (de pago). Los números de abajo fueron verificados en la documentación oficial de Google Analytics en julio de 2026; como esos límites son actualizados periódicamente por el propio Google, confirma el valor vigente en la fuente antes de planificar algo que dependa de ellos al límite.

Recurso	Propiedad estándar	GA4 360
Dimensiones personalizadas (ámbito de evento)	50	125
Dimensiones personalizadas (ámbito de usuario)	25	100
Dimensiones personalizadas (ámbito de artículo)	10	25
Métricas personalizadas	50	125
Retención de datos de usuario	2 o 14 meses	2 o 14 meses
Retención de datos de evento	2 o 14 meses	2, 14, 26, 38 o 50 meses
Muestreo en Explorations (por consulta)	a partir de ~10 millones de eventos	a partir de ~100 millones (hasta ~1.000 millones)
BigQuery Export diario (lote)	1 millón de eventos/día	20 mil millones de eventos/día

Según la documentación oficial de definiciones personalizadas de Google Analytics, las propiedades estándar tienen 50 dimensiones personalizadas con ámbito de evento, 25 con ámbito de usuario y 10 con ámbito de artículo, más 50 métricas personalizadas, con los techos de las propiedades GA4 360 bastante por encima de eso (Google Analytics Help, “Acerca de las dimensiones y métricas personalizadas”). Esto rara vez es un problema para un programa de tests A/B común, pero los equipos que corren decenas de experimentos simultáneos con muchos parámetros por evento pueden acercarse al límite, sobre todo en el ámbito de usuario.

Sobre la retención: por defecto, GA4 mantiene datos de usuario y de evento por 2 meses. En una propiedad estándar puedes extender eso hasta 14 meses en Admin, en la sección de recopilación y modificación de datos. Las propiedades GA4 360 (de pago) tienen opciones adicionales de 26, 38 y 50 meses para datos de evento (Google Analytics Help, “Acerca de la retención de datos”). Ese ajuste importa especialmente para tests A/B de ciclo largo (por ejemplo, tests que miden retención de suscripción a lo largo de varios meses): si la retención está en el estándar de 2 meses, los datos de exploración más antiguos simplemente desaparecen antes de que consigas analizarlos.

Sobre el muestreo: los informes de exploración de GA4 aplican muestreo cuando una consulta supera la cuota de eventos de la propiedad, cerca de 10 millones de eventos por consulta en propiedades estándar, y una cuota inicial bastante mayor (hasta cerca de 100 millones, con techo de hasta 1.000 millones) en propiedades GA4 360 (Google Analytics Help, “Acerca del muestreo de datos”). Un icono de calidad de datos avisa cuando el resultado que estás viendo está muestreado y qué porcentaje de los datos se usó. Para un test A/B de alto tráfico, eso importa: si estás leyendo la significancia directamente de una Exploration muestreada, el valor p que calcules encima de números ya muestreados carga un error adicional que la calculadora no puede corregir sola.

BigQuery export: la salida para un análisis sin muestreo

La forma más robusta de escapar del muestreo es exportar los eventos brutos de GA4 a BigQuery y correr tú mismo el cálculo estadístico sobre los datos completos, sin pasar por la capa de informes de GA4. La configuración es gratuita para propiedades estándar (Admin, en la sección de integraciones de producto), con una salvedad importante: la exportación diaria en lote tiene un límite de 1 millón de eventos por día; si la propiedad lo supera de forma consistente, Google puede pausar la exportación (Google Analytics Help, “Configurar la exportación de BigQuery”). Los sitios de alto tráfico que necesitan más que eso normalmente migran a la exportación en streaming, que no tiene ese techo, o a una cuenta GA4 360.

Una vez con los eventos brutos en BigQuery, el flujo para validar un test A/B queda así:

1. Filtrar los eventos view_experiment (o el nombre que hayas elegido) por el experiment_id del test en cuestión, separando por variant_id.
2. Contar visitantes únicos por variante (la unidad de aleatorización, normalmente user_pseudo_id).
3. Contar conversiones por variante, cruzando con el evento de conversión relevante (purchase, sign_up, o el key event definido para ese test).
4. Correr el mismo cálculo de dos proporciones que usa una calculadora de significancia estadística (la fórmula del puntaje z para dos proporciones), sea vía SQL en el propio BigQuery, sea exportando los cuatro números (visitantes y conversiones de cada lado) a una calculadora como la de este blog.

Es exactamente ese último paso, los cuatro números saliendo de BigQuery (o incluso de un informe predefinido de GA4, sin muestreo, cuando el volumen es bajo) y entrando en una calculadora de significancia, lo que demuestra en la práctica la sección de ejemplo trabajado de abajo.

Google Tag Manager como capa de disparo

En la práctica, la mayor parte de las implementaciones no escribe el evento view_experiment directamente en el código de la página. Lo dispara Google Tag Manager (GTM), con una etiqueta configurada para leer la variante activa (normalmente expuesta por la herramienta de test A/B como una variable de JavaScript o un data layer push) y enviar eso como evento de GA4, con experiment_id y variant_id como parámetros de la etiqueta.

Esa capa intermedia tiene una ventaja práctica: si cambias de herramienta de test A/B en el futuro, o corres el reparto por tu cuenta vía feature flag, solo necesitas ajustar el activador y la variable dentro de GTM, sin tocar el evento que llega a GA4 ni la taxonomía de dimensiones personalizadas que ya configuraste. La implementación detallada de etiquetas, activadores y variables para ese escenario específico se sale del alcance de este pilar, pero es un tema que merece (y va a tener) una guía dedicada propia en este blog.

Client-side, server-side o etiqueta server-side

El mismo evento view_experiment puede llegar a GA4 por tres caminos distintos, y la elección afecta la confiabilidad del dato, no solo la implementación. Por GTM en el navegador (client-side), la implementación es rápida, pero queda sujeta a bloqueadores de anuncios y a retrasos de carga. Directo desde el backend (server-side), el disparo es más robusto e inmune al bloqueo en el navegador, el estándar recomendado para tests en producto y SaaS. Un contenedor de GTM server-side queda en el medio del camino: centraliza la lógica de disparo en un servidor que tú controlas, reduciendo la dependencia del navegador del visitante sin exigir que cada evento sea escrito a mano en el backend de la aplicación. Ninguna de las tres opciones resuelve la significancia estadística, eso sigue siendo tarea de la calculadora, pero la elección equivocada puede sesgar el conteo de eventos entre variantes antes incluso de que empiece el cálculo.

Cómo atribuir ingresos al ganador de un test en GA4

La pregunta que decide el test rara vez es “qué variante tuvo más clics”, es “qué variante generó más ingresos, o más de las conversiones que pagan la cuenta”. GA4 ya sabe hacer esa cuenta, siempre que el evento de conversión (purchase, con el parámetro value completado, o el key event equivalente para un SaaS) lleve también la dimensión de variante, sea directamente o vía la propiedad de usuario experiment_bucket descrita en la sección de eventos.

Con esa segmentación en la mano, un informe de exploración de embudo (o una tabla libre con la dimensión de variante y la métrica de ingresos) ya muestra, lado a lado, cuánto convirtió cada variante y cuánto facturó cada variante. Es aquí, específicamente, donde GA4 entrega valor que ninguna calculadora sola entrega: el cruce entre variante, etapa del embudo y valor monetario, con toda la segmentación adicional (dispositivo, canal, nuevo x recurrente) que el resto de la herramienta ya ofrece.

Lo que GA4 sigue sin entregar, incluso con los ingresos correctamente segmentados, es la respuesta a “esa diferencia de ingresos es estadísticamente confiable, o se puede explicar por suerte de muestra”. Para eso, los cuatro números del embudo (visitantes y conversiones de cada lado) alimentan la calculadora de significancia, exactamente como en el ejemplo siguiente.

Un ejemplo trabajado: de GA4 a la significancia estadística

Imagina que exportaste de GA4 (de una Exploration de embudo segmentada por la dimensión variant_id, sin muestreo porque el volumen está por debajo del techo de 10 millones de eventos) los siguientes números de un test A/B de checkout:

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

El informe predefinido de GA4 muestra la diferencia bruta: la tasa de conversión de A es 480 ÷ 12.000 = 4,00%, la de B es 540 ÷ 12.000 = 4,50%, una mejora relativa de +12,5%. Hasta aquí es solo aritmética, y es exactamente lo que GA4 ya entrega por sí solo, con un color verde alentador en la variante B. Es también exactamente el punto donde mucha gente celebra demasiado pronto.

Pasando esos mismos cuatro números (visitantes y conversiones de cada lado) por la calculadora de significancia estadística de este blog, que usa el mismo test de dos proporciones descrito en la guía de significancia estadística:

Control (A)

VisitantesConversiones

Variación (B)

VisitantesConversiones

Confianza90%95%99%

Control (A) · Tasa-

Variación (B) · Tasa-

Mejora relativa-

valor-p-

IC 95% de la diferencia-

Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.

El resultado, calculado a partir de esos números: el puntaje z queda en aproximadamente 1,92, lo que da un valor p bilateral de aproximadamente 0,055 (5,5%). Con el corte convencional del 5%, ese test no es estadísticamente significativo, aunque la variante B esté nominalmente por delante. El intervalo de confianza del 95% de la diferencia va de aproximadamente −0,01 punto porcentual a +1,01 punto porcentual, es decir, el intervalo prácticamente toca el cero.

¿Qué hacer con un resultado así? Las opciones honestas son las mismas de cualquier test no concluyente: dejarlo correr más tiempo hasta alcanzar la muestra que la calculadora de tamaño de muestra recomendaría para ese efecto, aceptar que la ganancia real puede ser menor que el 12,5% observado, o tratar el resultado como aprendizaje (el cambio probablemente no es perjudicial, pero todavía no está probado) y testear la próxima hipótesis del backlog. Lo que no es honesto es publicar “aumentamos la conversión en 12,5%” basándose solo en el número que mostró el informe predefinido de GA4, sin esa verificación.

Privacidad y consentimiento: Consent Mode y protección de datos

Todo número que sale de GA4 depende de lo que el visitante consintió compartir. El Consent Mode de Google es la capa que comunica, a las etiquetas de Google (incluido GA4), qué autorizó cada visitante en términos de almacenamiento y uso de datos; cuando el consentimiento es negado, GA4 reduce la recolección y usa modelado estadístico y de comportamiento para rellenar parte del hueco, en lugar de simplemente no registrar nada (Google for Developers, “Consent mode overview”).

Eso tiene dos implicaciones directas para quien lee un resultado de test A/B en GA4:

• El conteo bruto de eventos por variante puede divergir levemente del comportamiento real, sobre todo en mercados o segmentos con alta tasa de rechazo de cookies, porque parte de los números que ves ya pasó por modelado, no son todos observados directamente.
• La implementación del Consent Mode necesita ser consistente entre las variantes. Si la variante B, por ejemplo, cambia la posición del banner de consentimiento (algo común en tests de layout), eso puede alterar la tasa de aceptación de cookies entre A y B, contaminando la comparación con una variable que no tiene nada que ver con la hipótesis original.

En Brasil, la LGPD exige base legal y transparencia para el tratamiento de datos personales, lo que en la práctica se traduce, en la mayoría de los sitios, en obtener consentimiento explícito antes de disparar etiquetas de analytics y publicidad, de forma equivalente a lo que exige el GDPR en Europa (donde el Consent Mode se volvió, desde marzo de 2024, obligatorio para quien usa funciones de anuncios de Google con tráfico del Espacio Económico Europeo). Trata la implementación del consentimiento como parte del diseño del test, no como un detalle de compliance aparte: un test A/B corrido sobre una base de consentimiento inconsistente entre variantes carga un sesgo que ninguna calculadora de significancia consigue corregir después.

Una verificación simple, y barata, resuelve buena parte del riesgo: antes de mirar el resultado del test en sí, compara la tasa de aceptación del banner de consentimiento entre el grupo que vio A y el grupo que vio B. Si las dos tasas son parecidas, el consentimiento no es una variable de confusión relevante para ese test. Si divergen de forma expresiva, vale investigar si algo en la variante (posición del banner, orden de carga de scripts, hasta el color del botón de aceptar) cambió el comportamiento de consentimiento antes de confiar en cualquier diferencia de conversión entre los dos lados.

Los errores más comunes al usar GA4 para decidir un test A/B

Ninguno de los errores de abajo es exótico, y por eso aparecen tanto: cada uno parece un ahorro de tiempo razonable en el día a día, hasta el momento en que la decisión equivocada sale cara (un cambio revertido meses después o, peor, un cambio malo que quedó al aire porque “GA4 mostró que subió”).

Error	Por qué es un problema	Corrección
Confiar solo en la diferencia porcentual del informe predefinido	GA4 muestra la diferencia bruta, no si es estadísticamente confiable	Pasar los números por una calculadora de significancia antes de declarar un ganador
No filtrar el tráfico interno y de bots	Los accesos del propio equipo y el tráfico automatizado distorsionan la tasa de conversión de cada variante, en general de forma desigual	Configurar filtros de datos internos en GA4 y excluir tráfico conocido de bots
Mirar la métrica equivocada (interacción en lugar de negocio)	“Sesiones con interacción” y “tiempo medio de interacción” son útiles, pero rara vez son la métrica que paga la cuenta	Definir la métrica primaria (compra, registro, trial) antes de correr el test, y no cambiarla a mitad de camino
Leer informes muestreados como si fueran exactos	Por encima del techo de eventos por consulta, GA4 muestrea la Exploration y el icono de calidad avisa, pero es fácil ignorarlo	Revisar el icono de muestreo, o exportar a BigQuery cuando el volumen exija precisión total
Olvidar el Consent Mode como variable de confusión	Una diferencia en la tasa de aceptación de cookies entre variantes contamina la comparación	Mantener la implementación de consentimiento idéntica entre control y variación
Analizar sin haber definido la variante como dimensión de usuario	El evento de compra, que ocurre después de la exposición, no lleva la variante si esta solo fue marcada con ámbito de evento	Usar una propiedad de usuario (experiment_bucket) para persistir la variante durante toda la sesión

GA4 solo x GA4 con calculadora: qué resuelve cada uno

Lo que necesitas saber	GA4 solo	GA4 + calculadora o motor estadístico
Cuántos visitantes vieron cada variante	Sí	Sí (misma fuente)
Cuántas conversiones y cuántos ingresos por variante	Sí	Sí (misma fuente)
Si la diferencia es estadísticamente significativa	No	Sí
Intervalo de confianza de la diferencia	No	Sí
Tamaño de muestra necesario para el efecto que quieres detectar	No	Sí
Alerta de muestra insuficiente o peeking	No	Depende de la disciplina de quien analiza, pero la calculadora hace visible el número
Segmentación cruzada (dispositivo, canal, nuevo x recurrente)	Sí	Sí (misma fuente)

La lectura directa de esa tabla es la tesis de toda esta guía: GA4 es insustituible como fuente de datos, y una calculadora estadística (o una herramienta de test que ya incorpore una) es insustituible como capa de decisión. Intentar usar solo uno de los dos deja la mitad del trabajo sin hacer.

Hazlo automático en Donnu

Acabas de ver el trabajo manual que junta GA4 y estadística: estructurar el evento correcto, registrar las dimensiones personalizadas, exportar a BigQuery cuando el volumen lo exige, y solo entonces pasar los números por una calculadora para saber si la diferencia es real. Donnu A/B cierra ese ciclo automáticamente: el snippet reparte y mantiene la variante de cada visitante, la plataforma ya calcula la significancia (con estadística bayesiana honesta) sin que necesites armar la cuenta aparte, y los eventos relevantes siguen disponibles para que los cruces con GA4 y BigQuery cuando quieras la visión completa de ingresos.

Empieza una prueba gratuita de 14 días y deja de decidir tests A/B solo por el color verde del informe de GA4. Si quieres profundizar antes, mira qué es un test A/B desde cero, cómo funciona la significancia estadística detrás de la calculadora, o los errores comunes que invalidan un test A/B, incluidos los que esta guía cubrió en detalle específico para GA4.

Referencias

• Google Analytics Help. Acerca de las dimensiones y métricas personalizadas. support.google.com/analytics/answer/14240153.
• Google Analytics Help. Acerca de la retención de datos. support.google.com/analytics/answer/7667196.
• Google Analytics Help. Acerca del muestreo de datos. support.google.com/analytics/answer/13331292.
• Google Analytics Help. Configurar la exportación de 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.