Cómo configurar la exportación de datos de GSC a BigQuery paso a paso

En febrero de 2023, Google nos dio una alegría: permitía la exportación masiva de datos brutos de Google Search Console (GSC) directamente a BigQuery. Esto es un antes y un después para el SEO, ya que por fin tenemos la propiedad de nuestros datos sin las limitaciones de la API (adiós a muestreos y datos anonimizados). Sí, BigQuery es de pago, pero con una buena estrategia, los costes pueden ser mínimos para la mayoría de proyectos e incluso para proyectos pequeños, totalmente gratuita.

La clave está en no conectar Looker Studio directamente a los datos en bruto de BigQuery. Es un error que puede salirte caro y ralentizar tus informes.

En su lugar, debemos transformar esos datos brutos en "datos finales" optimizados para el reporting a través de la creación de tablas específicas en BigQuery que solo contengan las métricas y dimensiones que realmente necesitamos.

Para ello, herramientas como Dataform son tus aliadas. Permiten crear flujos de trabajo SQL automatizados para transformar y particionar tus datos por fecha. Así, las consultas son mucho más rápidas y baratas, ya que solo procesas lo estrictamente necesario. Adoptar estas prácticas no solo te ahorrará dinero, sino que te dará el poder de desatar todo el potencial de tus datos de GSC para análisis y decisiones SEO mucho más certeras.

Cómo configurar la exportación de datos de GSC a BigQuery paso a paso

Vamos a desglosar los pasos para que puedas configurar la exportación de tus datos de Google Search Console a BigQuery como un auténtico profesional del SEO.

1. Activar la exportación masiva en GSC

Lo primero es lo primero: necesitas activar esta opción dentro de Google Search Console. Aunque la mayoría ya lo habrá hecho, si eres nuevo en esto o no lo has configurado aún, sigue estos pasos:

• Accede a GSC y selecciona la propiedad: Entra en tu cuenta de Google Search Console y elige la propiedad web que quieres conectar con BigQuery.

• Ve a los ajustes: En el menú lateral izquierdo, busca y haz clic en "Ajustes".

  

• Exportación de datos de BigQuery: Dentro de la configuración, verás una sección llamada "Exportación de datos de BigQuery". Haz clic en ella.

  

• Vincula tu proyecto de Google Cloud: Aquí se te pedirá que selecciones un proyecto de Google Cloud existente o que crees uno nuevo. Es importante que tengas los permisos adecuados en Google Cloud para poder realizar esta vinculación.

• Elige el conjunto de datos (dataset): Una vez vinculado el proyecto, se te pedirá que selecciones o crees un conjunto de datos (dataset) en BigQuery donde se almacenarán tus datos de GSC. Por defecto, suele llamarse searchconsole, pero puedes personalizarlo.

  

• Confirma la configuración: Revisa los detalles y confirma la exportación. A partir de este momento, tus datos de GSC comenzarán a exportarse diariamente a la tabla de BigQuery que has especificado.

Puntos clave a tener en cuenta en esta fase:

• Datos históricos: La exportación no incluye datos históricos. Empezarás a recopilar datos desde el día en que actives la exportación. No hay forma de recuperar datos de fechas anteriores a la activación.

• No necesitas usar BigQuery directamente: Aunque los datos pasan por BigQuery, si tu equipo de datos utiliza otro datawarehouse o almacén en la nube (como Snowflake o Redshift), pueden configurar una transferencia de datos desde BigQuery hacia ese otro sistema.

2. Entendiendo las tablas generadas

Una vez activada la exportación, BigQuery generará dos tablas principales en el conjunto de datos que hayas seleccionado. La estructura será similar a la que vemos en la siguiente imagen.

• searchdata_site_impression: Esta tabla contiene los datos de GSC agregados por propiedad. Es muy similar a lo que ya conoces de la API de GSC, pero con una ventaja crucial: incluye datos de consultas anonimizadas. Esto significa que tendrás filas donde el campo query estará vacío, pero el resto de los datos (clics, impresiones, etc.) estarán presentes, dándote una visión más completa.

• searchdata_url_impression: Esta tabla contiene los datos de GSC agregados por URL. Además de los campos de la tabla anterior, añade el campo url y campos booleanos como is_amp_top_stories para indicar el tipo de apariencia en la búsqueda. Esta es la tabla que usualmente usarás para análisis más detallados a nivel de página.

3. Gestionando los costes de BigQuery

Esta es una de las mayores preocupaciones, pero con una buena gestión, los costes suelen ser muy manejables. BigQuery cobra por dos conceptos principales:

• Almacenamiento (Storage): El coste es de aproximadamente 0,02 € por GB al mes. A menos que tengas sitios web con volúmenes de tráfico gigantescos (decenas de millones de clics diarios), este coste suele ser insignificante, a menudo por debajo de los 100 € mensuales. Puedes estimar el coste inicial viendo cuántos GB se generan los primeros días.

