GA4 sin muestreo con BigQuery: guía para eCommerce

Si gestionas un eCommerce, hay un punto en el que GA4 deja de ser “tu fuente de verdad” y pasa a ser “una vista aproximada”. En los primeros 3 segundos te lo resumo: si hay muestreo, límites o datos agregados, tus decisiones de presupuesto, SEO y pricing se apoyan en una foto borrosa. A 24 de agosto de 2026, entre privacidad, modelados y restricciones de interfaz, depender solo de reportes estándar es arriesgado.

La salida más sólida (y la que usan equipos de performance maduros) es GA4 + BigQuery: exportas el raw-ish de eventos, lo transformas a tu modelo de negocio y creas informes sin muestreo para: ventas reales por canal, rendimiento SEO por landing y categoría, ROAS con lógica de atribución propia, LTV por cohortes y, si conectas costes/márgenes, beneficio en lugar de solo ingresos.

En esta guía verás el paso a paso, consultas clave y una checklist final para implementarlo sin bloquear al equipo. Si quieres que lo montemos extremo a extremo (tracking + BigQuery + dashboards + automatización), puedes ver cómo trabajamos en nuestro método de implementación o pedir ayuda desde el formulario de contacto.

1. Por qué BigQuery: adiós muestreo y datos incompletos

GA4 está pensado para ser “analítica de producto + marketing” con una interfaz rápida. El problema: en eCommerce serio necesitas granularidad, reproducibilidad y control. BigQuery te lo da porque se convierte en tu capa de datos consultable, versionable y auditable.

¿Qué mejoras consigues al exportar GA4 a BigQuery?

• Menos dependencia de la interfaz: puedes recrear métricas y dimensiones sin estar atado a exploraciones, límites y combinaciones imposibles.
• Consultas sin muestreo (en el sentido práctico): trabajas con tablas de eventos exportados y haces agregaciones tú. En análisis avanzados, esto evita conclusiones basadas en muestras o recortes.
• Unión con otras fuentes: costes de Ads, catálogo (margen por SKU), CRM/ERP (devoluciones, estados), herramientas de emailing, etc.
• Lógica de negocio real: “compra válida” no siempre es cualquier purchase; puedes excluir cancelaciones, aplicar reglas por marketplace, agrupar por familias, etc.
• Escalabilidad: a medida que crecen sesiones y eventos, tu modelo puede crecer con particiones, tablas incrementales y materializaciones.

Qué “problemas” típicos resuelve en eCommerce:

• Necesitas saber qué landings SEO generan ventas, no solo tráfico (y segmentar por categoría, marca, precio).
• Quieres medir ROAS por campaña con una ventana y una atribución coherente para tu negocio.
• El equipo de finanzas pide margen y devoluciones: GA4 no “sabe” tu margen por SKU ni tu refund real si no lo conectas.
• Quieres LTV por cohortes (primera compra) y diferenciar cliente nuevo vs recurrente con criterio propio.

BigQuery no sustituye GA4: lo complementa. GA4 sigue siendo útil para exploración rápida, audiencias, debugging básico y activaciones. Pero la capa “decisión” (dashboards de negocio y análisis) es más robusta con datos en BigQuery.

Si además estás mejorando la base técnica de la tienda (rendimiento, medición, CRO), te interesa un enfoque integral. En servicios para eCommerce solemos combinar analítica, automatización y SEO para que el dato sirva para crecer, no para “mirarlo”.

2. Conectar GA4 a BigQuery (paso a paso y requisitos)

La conexión GA4 → BigQuery es relativamente directa, pero conviene hacerla con orden para evitar datasets “sucios” o que luego sean difíciles de mantener. La idea: crear un proyecto en Google Cloud, vincularlo a tu propiedad GA4 y validar que los eventos críticos del eCommerce se exportan bien.

Requisitos previos (check rápido):

• Acceso de administrador a la propiedad GA4.
• Acceso a un proyecto de Google Cloud (o capacidad de crear uno).
• Permisos en BigQuery (mínimo para crear dataset y consultar).
• Tracking eCommerce bien implementado (al menos view_item, add_to_cart, begin_checkout, purchase; idealmente también refund si aplica).

Paso a paso para vincular GA4 con BigQuery:

