Tu primera query en BigQuery: un ejercicio guiado

Antes de empezar

Este ejercicio asume que ya se tiene una cuenta de Google Cloud con BigQuery accesible, y que GA4 está conectado con al menos un día de datos exportados. Si los datos propios aún no están disponibles, se puede practicar con el dataset público bigquery-public-data que Google proporciona de forma gratuita a todos los usuarios.

El objetivo del ejercicio es ejecutar cinco consultas de complejidad creciente, cada una construida sobre la anterior. Al terminar, se habrá practicado con las cláusulas fundamentales de SQL: SELECT, FROM, WHERE, GROUP BY y ORDER BY.

Paso 1: Abrir el editor SQL de BigQuery

1. Ir a console.cloud.google.com/bigquery en el navegador.
2. Verificar que el proyecto correcto está seleccionado en la barra superior.
3. En el panel central aparece el editor SQL: un área de texto donde se escribe la consulta, y debajo un área donde aparecerán los resultados después de ejecutarla.
4. En el panel izquierdo (Explorer) se ven los datasets y tablas disponibles. Expandir el proyecto para ver el dataset de GA4 (analytics_XXXXXXXXX). Dentro del dataset, las tablas se nombran events_YYYYMMDD.

Paso 2: La consulta más simple posible

La primera consulta tiene un único objetivo: confirmar que los datos existen y que se puede acceder a ellos. Escribir lo siguiente en el editor (reemplazando el nombre del proyecto y dataset por los reales):

SELECT *
FROM `tu-proyecto.analytics_XXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
LIMIT 10

Hacer clic en el botón Run (o presionar Ctrl+Enter en Windows / Cmd+Enter en Mac).

Esta consulta dice: «muestra las primeras 10 filas de la tabla de eventos de ayer». El SELECT * pide todas las columnas, LIMIT 10 restringe a 10 filas para no cargar demasiados datos, y el filtro _TABLE_SUFFIX selecciona solo la tabla del día anterior.

Si aparecen filas con datos (event_date, event_name, user_pseudo_id, etc.), la conexión funciona. Los datos están ahí y se pueden consultar.

Paso 3: Seleccionar columnas específicas

El SELECT * es útil para explorar la estructura de una tabla, pero no es práctico para análisis reales. Las tablas de GA4 tienen muchas columnas (algunas con estructuras anidadas complejas), y la mayoría no se necesitan para una consulta específica. La siguiente query selecciona solo lo relevante:

SELECT
  event_date,
  event_name,
  traffic_source.medium AS medio,
  device.category AS dispositivo
FROM
  `tu-proyecto.analytics_XXXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
LIMIT 20

Ahora se ven solo cuatro columnas: fecha del evento, nombre del evento, medio de adquisición y tipo de dispositivo. El resultado es mucho más legible y fácil de interpretar. La notación traffic_source.medium accede al campo medium dentro del registro anidado traffic_source. El AS renombra la columna para que aparezca como «medio» en los resultados.

Paso 4: Filtrar datos

Para enfocarse solo en el tráfico orgánico, se añade una condición al WHERE:

SELECT
  event_date,
  event_name,
  device.category AS dispositivo
FROM
  `tu-proyecto.analytics_XXXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
  AND traffic_source.medium = 'organic'
LIMIT 20

El AND agrega una segunda condición: solo eventos de usuarios cuyo medio de adquisición es orgánico. Ahora los resultados muestran exclusivamente tráfico SEO. Si se quisiera ver también el tráfico de referral, se usaría OR: AND (traffic_source.medium = 'organic' OR traffic_source.medium = 'referral').

Paso 5: Contar y agrupar

Aquí es donde SQL empieza a ser realmente útil para análisis. En lugar de ver filas individuales (un evento por fila), se pueden agregar datos para obtener resúmenes. Esta consulta cuenta cuántos eventos de cada tipo ocurrieron en tráfico orgánico ayer:

SELECT
  event_name,
  COUNT(*) AS total
FROM
  `tu-proyecto.analytics_XXXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
  AND traffic_source.medium = 'organic'
GROUP BY
  event_name
ORDER BY
  total DESC

COUNT(*) cuenta filas. GROUP BY event_name agrupa por tipo de evento (todos los page_view juntos, todos los session_start juntos, etc.). ORDER BY total DESC ordena de mayor a menor. El resultado muestra un resumen claro: cuántos page_views, session_starts, scrolls y otros eventos ocurrieron en tráfico orgánico ayer.

Paso 6: Una consulta real de SEO

Para terminar el ejercicio con algo directamente útil para el trabajo de SEO, esta consulta muestra las sesiones orgánicas por día en la última semana:

SELECT
  PARSE_DATE('%Y%m%d', event_date) AS fecha,
  COUNT(
    DISTINCT CONCAT(
      user_pseudo_id, '.',
      CAST(
        (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
      AS STRING)
    )
  ) AS sesiones
FROM
  `tu-proyecto.analytics_XXXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY))
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  AND traffic_source.medium = 'organic'
GROUP BY
  fecha
ORDER BY
  fecha ASC

Esta es una versión simplificada de la query de sesiones orgánicas diarias del catálogo. La sintaxis de UNNEST(event_params) puede parecer compleja al principio: es la forma que tiene BigQuery de acceder a los parámetros anidados dentro de cada evento (como el ID de sesión, la URL de la página o el tiempo de engagement). Con la práctica, esta sintaxis se convierte en algo rutinario que se copia y adapta.

Interpretación de los resultados

BigQuery muestra los resultados en forma de tabla debajo del editor. Además de los datos, hay información adicional importante que aparece después de ejecutar cada query:

• Tiempo de ejecución: cuántos segundos tardó la consulta en procesarse. Las consultas típicas de SEO tardan entre 1 y 10 segundos.
• Bytes procesados: cuántos datos se leyeron del almacenamiento. Esto es lo que cuenta para la cuota gratuita de 1 TB/mes. BigQuery muestra una estimación antes de ejecutar la query (visible en la esquina superior derecha del editor) para saber cuánto consumirá.
• Filas devueltas: cuántos resultados tiene la tabla de respuesta.

Es buena práctica revisar los bytes procesados antes de ejecutar una query, especialmente si se trabaja sin filtro de fecha. Una consulta sin _TABLE_SUFFIX ni filtro de fecha puede procesar meses o años de datos de golpe, consumiendo cuota innecesariamente.

Siguiente paso

Con esta primera experiencia práctica, el siguiente paso es explorar el catálogo de queries de Queryteca y empezar a copiar y adaptar consultas reales a datos propios. Cada query del catálogo incluye una explicación línea por línea que facilita la comprensión. Para quienes prefieren practicar sin usar datos propios todavía, el artículo sobre herramientas gratuitas para practicar SQL ofrece alternativas que no requieren datos de producción.