Errores comunes al usar SQL para SEO (y cómo evitarlos)

Errores que cuestan tiempo y cuota

Aprender SQL implica cometer errores. La buena noticia es que en consultas SELECT (las que se usan para análisis SEO), los errores nunca borran ni modifican datos. Lo peor que puede ocurrir es obtener un resultado incorrecto, un error de sintaxis, o consumir más cuota de BigQuery de la necesaria.

Este artículo complementa la sección de errores comunes en los fundamentos con un enfoque más práctico y casos reales encontrados en análisis SEO.

Error 1: olvidar el filtro de fecha en GA4

El error más costoso. Sin _TABLE_SUFFIX, una query sobre las tablas de GA4 escanea todo el historial del dataset. En un sitio con un año de datos, esto puede consumir 50-100 GB de cuota en una sola ejecución, frente a 2-5 GB con el filtro correcto.

-- Siempre incluir el filtro de fecha
WHERE _TABLE_SUFFIX BETWEEN
  FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
  AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())

Revisar siempre la estimación de bytes en la esquina superior derecha del editor de BigQuery antes de ejecutar. Si el número parece desproporcionado (más de 20 GB para un análisis de 30 días), probablemente falta el filtro.

Error 2: posición media de GSC mal calculada

Este error es sutil porque no produce un mensaje de error, sino resultados incorrectos. La fórmula correcta para la posición media en el export de GSC a BigQuery requiere un ajuste porque las posiciones son 0-indexed:

-- Incorrecto: no ajusta el 0-indexing
SUM(sum_top_position) / SUM(impressions)

-- Correcto: convierte de 0-indexed a 1-indexed
SUM(sum_top_position + impressions) / SUM(impressions)

La diferencia es de exactamente 1 posición: la fórmula incorrecta muestra posición 3.2 cuando la real (la que muestra GSC) es 4.2. Parece menor, pero acumula impacto en análisis de oportunidades por posición.

Error 3: no normalizar URLs al cruzar fuentes

GSC almacena URLs limpias (https://ejemplo.com/pagina). GA4 almacena la URL completa incluyendo query strings (https://ejemplo.com/pagina?utm_source=twitter). Sin normalización, el JOIN falla silenciosamente:

-- Normalizar page_location de GA4 antes del JOIN
REGEXP_EXTRACT(page_location, r'(https?://[^?#]+)') AS url_normalizada

Un JOIN que devuelve menos filas de las esperadas suele ser síntoma de este problema. Si el cruce entre GSC y GA4 devuelve solo el 30% de las URLs esperadas, lo primero a verificar es la normalización.

Error 4: confundir traffic_source con fuente de sesión

El campo traffic_source en GA4 registra la fuente de la primera visita del usuario (first-touch), no la fuente de la sesión actual. Un usuario que llegó por orgánico la primera vez tendrá traffic_source.medium = 'organic' en todos sus eventos posteriores, incluso si la sesión actual es directa.

Para análisis donde la atribución a nivel de sesión importa (como calcular conversiones por canal para la sesión actual), conviene usar collected_traffic_source o los parámetros de sesión. Un truco útil para verificar cuál campo usar es ejecutar una query exploratoria que compare ambos campos para el mismo usuario y sesión. Si los valores difieren, significa que el usuario llegó por un canal diferente al de su primera visita, y la elección del campo afecta directamente los números del reporte.

Error 5: SELECT * en consultas de producción

BigQuery es un almacén columnar: cobra por las columnas leídas, no por las filas. La tabla de eventos de GA4 tiene columnas pesadas como event_params (un array de registros anidados). Un SELECT * lee todas las columnas, multiplicando el consumo de cuota por 5-10x respecto a seleccionar solo las columnas necesarias.

SELECT * es aceptable para exploración rápida con LIMIT 10. Para queries que se van a ejecutar regularmente, siempre especificar las columnas exactas que se necesitan.

Error 6: no usar SAFE_DIVIDE

En datos de SEO siempre hay divisores potencialmente cero (keywords sin impresiones, páginas sin sesiones). Una división normal produce un error que detiene toda la consulta. SAFE_DIVIDE devuelve NULL en lugar de error:

-- En lugar de: SUM(clicks) / SUM(impressions)
SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr

Error 7: esperar datos completos el mismo día

La exportación diaria de GA4 a BigQuery se completa al día siguiente. Consultar la tabla del día actual (_TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', CURRENT_DATE())) puede devolver datos parciales o una tabla vacía. Siempre usar DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) como fecha más reciente.

Cómo prevenir errores

• Empezar con queries del catálogo de Queryteca que ya están verificadas, y adaptarlas.
• Revisar la estimación de bytes antes de ejecutar.
• Usar CTEs para dividir queries complejas en pasos verificables.
• Ejecutar cada CTE por separado para verificar resultados intermedios.
• Estructurar las queries con formato claro y comentarios.

Los errores son parte del aprendizaje. Lo importante es reconocerlos rápido y saber dónde buscar la solución. Las buenas prácticas de la sección Fundamentos cubren estos temas en mayor profundidad.

Una estrategia adicional para prevenir errores es crear una query plantilla (template) con los filtros de fecha y las configuraciones de tabla ya incluidas. Al empezar un análisis nuevo, se copia la plantilla en lugar de escribir desde cero, lo que garantiza que los filtros esenciales (como _TABLE_SUFFIX y la normalización de URLs) estén siempre presentes. Con el tiempo, esta práctica reduce significativamente la frecuencia de errores recurrentes.