1. Crea o selecciona el proyecto en Google Cloud donde vivirá BigQuery. Recomendación: un proyecto por compañía o por entorno (prod/BI), con naming claro.
2. En BigQuery, crea un dataset (por ejemplo: ga4_export) con ubicación acorde a tu compliance (EU/US) y políticas internas.
3. En GA4, ve a Admin → Product links → BigQuery links (nombre puede variar según idioma) y pulsa “Link”.
4. Selecciona el proyecto y configura la exportación. Normalmente tendrás:
   • Daily export (recomendado siempre).
   • Streaming export (si necesitas casi tiempo real para alertas/stock/operaciones; evalúa coste/beneficio).
5. Valida tablas: se crearán tablas particionadas por fecha del estilo events_YYYYMMDD (y/o intraday si aplica).
6. Valida eventos: confirma que aparecen purchase y que vienen con los parámetros esperados (transaction_id, value, currency, items…).

Recomendaciones técnicas (para no sufrir después):

• Documenta el tracking: qué parámetros enviáis, en qué eventos y con qué formato (sobre todo IDs, monedas, impuestos, shipping, descuentos).
• Normaliza identificadores: define un estándar para user_id (si aplica), transaction_id, SKU y variantes. Evita que cambien según canal.
• Control de calidad: crea una consulta diaria de “sanidad” (compras, ingresos, tasa de items nulos, duplicados por transaction_id).
• Costes: BigQuery cobra por almacenamiento y por datos procesados en consultas. Usa particiones, evita SELECT * y crea tablas intermedias materializadas para dashboards.

Si tu web necesita ajustes de medición o rendimiento (muy típico cuando el tracking se rompe por scripts, consentimiento o cambios de plantilla), en optimización web y analítica trabajamos la parte técnica para que los datos que lleguen a BigQuery sean fiables.

3. Consultas clave para eCommerce (ventas, SEO, Ads, LTV)

El “superpoder” de GA4 en BigQuery es que puedes definir tus KPIs con SQL. Aquí tienes consultas tipo (plantillas) que sirven como base. Nota: el esquema exacto puede variar (y conviene adaptarlo a tu implementación). La idea es que veas la estructura: filtrar por evento, extraer parámetros y construir tablas de hechos (ventas) + dimensiones (canal, landing, producto).

3.1 Ventas (purchases) por día y canal

-- Ventas diarias por canal (default channel group) a partir de purchase
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  traffic_source.source AS source,
  traffic_source.medium AS medium,
  traffic_source.name AS campaign,
  COUNTIF(event_name = 'purchase') AS purchases,
  SUM((SELECT ep.value.double_value FROM UNNEST(event_params) ep WHERE ep.key='value')) AS revenue