• Consultas (Querying): Aquí es donde la cosa puede ponerse cara si no tienes cuidado. Se te cobra unos 5 € por cada TB procesado.

  • UI de BigQuery: Cuando ejecutas una consulta directamente en la interfaz de BigQuery, siempre verás la cantidad de datos que se procesarán y, por lo tanto, el coste estimado.

  • Herramientas de terceros (Looker Studio, TablePlus, etc.): El problema surge al usar conectores de otras herramientas. Looker Studio, por ejemplo, genera y ejecuta las consultas por ti. Si tu panel está mal optimizado, puede lanzar docenas de consultas y procesar terabytes de datos sin que te des cuenta, disparando los costes.

4. Optimizando tus datos: la arquitectura moderna (¡la clave!)

La idea es simple: no conectes tus herramientas de visualización (como Looker Studio) directamente a las tablas searchdata_site_impression o searchdata_url_impression. ¿Por qué?

• Lentitud: Estas tablas pueden tener miles de millones de filas. Un informe conectado directamente será extremadamente lento.

• Coste: Cada consulta en esas tablas gigantes es carísima. Un dashboard mal optimizado puede costarte cientos de euros al día.

La solución es aplicar una arquitectura de datos moderna, que se basa en dos niveles:

• Datos brutos (Raw Data): Son las tablas originales de GSC (searchdata_site_impression y searchdata_url_impression). Contienen toda la información disponible y se guardan para futuras necesidades, pero nunca se usan para reporting directo. El almacenamiento es barato, así que tenerlos es interesante para nosotros.

• Datos finales (Final Data): Son tablas que tú creas a partir de los datos brutos, incluyendo solo las métricas y dimensiones que necesitas para tus informes. Estas tablas están optimizadas para la velocidad y el coste.

5. Transformación de datos con Dataform (o DBT)

Para pasar de tus datos brutos a tus datos finales, necesitas una herramienta de transformación. Dataform (integrado en Google Cloud) o DBT son excelentes opciones. Aquí unas pequeñas indicaciones de cómo podemos usarlas:

• Define tus necesidades: Antes de transformar, piensa qué quieres ver en tus informes. Por ejemplo: fecha, clics, impresiones, tipo_pagina (blog, producto, etc.), tipo_consulta (branded, no-branded, anonimizada).

  

  
  

• Configura Dataform:

  • Crea un nuevo repositorio en Dataform dentro de tu proyecto de Google Cloud.

  • Configura el archivo workflow_settings.yaml con tu defaultProject, defaultLocation y defaultDataset.

  • En el archivo declarations.js (dentro de la carpeta sources), declara tus tablas de GSC (searchdata_site_impression y searchdata_url_impression) para poder referenciarlas fácilmente.

• Crea tu SQLX (el código de transformación):

  • Crea un archivo .sqlx (por ejemplo, gsc_data_pro.sqlx).

  • Define una tabla incremental: usa config { type: "incremental", ... }. Esto es crucial para el coste. Significa que Dataform solo procesará los datos nuevos cada vez que se ejecute, en lugar de reconstruir toda la tabla desde cero.

  • Particiona la tabla por fecha: Usa bigquery:{ partitionBy:"date", }. Las particiones permiten a BigQuery leer solo los datos necesarios para una consulta, reduciendo drásticamente los costes cuando filtras por rango de fechas.

  • Implementa la lógica para obtener el gsc_checkpoint: Es la última fecha de datos que ya tienes en tu tabla final. Esto asegura que solo proceses datos posteriores a esa fecha en ejecuciones incrementales.

  • Escribe tu consulta SQL: Aquí es donde seleccionas y transformas tus datos de las tablas originales de GSC. Por ejemplo, puedes usar sentencias CASE para clasificar las URLs en page_type o las queries en query_type.

• Prueba y programa:

  • Ejecuta tu modelo en Dataform para asegurarte de que se crea correctamente y sin errores. Verás cuánto cuesta una ejecución incremental y una completa.

  • Programa tu flujo de trabajo (workflow): Configura Dataform para que se ejecute diariamente. Si hay datos nuevos de GSC, se añadirán a tu tabla final; si no, no se ejecutará nada o apenas se consumirá, manteniendo los costes a raya.

6. Conectar Looker Studio (o tu herramienta favorita)

Una vez que tengas tu tabla de datos finales optimizada en BigQuery, ya puedes conectar tu herramienta de visualización sin miedo:

• En Looker Studio: Crea un nuevo informe, selecciona el conector de BigQuery y, esta vez, ¡elige tu tabla gsc_data_pro (o como la hayas llamado)!

• Beneficios: Notarás que tus informes cargan mucho más rápido y que los costes de BigQuery por consultas se reducen drásticamente.

---

Configurar GSC en BigQuery puede parecer intimidante al principio, pero siguiendo estos pasos y entendiendo la lógica de la arquitectura de datos, transformarás tu forma de analizar el rendimiento SEO. ¿Tienes alguna pregunta sobre alguno de estos pasos o te gustaría que profundizara en algún punto específico? déjala en los comentarios.