Cómo conectar Google Ads a Redshift: datos bajo control

Google Ads y Redshift se cruzan para ordenar campañas, costes y conversiones con datos fiables, histórico propio y análisis del negocio real.

Conectar Google Ads a Redshift consiste, en la práctica, en sacar los datos publicitarios de la plataforma de Google mediante la Google Ads API o un conector especializado, cargarlos en una zona intermedia —normalmente Amazon S3— y dejarlos ordenados dentro de Amazon Redshift para analizarlos con SQL, BI, modelos de atribución o cuadros de mando propios. No es una maniobra ornamental. Es el momento en que una cuenta publicitaria deja de vivir encerrada en sus informes nativos y entra en la sala de máquinas del negocio.

La vía más limpia para hacerlo depende del tamaño de la empresa, del presupuesto y de la paciencia técnica disponible. Un anunciante pequeño puede usar un conector ELT como Airbyte, Fivetran, Stitch, Hevo, Windsor.ai o similares; una agencia con decenas de cuentas suele preferir una arquitectura más controlada; y un equipo de datos maduro puede trabajar directamente con Google Ads API, guardar los resultados en S3 y cargar los datos en Redshift con COPY. La mala noticia —hay que decirlo— es que no existe un único método perfecto. La buena: casi todos los errores caros se pueden evitar si se entiende bien qué se mueve, cuándo se sincroniza y cómo se interpreta cada métrica.

La conexión que separa el dato útil del ruido

Google Ads ya ofrece informes dentro de su propia interfaz, claro. También permite exportaciones, paneles, integraciones con Looker Studio y alguna comodidad de esas que parecen suficientes hasta que aparece la primera pregunta incómoda: cuánto margen real dejó una campaña, qué cliente llegó por SEM pero cerró por email, qué palabra clave trae ventas limpias y no solo formularios con olor a humo, qué campaña de Performance Max está inflando el volumen mientras el coste por adquisición se estira como un chicle viejo.

Ahí entra Redshift. No como almacén por capricho, sino como centro de gravedad del dato. Cuando los datos de Google Ads conviven con CRM, analítica web, facturación, inventario, llamadas comerciales o datos de producto, el análisis cambia de liga. Ya no se mira solo el clic. Se mira el clic con su consecuencia. Se puede cruzar inversión, margen, recurrencia, devolución, territorio, segmento, temporada y vida útil del cliente. La publicidad deja de ser una tabla bonita y se convierte en contabilidad de la atención.

El problema es que Google Ads no habla Redshift de manera directa para todos los casos. No se pulsa un botón oficial y aparece una base perfecta al otro lado. Lo normal es usar una capa de extracción y carga. Esa capa puede ser un conector comercial, una herramienta open source o un desarrollo propio con la API. En cualquiera de las tres rutas, el corazón del asunto es el mismo: extraer informes de Google Ads, normalizar campos, respetar permisos, controlar fechas, evitar duplicados y cargar datos en tablas que luego se puedan consultar sin hacer arqueología cada lunes.

Conviene asumir otra cosa desde el principio. Los datos de Google Ads no son piedra grabada. Hay conversiones que llegan tarde, campañas que cambian de nombre, monedas que se expresan en micros, cuentas gestionadas desde MCC, campos que no combinan entre sí, recursos que dependen de versiones de API y modelos de atribución que pueden mover el suelo bajo los pies. En marketing digital, el dato rara vez entra por la puerta con traje planchado. Entra con polvo, etiquetas, retrasos y algún misterio.

La ruta más práctica: conector ELT, Redshift y calma

Para la mayoría de empresas, la forma más sensata de integrar Google Ads con Amazon Redshift es usar un conector ELT. La sigla suena a aparato industrial, pero la idea es sencilla: la herramienta extrae los datos de Google Ads, los carga en Redshift y deja que la transformación más fina ocurra después, ya dentro del almacén. Es menos artesanal que programar desde cero y bastante menos propenso a incendios si no se dispone de un equipo de ingeniería dedicado.

Airbyte, por ejemplo, ofrece un conector de Google Ads y un destino Redshift. En su versión open source exige más trabajo: token de desarrollador, credenciales OAuth, acceso correcto a la cuenta de Google Ads y configuración del destino con staging en S3. En la práctica, esto significa que los datos no suelen saltar de Google Ads a Redshift como una ardilla feliz; pasan por una zona intermedia en Amazon S3, que actúa como muelle de carga. Redshift bebe muy bien desde S3. Es su terreno natural.

