Versionado de queries: cómo guardarlas y reutilizarlas

Las queries son activos de trabajo

Una query SQL que ha tomado tiempo desarrollar y depurar tiene valor. Si se pierde o se olvida, hay que invertir ese tiempo de nuevo. A medida que se acumula experiencia, la biblioteca de queries personales se convierte en una herramienta de productividad: en lugar de escribir cada análisis desde cero, se adaptan queries existentes.

El problema es que muchos profesionales de SEO escriben queries directamente en el editor de BigQuery, ejecutan, copian el resultado a una hoja de cálculo, y cierran la pestaña. Semanas después, necesitan la misma query y no la encuentran.

Opción 1: Saved Queries en BigQuery

BigQuery tiene una funcionalidad nativa de queries guardadas. Al escribir una consulta en el editor, se puede guardar con un nombre descriptivo:

1. Escribir la query en el editor de BigQuery.
2. Hacer clic en «Save» > «Save query» en la barra superior.
3. Asignar un nombre descriptivo (ej: «GSC: Top keywords por clics – 28 días»).
4. Las queries guardadas aparecen en el panel izquierdo bajo «Saved queries».

Esta opción es la más simple y no requiere herramientas adicionales. La limitación es que las queries solo están disponibles en la cuenta de Google Cloud del usuario, y no hay un sistema de versiones (no se puede ver el historial de cambios).

Opción 2: archivos .sql en una carpeta local

Un enfoque sencillo y efectivo: guardar cada query como un archivo .sql en una carpeta del sistema de archivos, con una estructura organizada por tema:

-- Estructura de carpetas sugerida
queries-seo/
├── ga4/
│   ├── sesiones-organicas-diarias.sql
│   ├── engagement-rate-landing.sql
│   └── funnel-conversion-organico.sql
├── gsc/
│   ├── top-keywords-clics.sql
│   ├── canibalizacion-keywords.sql
│   └── keywords-posicion-4-10.sql
├── cruce-ga4-gsc/
│   ├── keywords-que-convierten.sql
│   └── paginas-zombi.sql
└── looker-studio/
    └── custom-query-mensual.sql

Cada archivo .sql contiene la query completa con un comentario en las primeras líneas que describe qué hace, qué fuente usa y para qué periodo está configurada. Los archivos se pueden abrir con cualquier editor de texto (VS Code, Sublime Text, Notepad++) que ofrezca syntax highlighting para SQL.

Opción 3: repositorio Git

Para quienes trabajan en equipo o quieren un historial de cambios completo, un repositorio Git (en GitHub, GitLab o Bitbucket) es la opción más robusta:

• Cada cambio queda registrado con fecha, autor y mensaje descriptivo.
• Es posible comparar versiones de una query para ver qué cambió.
• Varios miembros del equipo pueden contribuir y revisar queries.
• Se integra con herramientas de documentación y CI/CD.

No hace falta ser experto en Git para usarlo. Herramientas como GitHub Desktop o la integración Git de VS Code simplifican la gestión de versiones sin necesidad de usar la línea de comandos.

Opción 4: Google Sheets como catálogo

Una hoja de cálculo puede funcionar como catálogo indexado de queries, con columnas para nombre, descripción, fuente de datos, frecuencia de uso y la query misma. Es útil cuando el equipo no usa Git y necesita un lugar centralizado accesible desde el navegador.

La limitación es que las hojas de cálculo no ofrecen syntax highlighting para SQL, lo que hace las queries más difíciles de leer. Funciona mejor como índice que apunta a queries guardadas en BigQuery o en archivos .sql.

Buenas prácticas de organización

Nombrar de forma descriptiva

El nombre de la query (sea un archivo, una saved query o una entrada en un catálogo) debe indicar qué hace sin necesidad de abrirla:

• Bien: gsc-keywords-posicion-4-10-oportunidades.sql
• Mal: query-nueva.sql, test3.sql, final-final.sql

Incluir un encabezado en cada query

-- Nombre: Top keywords en posiciones 4-10
-- Fuente: GSC (searchdata_url_impression)
-- Periodo: últimos 28 días
-- Descripción: Keywords con posición media entre 4 y 10
--   que son candidatas a subir al top 3 con optimización.
-- Última modificación: 2026-04-15

SELECT ...

El encabezado funciona como documentación integrada. Cuando se abre la query meses después, el contexto está inmediatamente disponible.

Parametrizar lo que cambia

Si una query se usa con diferentes rangos de fecha o diferentes filtros, conviene dejar los valores variables bien señalizados con comentarios:

WHERE
  _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))  -- Cambiar 30 por el periodo deseado
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  AND traffic_source.medium = 'organic'  -- Cambiar por otro medio si es necesario

Cuándo revisar y actualizar queries guardadas

Las queries no son estáticas. Los esquemas de las tablas de GA4 y GSC pueden cambiar con actualizaciones del producto, y las necesidades de análisis evolucionan con el tiempo. Es recomendable revisar la biblioteca de queries al menos una vez por trimestre para verificar que siguen funcionando correctamente y que los resultados que devuelven continúan siendo relevantes para las decisiones del equipo.

El catálogo de Queryteca como punto de partida

El catálogo de Queryteca funciona como una biblioteca de referencia: 50 queries documentadas, explicadas y listas para copiar. La recomendación es usarlo como base, adaptar las queries a los datos propios (cambiando el nombre del proyecto y dataset), y guardar las versiones adaptadas en la biblioteca personal usando cualquiera de los métodos descritos.

El siguiente artículo aborda un tema que muchos pasan por alto: cuándo NO usar SQL, porque a veces la herramienta correcta es una hoja de cálculo.