GAQL se ejecuta desde un script o desde la API. La pregunta de arquitectura es dónde vive la lógica: dentro de Google (script) o fuera (un servidor con la API). No hay una respuesta única — hay una tabla de decisión, y elegir mal se paga en meses de mantenimiento.
Script o API: cuándo cada uno
| Necesidad | Script | API desde servidor |
|---|---|---|
| Leer informes y escribir en hojas | Sí (nativo, sin infraestructura) | Posible, con más trabajo |
| Cambios en la cuenta (pausar, presupuestos, negativas) | Sí | Sí |
| Procesos de más de 30 minutos | No (por tandas) | Sí |
| Base de datos propia (histórico entre cuentas) | No (hojas) | Sí |
| Claves de servicios externos (IA) | En la cuenta/hoja (con riesgo) | En el servidor |
| Centenares de cuentas | MCC con límites | API con cuota estándar |
| Instalación sin programar | Sí (pegar un script) | No |
| Coste de arranque | Minutos | Días o semanas (proyecto de desarrollo) |
Lo que el script hace mejor
El script de Google Ads es la herramienta más infravalorada de la plataforma: corre DENTRO de Google (sin servidores, sin credenciales que gestionar, sin OAuth), lee cualquier informe por GAQL, escribe en hojas de cálculo de forma nativa y puede programarse cada hora — trabajo casi en tiempo real. Para el 90% de las automatizaciones de un anunciante o una agencia, el script llega y sobra. Sus dos límites duros: 30 minutos por ejecución (los procesos grandes se trocean en tandas) y las cuotas de llamadas externas.
Cuándo hace falta la API (y su letra pequeña)
La API de Google Ads entra en juego cuando el proyecto necesita lo que un script no puede dar: procesos que duran horas, una base de datos propia que cruce histórico de varias cuentas, integraciones con otros sistemas, o volúmenes de cuentas que desbordan un MCC. La letra pequeña: token de desarrollador con su proceso de aprobación, OAuth, infraestructura que mantener, y una verdad que ya contaba en mi primer libro — «el desarrollo con la API no acaba nunca: una vez que empiezas, siempre se te ocurre algo nuevo que implementar». La API es un compromiso a largo plazo, no un atajo.
El criterio para decidir
- Si cabe en 30 minutos y el resultado vive bien en una hoja: script, siempre. Es más barato, más rápido de construir y no depende de nada.
- Si necesita memoria entre cuentas, procesos largos o claves que no deben circular: servidor con API — asumiendo su coste real.
- Las herramientas profesionales del mercado suelen combinar ambos mundos (una parte instalable + servicios en servidor); como usuario te basta con evaluar el resultado: qué datos pide, qué permisos necesita y qué pasa si su servicio se cae un día.
⚠️ Trampa: el error clásico es sobredimensionar: montar servidor, base de datos y API para algo que un script de 200 líneas resolvía. La infraestructura no mejora el marketing — lo mejoran los datos y el criterio. Empieza por el script; migra a la API cuando choques dos veces con sus límites, no antes.
💡 Truco ninja: el punto medio olvidado son los scripts a nivel de MCC: un solo script que recorre decenas de cuentas con la misma lógica, sin API ni servidores. Para agencias con procesos estandarizados es el mejor coste/beneficio de toda la plataforma.
Qué debes recordar
- Script para leer, escribir en hojas, cambiar la cuenta e instalar sin programar; API en servidor para procesos largos, bases de datos y claves protegidas.
- La API es un proyecto de desarrollo con mantenimiento para siempre; el script es una herramienta que ya tienes.
- Empieza simple y migra solo cuando los límites te lo pidan dos veces.
Fin del Módulo 8. El Módulo 9 sube de nivel: arquitecturas de cuenta para escalar, con casos reales.