Fivetran representa la versión más gestionada de ese camino. Se autoriza Google Ads mediante OAuth, se indica el customer ID o las cuentas bajo un Manager Account y se define el destino. Su virtud está en quitar fricción: sincronizaciones incrementales, esquemas predefinidos, tablas estándar y mantenimiento razonable cuando cambian los modelos. Su coste, naturalmente, puede crecer con el volumen. La comodidad tiene factura. Rara vez falla esa ley.

El flujo ideal no empieza conectando nada. Empieza decidiendo qué se necesita. Campañas, grupos de anuncios, anuncios, términos de búsqueda, costes, clics, impresiones, conversiones, valores de conversión, dispositivos, redes, ubicaciones, audiencias, assets, campañas de Shopping o Performance Max. Cada campo añade contexto, pero también peso, coste y posibles incompatibilidades. Seleccionar todos los datos porque “ya que estamos” es una vieja costumbre de oficina que acaba generando tablas obesas, consultas lentas y dashboards con más columnas que criterio.

En una cuenta pequeña, sincronizar campañas, grupos, anuncios, métricas diarias y conversiones puede bastar. En una agencia, interesa separar esquemas por cliente o por tipo de cuenta. En una empresa con ecommerce, conviene cruzar Google Ads con Redshift y con datos de producto y márgenes, porque vender mucho con poco beneficio no es rendimiento: es gimnasia financiera. Y bastante cansada.

La vía técnica: Google Ads API, S3 y COPY

El camino propio tiene una belleza áspera. Se usa Google Ads API para consultar informes mediante GAQL, se guardan los resultados en archivos estructurados —CSV, JSON o Parquet, según arquitectura—, se depositan en S3 y se cargan en Redshift con COPY. Es más trabajo, sí. También da más control sobre el modelo, la frecuencia, la validación y la forma exacta en que se guardan los datos.

Google Ads API permite consultar datos de rendimiento con servicios como SearchStream. En cristiano: se lanza una consulta sobre recursos publicitarios y se recibe una respuesta con métricas, segmentos y dimensiones. GAQL se parece a SQL, aunque no conviene confiarse. Tiene sus reglas, sus combinaciones permitidas y sus campos caprichosos. Pedir métricas incompatibles en la misma consulta es como pedirle a una hemeroteca que ordene los periódicos por olor: la intención puede ser interesante, pero el sistema no lo acepta.

La arquitectura típica es sobria. Un proceso programado consulta Google Ads por fecha, cuenta y recurso; guarda cada extracción en S3 con una ruta ordenada por día, cliente y tipo de informe; Redshift carga los ficheros con COPY; después, unas tablas de staging reciben el dato crudo y otras tablas analíticas lo limpian. Esta separación es importante. No se debe cargar directamente el dato final como si todo viniera perfecto. Primero entra en una antesala. Luego se revisa, se deduplica, se tipa, se convierte moneda, se ajustan fechas y se prepara para análisis.

Redshift está especialmente cómodo cargando datos desde S3. El comando COPY puede leer archivos de un bucket, usar rutas o manifiestos, y autorizarse mediante un rol IAM. Ese detalle parece menor hasta que alguien intenta meter credenciales a mano en un script que luego acaba copiado en un repositorio. El dato publicitario no es secreto de Estado, pero tampoco confeti. Hay inversión, estrategia, cuentas, clientes y señales comerciales. IAM, permisos mínimos y cifrado no son postureo técnico; son higiene.

Una decisión clave es la frecuencia. Para campañas activas, una carga diaria suele bastar en análisis de negocio, pero un equipo de puja o reporting operativo puede necesitar varias sincronizaciones al día. Las conversiones tardías obligan a reabrir ventanas recientes. Si solo se carga “ayer” y nunca se vuelve atrás, se perderán ajustes. Lo razonable es recargar una ventana móvil, por ejemplo los últimos 7, 14 o 30 días, según el ciclo de conversión. El marketing no siempre cierra cuando el usuario hace clic. A veces vuelve tres días después, con café, dudas y tarjeta.