FROM `PROJECT.DATASET.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
  AND event_name = 'purchase'
GROUP BY 1,2,3,4
ORDER BY date ASC;

Qué revisar: que value exista y sea numérico, que la moneda sea consistente y que no tengas duplicados por transaction_id. En eCommerce, un “error silencioso” es medir compras duplicadas por reintentos de pago o por eventos disparados dos veces.

3.2 SEO: ventas por landing page (atribución “última no directa” simplificada)

En SEO solemos querer: “qué URLs atraen usuarios que compran” y “qué categorías sostienen ingresos orgánicos”. La atribución real puede ser compleja; como punto de partida, analiza sesiones cuyo primer touch/landing coincide con una URL.

-- Ventas atribuidas a la landing del usuario (modelo simple)
WITH purchases AS (
  SELECT
    user_pseudo_id,
    (SELECT ep.value.string_value FROM UNNEST(event_params) ep WHERE ep.key='page_location') AS page_location,
    (SELECT ep.value.double_value FROM UNNEST(event_params) ep WHERE ep.key='value') AS revenue,
    traffic_source.source AS source,
    traffic_source.medium AS medium,
    event_timestamp
  FROM `PROJECT.DATASET.events_*`
  WHERE event_name='purchase'
),
landing AS (
  SELECT
    user_pseudo_id,
    (SELECT ep.value.string_value FROM UNNEST(event_params) ep WHERE ep.key='page_location') AS landing_page,
    MIN(event_timestamp) AS first_ts
  FROM `PROJECT.DATASET.events_*`
  WHERE event_name='page_view'
  GROUP BY 1,2
)
SELECT
  l.landing_page,
  COUNT(*) AS purchases,
  SUM(p.revenue) AS revenue
FROM purchases p
JOIN landing l
  ON p.user_pseudo_id = l.user_pseudo_id
WHERE p.medium = 'organic'
GROUP BY 1
ORDER BY revenue DESC
LIMIT 100;

Consejo: para hacerlo bien, deberías construir un modelo de sesión (con ga_session_id) y asociar la primera page_view de la sesión que originó la compra. Esta plantilla es intencionalmente simple para que puedas empezar y evolucionar.

3.3 Ads: ROAS con coste externo

GA4 te da ingresos/atribución; el coste suele venir de Google Ads, Meta o una tabla propia. El patrón típico es: crear una tabla de costes diaria por campaña y unirla por fecha + campaign/source.

-- Ejemplo de unión con una tabla de costes (costs_daily)
-- costs_daily: date, source, campaign, cost
WITH rev AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS date,
    traffic_source.source AS source,
    traffic_source.name AS campaign,
    SUM((SELECT ep.value.double_value FROM UNNEST(event_params) ep WHERE ep.key='value')) AS revenue
  FROM `PROJECT.DATASET.events_*`
  WHERE event_name='purchase'
  GROUP BY 1,2,3
)
SELECT
  r.date,
  r.source,
  r.campaign,
  r.revenue,
  c.cost,
  SAFE_DIVIDE(r.revenue, c.cost) AS roas
FROM rev r
LEFT JOIN `PROJECT.BI.costs_daily` c
  ON r.date = c.date AND r.source = c.source AND r.campaign = c.campaign
ORDER BY r.date DESC;

3.4 LTV por cohorte (primer pedido)

LTV útil = ingresos acumulados por cliente en ventanas (30/60/90/180 días) desde su primera compra. Esto te permite decidir CAC objetivo, pujas, y priorización de categorías. Aquí un enfoque base por usuario (idealmente usarías user_id si está disponible y es estable).

-- Cohortes por fecha de primera compra y revenue a 30 días
WITH purchases AS (
  SELECT
    user_pseudo_id,
    PARSE_DATE('%Y%m%d', event_date) AS date,
    (SELECT ep.value.double_value FROM UNNEST(event_params) ep WHERE ep.key='value') AS revenue
  FROM `PROJECT.DATASET.events_*`
  WHERE event_name='purchase'
),
first_purchase AS (
  SELECT
    user_pseudo_id,
    MIN(date) AS cohort_date
  FROM purchases
  GROUP BY 1
)
SELECT
  fp.cohort_date,
  COUNT(DISTINCT fp.user_pseudo_id) AS customers,
  SUM(CASE WHEN p.date BETWEEN fp.cohort_date AND DATE_ADD(fp.cohort_date, INTERVAL 30 DAY)
           THEN p.revenue ELSE 0 END) AS revenue_30d,
  SAFE_DIVIDE(
    SUM(CASE WHEN p.date BETWEEN fp.cohort_date AND DATE_ADD(fp.cohort_date, INTERVAL 30 DAY)
             THEN p.revenue ELSE 0 END),
    COUNT(DISTINCT fp.user_pseudo_id)
  ) AS ltv_30d
FROM first_purchase fp
LEFT JOIN purchases p
  ON p.user_pseudo_id = fp.user_pseudo_id
GROUP BY 1
ORDER BY fp.cohort_date DESC;

Extensión (recomendada): añade margen por SKU y devoluciones. Para eso necesitas unir la tabla de items del evento purchase con tu catálogo (SKU → margen) y con ERP/CRM (refunds/cancelaciones). Así pasas de “revenue LTV” a profit LTV, que es lo que realmente escala.

Cuando estos bloques están listos, el siguiente paso es empaquetarlos en un modelo (tablas “hechos” y “dimensiones”) y construir dashboards. Si buscas ayuda para automatizarlo (actualizaciones, alertas, reporting), puedes verlo en SEOAGIL, donde combinamos datos + SEO + automatización para eCommerce.

4. Conclusión: dashboard y próximos pasos para escalar

Con GA4 conectado a BigQuery, el objetivo no es “tener datos” sino tener decisiones. El camino más eficiente es: (1) asegurar tracking, (2) exportar y validar, (3) crear 3–5 tablas base, (4) dashboard operativo y (5) automatizaciones y alertas.

Cómo debería ser tu primer dashboard (mínimo viable) para eCommerce:

• Ventas: ingresos, pedidos, AOV, tasa de conversión (si la calculas a tu manera), split por canal.
• SEO: landings por ingresos orgánicos, categorías, queries (si conectas Search Console en otro dataset) y tendencia semanal.
• Ads: coste, ingresos atribuidos, ROAS, CAC (si tienes clientes nuevos), y alertas de desviación.
• Cliente: cohortes y LTV 30/60/90 días; nuevo vs recurrente.
• Producto: top SKUs por ingresos y (cuando puedas) por margen; stock-outs si conectas inventario.

Checklist práctica (implementación en 7–14 días):

• ☐ Confirmar eventos eCommerce (purchase con transaction_id, value, currency e items completos).
• ☐ Crear proyecto GCP + dataset BigQuery con ubicación correcta.
• ☐ Vincular GA4 → BigQuery (daily export) y verificar tablas events_YYYYMMDD.
• ☐ Crear query de control de calidad: duplicados por transaction_id, revenue nulo, currency inconsistente.
• ☐ Construir tabla “fact_purchases” (compras deduplicadas) y tabla “dim_traffic” (source/medium/campaign).
• ☐ Crear informes base: ventas por canal, SEO por landing, ROAS con costes.
• ☐ Definir cohortes y LTV (al menos 30 días) y validarlo con negocio.
• ☐ Montar dashboard y programar refresco.

Errores comunes (y cómo evitarlos):

• Conectar BigQuery “y ya”: sin queries de sanidad, no detectas duplicados o compras sin items.
• No deduplicar purchases: si un evento se dispara dos veces, tu revenue se infla y te crees más rentable.
• Mezclar entornos (staging y producción): filtra por hostname o usa propiedades separadas.
• No estandarizar UTM/campaign naming: luego es imposible cruzar costes y atribución con coherencia.
• Dashboards que consultan raw events cada vez: caro y lento. Mejor tablas intermedias agregadas.

Si estás en la fase de escalar (más inversión, más catálogo, más países), BigQuery te permite además incorporar modelos de atribución propios, detección de anomalías y segmentación avanzada para personalización. Y, en contexto 2026, también te ayuda a alimentar procesos de IA internos (resúmenes, forecasting, análisis de cohorts) sin depender de exports manuales.

Preguntas frecuentes

¿GA4 “sin muestreo” con BigQuery significa que siempre tengo el 100% de los datos?

Significa que dejas de depender de los límites y agregaciones de la interfaz de GA4 y trabajas con la exportación de eventos en BigQuery para calcular tus métricas. Aun así, la calidad final depende del tracking (consentimiento, ad blockers, implementación) y de cómo deduplicas/transformas.

¿Necesito streaming export o con el daily export es suficiente?

Para la mayoría de eCommerce, daily export es suficiente para reporting y decisiones. Streaming tiene sentido si necesitas casi tiempo real (alertas operativas, fraude, monitorización de checkout) y aceptas el coste y complejidad extra.

¿Qué es lo primero que debería construir en BigQuery para eCommerce?

Una tabla de compras deduplicadas (por transaction_id) con revenue, items, canal/campaign y fecha. Con eso puedes sacar ventas por canal, por producto y por landing, que suele ser lo más accionable.

¿Puedo calcular margen y beneficio en estos informes?

Sí, pero GA4 no lo trae por defecto. Necesitas una tabla de catálogo/ERP con coste o margen por SKU y unirla a los items de purchase. Si además incorporas devoluciones/cancelaciones, tendrás beneficio neto más realista.

¿Esto ayuda al SEO y a aparecer en resultados con IA?

Indirectamente sí: al medir mejor qué landings y categorías generan ingresos, priorizas contenidos y mejoras técnicas con impacto real (no solo tráfico). Además, puedes crear insights y resúmenes internos que aceleren decisiones de contenido y optimización, alineados con cómo los motores con IA sintetizan señales de utilidad.