En mayo de 2026, la versión v24 de Google Ads API ya está publicada y trae cambios en áreas como anuncios, Demand Gen, reporting y otros recursos. Esto importa porque una integración de Google Ads con Redshift no se construye y se abandona como una maceta en el alféizar. Hay que mantenerla. Las versiones de API cambian, algunos campos desaparecen, otros llegan, ciertas validaciones se endurecen y los conectores deben adaptarse. El dato publicitario vive en una casa con reformas constantes.

También hay un cambio especialmente relevante para quien monta un histórico propio en Redshift: desde el 1 de junio de 2026, Google anunció una política de retención de 37 meses para estadísticas granulares de rendimiento, mientras los datos agregados mensuales, trimestrales y anuales mantienen una disponibilidad más larga. Traducido al lenguaje de negocio: guardar histórico propio en Redshift deja de ser una manía de analista y se convierte en seguro contra la pérdida de detalle. Quien necesite comparar campañas diarias de hace cuatro años no debería confiar en que la plataforma publicitaria le conserve siempre ese nivel de granularidad.

A partir del 15 de junio de 2026, además, Google comienza a ajustar el reporting de productos para incluir datos de todas las redes de Performance Max, con métricas más completas entre tipos de campaña y canales. Para ecommerce, retail y cuentas con Shopping, este movimiento no es decorativo. Puede alterar cómo se interpretan series históricas, informes de producto y comparativas entre campañas. El almacén de datos debe registrar fechas de extracción, versión de esquema y, cuando proceda, cambios metodológicos. Sin eso, una subida de rendimiento puede ser una mejora real… o simplemente una nueva forma de contar.

Qué datos conviene llevar a Redshift

El primer impulso suele ser llevarlo todo. Todo, esa palabra que ha hundido más proyectos de datos que la falta de presupuesto. En Google Ads, “todo” significa estructuras de cuenta, métricas, segmentos, recursos, assets, conversiones, ubicaciones, términos de búsqueda, audiencias, extensiones, presupuestos, estrategias de puja y un largo pasillo de nombres que cambia según el tipo de campaña. Si el objetivo es análisis serio, hay que empezar por los informes que explican dinero, intención y resultado.

La base mínima razonable incluye datos diarios por cuenta, campaña, grupo de anuncios y anuncio, con coste, clics, impresiones, conversiones y valor de conversión. A eso se le añade segmentación por dispositivo, red, país o región cuando esas dimensiones influyen de verdad en decisiones. En B2B, quizá interesen más los leads cualificados que las conversiones brutas. En ecommerce, el valor de conversión necesita dialogar con margen, stock y devoluciones. En negocios locales, la ubicación puede pesar más que la creatividad. Cada empresa tiene su propia huella.

Hay un punto técnico que conviene no olvidar: Google Ads expresa muchos importes en micros. Un millón de micros equivale a una unidad de moneda. Si alguien carga el coste sin convertirlo, el dashboard puede declarar que una campaña gastó 184 millones de euros cuando, en realidad, fueron 184. La escena es cómica durante tres segundos. Luego deja de serlo. Normalizar importes es una de esas tareas pequeñas que separan un almacén fiable de una fábrica de sustos.

Las conversiones merecen capítulo aparte. No todas pesan igual. Puede haber conversiones primarias y secundarias, llamadas, formularios, compras, acciones importadas, conversiones offline, valores ajustados y retrasos por atribución. Llevar conversiones a Redshift sin entender su definición es como archivar facturas sin saber si son ingresos o presupuestos. El dato entra, sí, pero no necesariamente dice la verdad.

También conviene conservar nombres y estados históricos. Una campaña que hoy se llama “Brand España PMax Q2” pudo llamarse de otra manera hace dos meses. Si el modelo solo guarda el nombre actual, las comparativas antiguas se vuelven confusas. Las tablas de historial ayudan a reconstruir la película. No solo la foto. En publicidad, la foto suele mentir por omisión; la película, al menos, confiesa sus cortes.

Amazon Redshift es potente, pero no hace milagros con modelos mal diseñados. Si se carga una tabla gigantesca con todos los campos mezclados, sin tipos claros, sin claves, sin estrategia de actualización y sin partición lógica por fecha, el almacén acabará convertido en un trastero caro. Y los trasteros, ya se sabe, siempre prometen orden hasta que uno abre la puerta.

Redshift no perdona una mala mesa

Lo sensato es trabajar con capas. Una tabla de staging recibe el dato tal como llega del conector o de la API. Otra capa limpia y normaliza. Una tercera prepara modelos analíticos listos para BI: rendimiento diario por campaña, gasto por cuenta, coste por conversión, ROAS, evolución por dispositivo, comparativas por país, eficiencia por tipo de campaña. Este patrón evita que cada dashboard tenga que repetir las mismas transformaciones y reduce la tentación, muy humana, de calcular cada métrica de una forma distinta.

La deduplicación es crítica. Las sincronizaciones incrementales pueden traer cambios sobre registros recientes. Las recargas de ventanas móviles pueden pisar datos. Los conectores pueden modificar esquemas. Una buena tabla debe poder identificar una fila por cuenta, fecha, recurso, segmento y tipo de informe. Después se decide si se reemplaza, se actualiza o se conserva versión. La trazabilidad importa porque cuando el CEO pregunta por qué el gasto del martes cambió el jueves, responder “cosas de Google” no suele irradiar liderazgo.

En Redshift, COPY desde S3 permite cargar datos de manera eficiente y paralela. Para flujos más automatizados, existen mecanismos como COPY JOB, que puede vigilar ubicaciones de S3 y cargar nuevos archivos bajo ciertas condiciones. No siempre hace falta complicar la arquitectura; a veces un orquestador como Airflow, Dagster, Prefect, Step Functions o incluso una Lambda bien medida basta. La elegancia está en que falle poco, avise pronto y deje huella.

Las cuentas de Google Ads gestionadas desde un Manager Account añaden una capa de complejidad. No basta con tener acceso visual a una cuenta; la integración necesita permisos adecuados y, en desarrollos propios, un developer token aprobado. En conectores gestionados, la autorización OAuth simplifica bastante el camino, aunque no elimina la necesidad de revisar qué cuentas se sincronizan, quién autorizó el acceso y qué ocurre si ese usuario pierde permisos o abandona la empresa. La rotación humana, ese pequeño desastre recurrente.

En AWS, el acceso de Redshift a S3 debe hacerse con roles IAM bien delimitados. Nada de llaves eternas circulando por hojas de cálculo. El bucket de staging debería tener cifrado, políticas claras, control de acceso y ciclo de vida para no acumular archivos sin sentido durante años. Si hay datos de varios clientes, separar rutas, esquemas y permisos no es manía legalista. Es supervivencia profesional.

La privacidad también entra en juego. Google Ads no debería convertirse en excusa para aspirar más datos de los necesarios. Los informes de rendimiento suelen ser agregados, pero al cruzarlos con CRM o ventas pueden aparecer datos sensibles o identificadores internos. El modelo debe respetar minimización, controles de acceso y finalidades claras. El dato, cuando se mezcla demasiado, empieza a parecer inocente hasta que deja de serlo.

Errores habituales al exportar Google Ads a Redshift

El error más común es creer que conectar equivale a entender. Una tabla cargada en Redshift no garantiza análisis. Solo garantiza que hay datos en algún sitio. La diferencia entre un warehouse útil y un vertedero elegante está en la semántica: qué representa cada campo, cómo se calcula cada métrica, qué periodo cubre, qué desfase arrastra y qué cambios de plataforma pueden haber alterado la serie.

Otro tropiezo frecuente es ignorar las ventanas de atribución. Google Ads puede actualizar conversiones después del clic inicial. Si la integración solo extrae datos del día anterior y nunca vuelve a consultar fechas recientes, el histórico quedará subestimado. La solución no es filosófica: recargar una ventana móvil y documentar el comportamiento. El dato fresco huele bien, pero a veces todavía está crudo.

Los cambios de esquema también rompen cosas. Un conector puede añadir campos, retirar otros, cambiar tipos o exigir refrescar la fuente después de una actualización de API. En Airbyte, por ejemplo, las migraciones de versiones pueden requerir refrescar el esquema y resetear streams afectados. En Fivetran, ciertos informes personalizados pueden chocar con limitaciones de campos combinables de Google Ads API. La integración necesita mantenimiento, igual que una campaña necesita revisar términos de búsqueda, creatividades y presupuesto. Lo automático no significa autónomo.

La granularidad excesiva es otro vicio. Cruzar fecha, hora, dispositivo, ubicación, audiencia, término, campaña, anuncio y conversión puede producir una tabla inmensa con poca utilidad real. Hay análisis que necesitan detalle; otros necesitan estabilidad. Meter todas las dimensiones en todos los informes convierte cada consulta en una mudanza. Mejor varios modelos orientados a uso que una catedral única donde nadie encuentra la puerta.

Y luego está el reporting bonito, ese narcótico. Un dashboard puede mostrar ROAS, CPA, CTR y conversiones con colores elegantes mientras debajo hay costes en micros, conversiones duplicadas, campañas renombradas y fechas incompletas. La estética no valida el dato. Solo lo maquilla. Antes de diseñar el panel, hay que reconciliar totales con Google Ads, comprobar diferencias aceptables, revisar cuentas incluidas, monedas, zonas horarias y modelos de conversión. La cocina antes que el escaparate.

Para un proyecto medio, la arquitectura recomendable no necesita fuegos artificiales. Un conector ELT autorizado contra Google Ads extrae datos diarios de las cuentas seleccionadas, los deposita en Redshift mediante staging en S3 y crea tablas base. Después, dbt o SQL programado genera modelos limpios: campañas por día, rendimiento por dispositivo, inversión por cuenta, conversiones por acción, evolución semanal y comparativas frente a objetivos. Un orquestador controla horarios y alertas. Un panel de BI consulta solo modelos finales, no tablas crudas.

Si se desarrolla a medida, el patrón cambia poco. Un script consulta Google Ads API con GAQL, pagina resultados, respeta límites, guarda archivos en S3 con rutas fechadas, ejecuta COPY hacia staging, valida conteos, reemplaza particiones recientes y deja logs. No suena glamuroso. Mejor. Las integraciones de datos que presumen demasiado suelen acabar llorando en silencio a las tres de la mañana.

El primer día no hace falta cubrir toda la galaxia. Es más inteligente empezar con un informe de coste y rendimiento diario por campaña, reconciliarlo contra Google Ads, añadir conversiones, incorporar dimensiones relevantes y, solo después, ampliar a términos de búsqueda, assets o producto. La confianza se construye por capas. Primero que cuadre el gasto. Luego que cuadren las conversiones. Después ya vendrán los modelos de atribución, los experimentos y las conversaciones profundas sobre incrementalidad, esa palabra que en marketing se pronuncia mucho y se demuestra bastante menos.

El almacén donde la publicidad aprende a hablar

El gran beneficio aparece cuando Redshift deja de ser un destino técnico y se convierte en una memoria común. Marketing ve inversión y rendimiento. Finanzas ve coste y margen. Ventas ve calidad de lead. Producto ve demanda. Dirección ve tendencia. La misma campaña ya no tiene cinco verdades repartidas en cinco hojas distintas. Tiene una discusión mejor informada. Que no es poco.

Conectar Google Ads a Redshift no es solo una integración entre plataformas. Es una decisión sobre cómo se quiere gobernar el rendimiento. La publicidad digital ha vivido demasiados años dentro de paneles que explican muy bien lo que ocurre dentro de su jardín, pero bastante peor lo que pasa al otro lado de la verja. Redshift abre esa verja. No arregla la estrategia, no abarata los clics por arte de magia, no convierte una mala oferta en un negocio brillante. Pero permite mirar el gasto con menos niebla.

La ruta más razonable para la mayoría será un conector ELT bien configurado, con sincronización incremental, staging en S3, tablas limpias y controles de calidad. La ruta más potente será una integración propia con Google Ads API, especialmente cuando haya necesidades muy específicas, múltiples cuentas, modelos internos de atribución o exigencias de gobierno del dato. En ambos casos, la prioridad es la misma: histórico fiable, métricas bien definidas y mantenimiento constante.

En 2026, con cambios en versiones de API, límites de retención granular y reporting cada vez más atravesado por Performance Max, almacenar el dato publicitario en un warehouse deja de parecer una extravagancia de empresas grandes. Es una forma de conservar memoria. Y la memoria, en marketing, vale dinero. A veces mucho. Porque quien solo mira el panel de ayer puede optimizar el clic; quien conserva y cruza años de datos puede entender el negocio. Esa es la diferencia entre conducir mirando el velocímetro y conducir mirando también la carretera.