Google Ads Scripts y Automatización con IA: Guía Técnica Completa 2026
Google Ads Scripts es la herramienta de automatización nativa de Google Ads que permite ejecutar código JavaScript directamente sobre una cuenta —o sobre múltiples cuentas cliente desde una cuenta MCC— para leer métricas, tomar decisiones basadas en reglas de negocio y ejecutar cambios estructurales sin intervención manual. A diferencia de las reglas automatizadas nativas de la interfaz, que cubren un puñado de condiciones predefinidas, Scripts corre sobre el motor Google Apps Script de Google y expone el objeto AdsApp, lo que habilita lógica arbitrariamente compleja: comparar tendencias históricas, cruzar datos de múltiples fuentes, escribir en hojas de cálculo externas o enviar alertas condicionales por email.
Esta guía es una referencia técnica completa y orientada a la implementación: qué son los scripts y en qué se diferencian de otras herramientas de automatización de Google Ads, cómo se estructura un script desde cero, cinco ejemplos de código completo y funcional que podés adaptar hoy mismo a tu cuenta, cómo la inteligencia artificial generativa se está integrando en este flujo de trabajo, los límites técnicos reales que hay que conocer antes de escalar automatización, los errores más comunes que vemos en auditorías de cuentas con scripts mal implementados, y las prácticas de seguridad que aplicamos en Old Fox antes de dar permisos de escritura a cualquier pieza de código que toque presupuesto o estructura de campaña real.
Si gestionás una cuenta de Google Ads con más de un puñado de campañas, tarde o temprano vas a necesitar automatizar algo que la interfaz nativa no cubre: una alerta de variación de costo, un pausado condicional, un reporte que combine datos de múltiples campañas en un formato que tu equipo pueda leer sin abrir la plataforma. Esta guía te da el marco técnico y el código de partida para hacerlo bien desde el primer script.
Solicitá una Auditoría Gratuita de tu Cuenta →
¿Qué son Google Ads Scripts? Definición Técnica
Google Ads Scripts es una funcionalidad integrada en la interfaz de Google Ads (dentro de Herramientas y Configuración → Acciones masivas → Scripts) que permite escribir y ejecutar código JavaScript sobre el motor de Google Apps Script, con acceso a una API específica de Google Ads llamada AdsApp. El código se ejecuta en los servidores de Google, no en el navegador del usuario, lo que significa que un script puede correr de forma programada (por ejemplo, cada hora o cada día) sin que nadie tenga la cuenta abierta.
Técnicamente, un script de Google Ads es una función main() —el punto de entrada obligatorio, igual que en cualquier programa ejecutable— que puede leer entidades de la cuenta (campañas, grupos de anuncios, palabras clave, anuncios, extensiones), leer métricas de rendimiento vía reportes en GAQL (Google Ads Query Language, el lenguaje de consulta que reemplazó a AWQL desde 2022), y ejecutar acciones de escritura como pausar, activar, cambiar pujas o modificar presupuestos.
Los casos de uso típicos que resuelven los scripts, y que la interfaz nativa no cubre bien o directamente no cubre, son:
Automatización de reglas de negocio complejas. Condiciones que combinan múltiples métricas, múltiples períodos de comparación o lógica condicional anidada que las reglas automatizadas nativas no soportan.
Alertas proactivas. Notificaciones por email cuando una métrica se desvía de un patrón esperado, en lugar de descubrir el problema al revisar manualmente la cuenta días después.
Reportes y exportación de datos. Envío automático de métricas a Google Sheets, BigQuery o sistemas externos vía UrlFetchApp, para armar dashboards que combinen Google Ads con otras fuentes de datos del negocio.
Pausado y activación condicional. Reglas de pausado más sofisticadas que las nativas, como pausar keywords con Quality Score sostenidamente bajo, o reactivar campañas estacionales según condiciones externas (clima, inventario, eventos).
Gestión a escala en cuentas MCC. Ejecutar la misma lógica de forma simultánea sobre decenas o cientos de cuentas cliente, algo que sería inviable de hacer manualmente cuenta por cuenta.
Antes de escribir el primer script, vale la pena entender dónde encaja esta herramienta frente a las otras tres formas de gestionar automatización en Google Ads: el editor nativo, las reglas automatizadas y la API oficial.
Google Ads Scripts vs. Editor vs. Reglas Automatizadas vs. API: Comparativa Técnica
Es habitual que equipos de marketing confundan estas cuatro herramientas, o que usen la más compleja para un caso de uso que la más simple resuelve perfectamente bien. Esta tabla resume las diferencias técnicas reales:
| Herramienta | Requiere código | Nivel de complejidad | Límite de ejecución | Casos de uso ideales |
|---|---|---|---|---|
| Google Ads Editor | No | Bajo | Sin límite (offline, sincroniza al subir cambios) | Cambios masivos puntuales, edición offline, copias entre cuentas |
| Reglas Automatizadas (Automated Rules) | No | Bajo-Medio | Ejecución nativa, sin límite de tiempo propio | Condiciones simples (pausar si CPA > X, subir puja si posición < Y) |
| Google Ads Scripts | Sí (JavaScript) | Medio-Alto | 30 minutos por ejecución en cuenta individual | Lógica condicional compleja, alertas, reportes, automatización a escala MCC |
| Google Ads API | Sí (cualquier lenguaje soportado por el SDK) | Alto | Sin límite de tiempo de ejecución propio del lado de Google (depende de tu infraestructura) | Integraciones con sistemas propios, aplicaciones de gestión multicuenta, automatización a nivel de producto o plataforma |
La diferencia clave entre Scripts y la API no es solo técnica sino de propósito: Scripts corre dentro de la infraestructura de Google Ads, sin necesidad de servidores propios, autenticación OAuth compleja ni mantenimiento de infraestructura; la API requiere una aplicación propia (con su propio hosting, autenticación y manejo de errores) pero no tiene el límite de 30 minutos por ejecución y permite construir productos completos sobre Google Ads. En la enorme mayoría de las cuentas que gestionamos en Old Fox, Scripts cubre el 100% de las necesidades de automatización sin necesidad de llegar a la complejidad de una integración vía API.
Las reglas automatizadas nativas, por su parte, siguen siendo la opción correcta para condiciones verdaderamente simples de una sola variable (por ejemplo, "pausar anuncio si CTR menor a 1% durante 7 días"), porque no requieren mantenimiento de código ni conocimiento técnico. El error que vemos con frecuencia en auditorías es el opuesto: cuentas que replican en un script complejo algo que una regla automatizada nativa resolvía en dos clics, agregando mantenimiento innecesario.
Estructura Básica de un Script: main(), AdsApp y Programación de Ejecuciones
Todo script de Google Ads parte de la misma estructura mínima obligatoria: una función main() sin parámetros, que es el único punto de entrada que Google Ads reconoce y ejecuta. Dentro de esa función accedés a la cuenta a través del objeto global AdsApp (o AdsManagerApp si el script corre a nivel de cuenta MCC).
function main() {
// Todo el código del script vive dentro de esta función
Logger.log("Cuenta: " + AdsApp.currentAccount().getName());
}
El objeto AdsApp expone selectores para cada tipo de entidad de la cuenta —AdsApp.campaigns(), AdsApp.adGroups(), AdsApp.keywords(), AdsApp.ads(), AdsApp.shoppingProducts(), entre otros— que devuelven iteradores sobre los que se puede aplicar condiciones (withCondition()), rangos de fecha (forDateRange()) y límites (withLimit()) antes de recorrerlos con .get(). Además, AdsApp.report() permite ejecutar consultas GAQL directamente, que es el método recomendado hoy para extraer métricas agregadas de forma eficiente, en lugar de iterar entidad por entidad cuando el volumen de datos es alto.
Cómo se Programan las Ejecuciones (Triggers)
Un script no corre solo la primera vez que lo escribís: hay que asociarle una programación (schedule) desde la sección "Programación" del editor de scripts, o dejarlo en ejecución manual si preferís correrlo bajo demanda. Las opciones nativas de programación incluyen ejecución cada hora, cada día a una hora específica, cada semana en un día determinado, o cada mes. No es posible programar ejecuciones con una frecuencia menor a una hora: si necesitás monitoreo casi en tiempo real, la única alternativa dentro del ecosistema de Google Ads es una integración vía API con tu propia infraestructura de scheduling.
Cada ejecución programada corre de forma completamente independiente: un script no "recuerda" nada de la ejecución anterior salvo que explícitamente guardes ese estado en algún lugar persistente, como una hoja de cálculo, el servicio PropertiesService de Apps Script, o una base de datos externa vía UrlFetchApp. Este es un punto que genera confusión frecuente: si tu lógica depende de comparar el estado actual contra un estado anterior (por ejemplo, "esta keyword tuvo Quality Score bajo en las últimas 3 ejecuciones consecutivas"), tenés que diseñar explícitamente ese mecanismo de persistencia, porque el script por sí solo no tiene memoria entre corridas.
Scripts a Nivel de Cuenta Individual vs. Nivel MCC
Cuando el script se escribe dentro de una cuenta individual, AdsApp opera exclusivamente sobre esa cuenta. Cuando se escribe dentro de una cuenta MCC (administrador), el objeto relevante pasa a ser AdsManagerApp, que expone AdsManagerApp.accounts() para iterar sobre las cuentas cliente y el método .select() para "entrar" al contexto de una cuenta específica antes de ejecutar lógica con AdsApp dentro de ese contexto. Los scripts MCC además permiten executeInParallel(), que ejecuta la misma función sobre múltiples cuentas cliente de forma simultánea en lugar de secuencial, lo cual es indispensable cuando gestionás automatización sobre decenas de cuentas.
Ejemplo 1: Script de Alerta de Variación de CPA
Este es probablemente el script más útil para cualquier cuenta con presupuesto relevante: compara el CPA del día actual contra el promedio de los últimos 7 días y envía un email automático si la variación supera un umbral definido. Detectar una desviación de CPA el mismo día, en lugar de descubrirla al revisar la cuenta días después, es la diferencia entre corregir un problema con impacto acotado o dejarlo erosionar el presupuesto de todo el mes.
function main() {
var CPA_INCREASE_THRESHOLD = 0.30; // 30% de aumento dispara la alerta
var ALERT_EMAIL = "cuentas@tuagencia.com";
var today = getAggregatedMetrics("TODAY");
var last7Days = getAggregatedMetrics("LAST_7_DAYS");
if (today.conversions === 0 || last7Days.conversions === 0) {
Logger.log("Conversiones insuficientes para calcular CPA. Se omite la alerta de hoy.");
return;
}
var todayCpa = today.cost / today.conversions;
var avgCpa7d = last7Days.cost / last7Days.conversions;
var variation = (todayCpa - avgCpa7d) / avgCpa7d;
if (variation > CPA_INCREASE_THRESHOLD) {
var subject = "Alerta de CPA: " + AdsApp.currentAccount().getName();
var body = "El CPA de hoy ($" + todayCpa.toFixed(2) + ") supera en " +
(variation * 100).toFixed(1) + "% el promedio de los últimos 7 días ($" +
avgCpa7d.toFixed(2) + ").\n\n" +
"Costo de hoy: $" + today.cost.toFixed(2) + " / Conversiones: " + today.conversions;
MailApp.sendEmail(ALERT_EMAIL, subject, body);
Logger.log(body);
} else {
Logger.log("CPA dentro de rango normal. Variación: " + (variation * 100).toFixed(1) + "%");
}
}
function getAggregatedMetrics(dateRange) {
var query =
"SELECT metrics.cost_micros, metrics.conversions " +
"FROM campaign " +
"WHERE campaign.status = 'ENABLED' " +
"AND segments.date DURING " + dateRange;
var report = AdsApp.report(query);
var rows = report.rows();
var totalCost = 0;
var totalConversions = 0;
while (rows.hasNext()) {
var row = rows.next();
totalCost += row["metrics.cost_micros"] / 1000000;
totalConversions += parseFloat(row["metrics.conversions"]);
}
return { cost: totalCost, conversions: totalConversions };
}
Qué hace exactamente: la función auxiliar getAggregatedMetrics() ejecuta una consulta GAQL sobre la vista campaign para dos rangos de fecha distintos y suma costo y conversiones de todas las campañas activas. Luego main() calcula el CPA de cada período y compara la variación porcentual contra un umbral configurable. Si el umbral se supera, dispara un email vía MailApp.sendEmail(), la función nativa de Apps Script para envío de correo sin necesidad de configurar un servidor SMTP propio.
Por qué es útil: esta es exactamente la clase de monitoreo que complementa bien el seguimiento de campañas con Smart Bidding, donde el algoritmo puede tardar en corregir una desviación de costo por sí solo. Si gestionás campañas con estrategias de puja automatizada, te recomendamos revisar también nuestra guía completa de Smart Bidding y puja automatizada para entender cuándo una variación de CPA es ruido normal del algoritmo y cuándo es una señal de un problema estructural real.
Ejemplo 2: Script de Pausado Automático de Keywords con Quality Score Bajo Sostenido
Antes de mostrar el código, una aclaración técnica importante: el Quality Score es una métrica que existe a nivel de palabra clave, no a nivel de anuncio. Es un error conceptual frecuente (incluso entre gestores de cuentas con experiencia) asumir que el Quality Score se aplica al anuncio individual; en realidad se calcula por la combinación de keyword, relevancia del anuncio, y experiencia de landing page asociada a esa keyword específica. Por eso este script pausa keywords, no anuncios, con Quality Score sostenidamente bajo.
function main() {
var QS_THRESHOLD = 3; // Quality Score mínimo aceptable (escala de 1 a 10)
var MIN_IMPRESSIONS = 100; // impresiones mínimas para considerar el dato confiable
var ALERT_EMAIL = "cuentas@tuagencia.com";
var keywordIterator = AdsApp.keywords()
.withCondition("Status = ENABLED")
.withCondition("Impressions >= " + MIN_IMPRESSIONS)
.forDateRange("LAST_14_DAYS")
.get();
var pausedCount = 0;
var pausedList = [];
while (keywordIterator.hasNext()) {
var keyword = keywordIterator.next();
var qs = keyword.getQualityScore();
if (qs !== null && qs <= QS_THRESHOLD) {
keyword.pause();
pausedCount++;
pausedList.push(
keyword.getText() + " (QS: " + qs + ", Grupo: " + keyword.getAdGroup().getName() + ")"
);
}
}
if (pausedCount > 0) {
var body = "Se pausaron " + pausedCount +
" keywords por mantener un Quality Score de " + QS_THRESHOLD +
" o menor durante los últimos 14 días:\n\n" + pausedList.join("\n");
MailApp.sendEmail(ALERT_EMAIL, "Alerta: keywords pausadas por bajo Quality Score", body);
Logger.log(body);
} else {
Logger.log("No se encontraron keywords por debajo del umbral de Quality Score.");
}
}
Qué hace exactamente: recorre todas las keywords activas con al menos 100 impresiones en los últimos 14 días (el filtro de impresiones mínimas evita pausar keywords con muy poco volumen, donde el Quality Score puede no ser representativo todavía), y pausa aquellas con Quality Score de 3 o menos usando el método nativo getQualityScore() del objeto Keyword.
Por qué es útil, y por qué requiere salvaguardas: un Quality Score bajo sostenido generalmente indica baja relevancia de anuncio o experiencia de landing page pobre para esa consulta específica, lo cual infla el CPC pagado por clic. Pausar automáticamente esas keywords protege el presupuesto de la cuenta, pero es también el ejemplo perfecto de un script que puede causar daño real si se implementa sin límites: si el umbral está mal calibrado, o si una campaña nueva todavía está en fase de aprendizaje con Quality Score temporalmente bajo, el script podría pausar tráfico que en realidad iba a mejorar con el tiempo. Más adelante en esta guía profundizamos en qué salvaguardas agregar antes de dar permisos de pausado automático a cualquier script. Para entender en profundidad cómo se calcula y qué componentes tiene el Quality Score, recomendamos nuestra nota completa sobre Quality Score en Google Ads.
Ejemplo 3: Script de Monitoreo de Presupuesto Agotado Antes de las 12hs
Cuando una campaña agota su presupuesto diario antes del mediodía, la cuenta pierde visibilidad durante las horas de mayor actividad del resto del día, un problema particularmente crítico en verticales con patrones de conversión concentrados en la tarde o noche. Este script corre cada mañana y alerta si alguna campaña ya consumió un porcentaje alto de su presupuesto diario antes de una hora límite configurable.
function main() {
var HOUR_THRESHOLD = 12; // hora límite, en la zona horaria de la cuenta
var SPEND_THRESHOLD_PERCENT = 90; // % del presupuesto diario considerado "agotado"
var ALERT_EMAIL = "cuentas@tuagencia.com";
var timezone = AdsApp.currentAccount().getTimeZone();
var now = new Date();
var currentHour = parseInt(Utilities.formatDate(now, timezone, "HH"), 10);
if (currentHour >= HOUR_THRESHOLD) {
Logger.log("Fuera de la ventana de control (antes de las " + HOUR_THRESHOLD + "hs). Script omitido.");
return;
}
var campaignIterator = AdsApp.campaigns()
.withCondition("Status = ENABLED")
.get();
var alerts = [];
while (campaignIterator.hasNext()) {
var campaign = campaignIterator.next();
var budget = campaign.getBudget();
var dailyBudget = budget.getAmount();
if (dailyBudget <= 0) {
continue;
}
var stats = campaign.getStatsFor("TODAY");
var spendToday = stats.getCost();
var spendPercent = (spendToday / dailyBudget) * 100;
if (spendPercent >= SPEND_THRESHOLD_PERCENT) {
alerts.push(
campaign.getName() + ": " + spendPercent.toFixed(1) +
"% del presupuesto diario consumido antes de las " + HOUR_THRESHOLD + "hs ($" +
spendToday.toFixed(2) + " de $" + dailyBudget.toFixed(2) + ")"
);
}
}
if (alerts.length > 0) {
var subject = "Alerta: presupuesto casi agotado antes de las " + HOUR_THRESHOLD + "hs";
var body = "Las siguientes campañas consumieron su presupuesto diario antes de tiempo:\n\n" +
alerts.join("\n");
MailApp.sendEmail(ALERT_EMAIL, subject, body);
Logger.log(body);
} else {
Logger.log("Ninguna campaña superó el umbral de consumo antes de las " + HOUR_THRESHOLD + "hs.");
}
}
Qué hace exactamente: primero valida, usando la zona horaria configurada de la cuenta (AdsApp.currentAccount().getTimeZone()), que la ejecución esté ocurriendo antes de la hora límite definida; si el script corre más tarde por cualquier motivo, se detiene sin generar una alerta fuera de contexto. Luego recorre todas las campañas activas, obtiene el presupuesto diario configurado con getBudget().getAmount() y el gasto acumulado del día con getStatsFor("TODAY").getCost(), y calcula qué porcentaje del presupuesto ya se consumió.
Por qué es útil: este script no pausa ni modifica nada — es intencionalmente de solo lectura y alerta, lo cual lo hace seguro de implementar incluso en cuentas donde todavía no hay confianza total en la automatización de escritura. Es también el primer paso natural antes de automatizar una respuesta (por ejemplo, redistribuir presupuesto entre campañas), algo que recomendamos testear manualmente varias semanas antes de delegarlo completamente a un script.
Ejemplo 4: Script de Exportación Semanal de Métricas de Performance Max a Google Sheets
A diferencia de un reporte diario simple, este script arma un reporte semanal con métricas de Performance Max por asset group, calculando ROAS y CPA directamente en el script antes de escribir la fila, y agregando encabezados automáticamente la primera vez que corre sobre una hoja vacía. Es el tipo de reporte que recomendamos para revisiones de gestión semanales, en lugar de un log diario que requiere procesamiento manual posterior.
function main() {
var SHEET_URL = "URL_DE_TU_HOJA_DE_CALCULO";
var SHEET_NAME = "Reporte Semanal PMax";
var spreadsheet = SpreadsheetApp.openByUrl(SHEET_URL);
var sheet = spreadsheet.getSheetByName(SHEET_NAME);
if (!sheet) {
sheet = spreadsheet.insertSheet(SHEET_NAME);
}
if (sheet.getLastRow() === 0) {
sheet.appendRow([
"Semana", "Campaña", "Asset Group", "Costo", "Conversiones",
"Valor de Conversión", "Clics", "Impresiones", "ROAS", "CPA"
]);
}
var query =
"SELECT campaign.name, asset_group.name, metrics.cost_micros, " +
"metrics.conversions, metrics.conversions_value, metrics.clicks, metrics.impressions " +
"FROM asset_group " +
"WHERE campaign.advertising_channel_type = 'PERFORMANCE_MAX' " +
"AND segments.date DURING LAST_7_DAYS";
var report = AdsApp.report(query);
var rows = report.rows();
var timezone = AdsApp.currentAccount().getTimeZone();
var weekOf = Utilities.formatDate(new Date(), timezone, "yyyy-MM-dd");
while (rows.hasNext()) {
var row = rows.next();
var cost = row["metrics.cost_micros"] / 1000000;
var conversions = parseFloat(row["metrics.conversions"]);
var conversionValue = parseFloat(row["metrics.conversions_value"]);
var roas = cost > 0 ? conversionValue / cost : 0;
var cpa = conversions > 0 ? cost / conversions : 0;
sheet.appendRow([
weekOf,
row["campaign.name"],
row["asset_group.name"],
cost.toFixed(2),
conversions,
conversionValue.toFixed(2),
row["metrics.clicks"],
row["metrics.impressions"],
roas.toFixed(2),
cpa.toFixed(2)
]);
}
Logger.log("Reporte semanal de Performance Max exportado correctamente.");
}
Qué hace exactamente: ejecuta una consulta GAQL sobre la vista asset_group filtrada por campañas de tipo Performance Max en los últimos 7 días, calcula ROAS (valor de conversión dividido costo) y CPA para cada asset group, y agrega una fila por asset group a una hoja de cálculo, creando el encabezado automáticamente si la hoja está vacía. A diferencia de un log diario, este formato semanal reduce el ruido de variación día a día y facilita comparar tendencias de rendimiento entre asset groups de un vistazo.
Por qué es útil: como explicamos en detalle en nuestra guía técnica completa de Performance Max, el reporte nativo de la interfaz para este tipo de campaña es limitado en comparación con Búsqueda tradicional, especialmente para analizar rendimiento por asset group a lo largo del tiempo. Complementar ese reporte nativo con una exportación automatizada y versionada en una hoja de cálculo permite construir series históricas propias que Google Ads no conserva de forma nativa más allá de cierta ventana de tiempo.
Ejemplo 5: Script de Detección de Anomalías con Desviación Estándar
Los cuatro ejemplos anteriores usan umbrales fijos definidos manualmente (30% de variación de CPA, Quality Score de 3, 90% de presupuesto consumido). Ese enfoque funciona bien para reglas simples, pero tiene una limitación: un umbral fijo no se adapta a la volatilidad natural de cada cuenta. Una cuenta con tráfico bajo y alta variabilidad diaria puede disparar falsas alarmas constantemente con un umbral fijo del 30%, mientras que una cuenta grande y estable podría necesitar un umbral mucho más sensible para detectar un problema real a tiempo.
Un enfoque estadísticamente más robusto es calcular la desviación estándar del gasto diario de los últimos 30 días y marcar como anómalo cualquier día que se aleje más de un número configurable de desviaciones estándar respecto del promedio, en lugar de usar un porcentaje fijo arbitrario.
function main() {
var STD_DEV_MULTIPLIER = 2; // días que se alejan más de 2 desvíos estándar se marcan como anómalos
var ALERT_EMAIL = "cuentas@tuagencia.com";
var dailyCosts = getDailyCostSeries(30);
if (dailyCosts.length < 10) {
Logger.log("Historial insuficiente para calcular una desviación estándar confiable.");
return;
}
var stats = calculateStats(dailyCosts);
var todayCost = dailyCosts[dailyCosts.length - 1];
var zScore = (todayCost - stats.mean) / stats.stdDev;
if (Math.abs(zScore) > STD_DEV_MULTIPLIER) {
var direction = zScore > 0 ? "por encima" : "por debajo";
var subject = "Anomalía de gasto detectada: " + AdsApp.currentAccount().getName();
var body = "El gasto de hoy ($" + todayCost.toFixed(2) + ") está " + direction +
" de lo esperado, a " + Math.abs(zScore).toFixed(2) + " desviaciones estándar del promedio de 30 días ($" +
stats.mean.toFixed(2) + ", desvío estándar $" + stats.stdDev.toFixed(2) + ").";
MailApp.sendEmail(ALERT_EMAIL, subject, body);
Logger.log(body);
} else {
Logger.log("Gasto de hoy dentro del rango esperado (z-score: " + zScore.toFixed(2) + ")");
}
}
function getDailyCostSeries(days) {
var query =
"SELECT segments.date, metrics.cost_micros " +
"FROM customer " +
"WHERE segments.date DURING LAST_" + days + "_DAYS " +
"ORDER BY segments.date ASC";
var report = AdsApp.report(query);
var rows = report.rows();
var costByDate = {};
while (rows.hasNext()) {
var row = rows.next();
var date = row["segments.date"];
var cost = row["metrics.cost_micros"] / 1000000;
costByDate[date] = (costByDate[date] || 0) + cost;
}
return Object.keys(costByDate).sort().map(function (date) {
return costByDate[date];
});
}
function calculateStats(values) {
var n = values.length;
var mean = values.reduce(function (sum, v) { return sum + v; }, 0) / n;
var variance = values.reduce(function (sum, v) { return sum + Math.pow(v - mean, 2); }, 0) / n;
return { mean: mean, stdDev: Math.sqrt(variance) };
}
Qué hace exactamente: la función getDailyCostSeries() arma una serie de gasto diario agregado a nivel de cuenta durante los últimos 30 días a partir de una consulta GAQL sobre customer, agrupando por fecha. calculateStats() calcula el promedio y el desvío estándar de esa serie, y main() compara el gasto del día actual (el último valor de la serie) contra ese promedio, expresando la distancia en términos de z-score (número de desvíos estándar de diferencia) en lugar de un porcentaje fijo.
Por qué es útil: este patrón es exactamente el tipo de lógica que mencionamos en la sección de IA generativa como "detección de anomalías": no depende de un umbral arbitrario elegido a mano, sino que se adapta automáticamente a la volatilidad histórica real de cada cuenta. Es también la base natural sobre la que se puede construir una capa adicional de análisis con un modelo de lenguaje: exportar esta misma serie de datos a una hoja de cálculo y pedirle a un modelo de IA que identifique patrones de cambio de tendencia sostenido (no solo picos puntuales de un día), algo que un cálculo de desvío estándar simple no captura bien por sí solo.
Cómo Elegir Entre Regla Nativa, Script Propio o Integración vía API
Con los cinco ejemplos de código de esta guía como referencia, vale la pena resumir un criterio simple de decisión para no sobredimensionar (ni subdimensionar) la solución técnica frente a una necesidad de automatización concreta:
Si la condición es una sola variable con un umbral fijo simple ("pausar si CTR menor a 1%", "subir presupuesto si impression share perdido por presupuesto supera 20%"), una regla automatizada nativa alcanza y no requiere mantenimiento de código.
Si la lógica combina múltiples métricas, múltiples períodos de comparación, o necesita exportar datos a un sistema externo, como los cinco ejemplos de esta guía, un script propio es la herramienta correcta: corre dentro de la infraestructura de Google sin necesidad de servidores propios, y cubre prácticamente cualquier lógica condicional que se pueda expresar en JavaScript.
Si la necesidad es correr con una frecuencia menor a una hora, construir un producto de gestión multicuenta con interfaz propia, o integrar Google Ads con sistemas internos complejos de forma bidireccional, la Google Ads API es la herramienta apropiada, aceptando el costo de mantener infraestructura propia a cambio de eliminar el límite de 30 minutos por ejecución y el piso de una hora entre corridas.
En Old Fox, la gran mayoría de las cuentas que gestionamos resuelven el 100% de sus necesidades de automatización con una combinación de reglas nativas para condiciones simples y scripts propios para lógica compleja, y recién recomendamos evaluar una integración vía API cuando el volumen de cuentas gestionadas o la necesidad de tiempo real lo justifica claramente frente al costo de mantenimiento de infraestructura propia.
Otros Casos de Uso de Automatización que Resolvemos con Scripts
Más allá de los cinco ejemplos de código completo de esta guía, estos son otros patrones de automatización frecuentes que implementamos en cuentas de clientes, y que podés adaptar con la misma estructura de main() y AdsApp que ya vimos:
Minería automática de palabras clave negativas desde el informe de términos de búsqueda. Un script que revisa semanalmente el reporte de términos de búsqueda, identifica consultas con gasto acumulado por encima de un umbral y cero conversiones en un período extendido, y las agrega automáticamente como negativas a nivel de grupo de anuncios o campaña, evitando que el equipo tenga que revisar manualmente ese reporte cada semana.
Alerta de anuncios o extensiones rechazados. Un script diario que revisa el estado de aprobación de anuncios y extensiones, y notifica inmediatamente si alguno pasa a estado "rechazado" o "en revisión" durante más de 48 horas, algo que de otra forma solo se detecta al revisar manualmente la interfaz.
Pacing de presupuesto mensual. Un script que compara el gasto acumulado del mes contra el ritmo esperado según el día del mes en curso, alertando tanto si el ritmo de gasto está muy por encima (riesgo de agotar el presupuesto antes de fin de mes) como muy por debajo (riesgo de terminar el mes sin invertir el presupuesto asignado).
Reactivación estacional condicionada a variables externas. En cuentas de retail físico, scripts que activan o pausan campañas geográficas específicas según variables externas consultadas vía UrlFetchApp (por ejemplo, un servicio de clima, o el estado de stock de un sistema de inventario propio), reduciendo gasto en campañas de productos o servicios afectados por condiciones externas cambiantes.
Sincronización de exclusiones de audiencia entre cuentas de una misma MCC. En grupos empresariales con múltiples cuentas que comparten una misma base de exclusión (por ejemplo, listas de clientes actuales que no deben recibir campañas de adquisición), un script que corre a nivel MCC y sincroniza esas exclusiones entre cuentas cliente, evitando el mantenimiento manual duplicado cuenta por cuenta.
Cómo la IA Generativa se Integra en la Automatización de Google Ads
La inteligencia artificial generativa cambió de forma concreta cómo se escriben, mantienen y complementan los scripts de Google Ads en los últimos dos años. No se trata de una integración nativa de Google Ads con un modelo de lenguaje dentro del editor de scripts (eso todavía no existe de forma oficial), sino de un cambio en el flujo de trabajo de quienes escriben y mantienen scripts. Estas son las aplicaciones concretas que vemos hoy:
Generación asistida de código. Herramientas como ChatGPT, Claude o Gemini son hoy el punto de partida habitual para escribir un script nuevo: describís la lógica de negocio en lenguaje natural ("quiero pausar keywords con Quality Score menor a 4 que tengan más de 200 clics en 30 días") y el modelo genera una primera versión funcional del código, que después hay que revisar, adaptar a la estructura de cuenta específica y testear en modo de solo lectura antes de darle permisos de escritura. Esto redujo drásticamente el tiempo de desarrollo de scripts simples y medianos, pero no elimina la necesidad de revisión técnica humana: un modelo de lenguaje puede generar código que compila y corre sin errores pero que aplica una lógica de negocio incorrecta o insegura si el prompt original no fue lo suficientemente específico.
Traducción de reglas de negocio en lenguaje natural a lógica ejecutable. Cada vez es más común que el equipo de marketing (sin conocimiento de programación) redacte la regla de negocio en español simple —"si una campaña gasta más del 90% de su presupuesto antes del mediodía, avisame"— y que un desarrollador o un modelo de IA generativa traduzca esa regla a código funcional, iterando sobre el prompt hasta que la lógica generada coincide exactamente con la intención de negocio. Este flujo democratizó el acceso a la automatización: hoy no hace falta que quien define la regla de negocio sepa escribir JavaScript, aunque sigue siendo indispensable que alguien con criterio técnico revise el código antes de producción.
Detección de anomalías en datos exportados. Una vez que un script exporta métricas a una hoja de cálculo o una base de datos externa (como el ejemplo semanal de Performance Max de esta guía), es habitual conectar esos datos a un modelo de IA —vía la API de un proveedor de LLM, o funciones nativas de Google Sheets con extensiones de IA— para detectar patrones anómalos que una alerta de umbral fijo no captura: por ejemplo, un asset group que crece en gasto de forma sostenida sin que las conversiones acompañen ese crecimiento durante varias semanas consecutivas, un patrón más difícil de capturar con una simple regla de "si X supera Y" pero perfectamente identificable para un modelo entrenado en series temporales o mediante un prompt bien diseñado sobre los datos exportados.
Redacción de resúmenes ejecutivos automáticos. Algunas cuentas ya combinan el reporte exportado por script con una llamada a un modelo de lenguaje que genera un resumen ejecutivo en texto plano de los cambios de la semana, reduciendo el tiempo que un gerente de marketing necesita para interpretar una planilla de números.
Es importante ser precisos sobre los límites reales de esta integración: la IA generativa asiste en la escritura y el análisis, pero no ejecuta scripts de forma autónoma dentro de Google Ads ni reemplaza el criterio humano en decisiones de pausado o cambio de presupuesto que impactan dinero real. El patrón que recomendamos, y que profundizamos en nuestro artículo sobre el futuro del performance marketing con IA, es usar IA generativa como acelerador de desarrollo y como capa de análisis adicional sobre datos ya extraídos, manteniendo siempre una capa de revisión humana antes de que cualquier acción automatizada impacte presupuesto real.
Límites Técnicos y de Cuota de Google Ads Scripts
Antes de diseñar automatización a escala, es indispensable conocer los límites técnicos reales de la plataforma, porque varios de ellos determinan directamente qué arquitectura de script es viable y cuál no:
Tiempo máximo de ejecución: 30 minutos por script, en cuenta individual. Si un script no termina de ejecutarse dentro de ese margen, Google lo interrumpe automáticamente, dejando cualquier operación de escritura pendiente sin ejecutar. Esto es especialmente relevante en cuentas grandes con miles de keywords o productos: iterar entidad por entidad con selectores nativos (AdsApp.keywords().get()) es mucho más lento que ejecutar una consulta agregada en GAQL vía AdsApp.report(), por lo que recomendamos priorizar reportes sobre iteradores cuando el volumen de datos es alto.
Frecuencia mínima de ejecución: una hora. No es posible programar un script para correr con mayor frecuencia que cada 60 minutos desde la interfaz nativa de programación. Para monitoreo en tiempo casi real, la única alternativa es una integración vía API con infraestructura propia de scheduling.
Cuentas MCC: hasta 6 horas de ejecución acumulada distribuidas entre cuentas cliente. Cuando un script corre a nivel de cuenta administradora (MCC) usando executeInParallel() sobre múltiples cuentas cliente, el límite de 30 minutos aplica por cuenta individual dentro del lote, pero el tiempo total acumulado de ejecución del script sobre el conjunto de cuentas puede extenderse considerablemente más allá de ese margen individual, dependiendo de cuántas cuentas se procesen en paralelo.
Cuotas de envío de email. MailApp.sendEmail(), al correr sobre la infraestructura de Google Apps Script, está sujeto a cuotas diarias de envío de correo compartidas con otros scripts de Apps Script asociados a la misma cuenta de Google, lo cual rara vez es un problema para alertas puntuales pero puede convertirse en un cuello de botella si se diseñan decenas de alertas independientes que se disparan con alta frecuencia.
Límites de llamadas a servicios externos vía UrlFetchApp. Si el script necesita comunicarse con una API externa (por ejemplo, para enviar datos a un sistema propio o consultar un modelo de IA), esas llamadas también están sujetas a cuotas diarias del entorno de Apps Script, además de cualquier límite propio del servicio externo consultado.
No hay persistencia nativa entre ejecuciones. Como mencionamos antes, cada corrida de un script es independiente; cualquier lógica que dependa de "recordar" el estado de una ejecución anterior necesita almacenamiento explícito, ya sea en PropertiesService, una hoja de cálculo o una base de datos externa.
Errores Comunes al Escribir e Implementar Scripts
En auditorías técnicas de cuentas que ya usan Google Ads Scripts, encontramos con mucha frecuencia los mismos patrones de error, algunos triviales de corregir y otros con potencial real de dañar el rendimiento de la cuenta:
1. No manejar cuotas ni límites de ejecución. Scripts escritos para cuentas pequeñas que se rompen silenciosamente al escalar a cuentas con miles de entidades, porque iteran entidad por entidad en lugar de usar reportes agregados en GAQL, superando el límite de 30 minutos sin que nadie lo note hasta que el reporte deja de actualizarse.
2. Scripts que fallan silenciosamente sin alertas. La causa más frecuente de "por qué el script dejó de funcionar hace tres semanas y nadie se dio cuenta": ausencia total de manejo de errores (try/catch) y de notificación cuando el script falla. Un script bien diseñado siempre debería notificar por email cuando su propia ejecución falla, no solo cuando detecta una anomalía en los datos de la cuenta.
3. Lógica de pausado agresiva sin salvaguardas. Scripts que pausan keywords, anuncios o campañas completas sin un límite máximo de entidades afectadas por ejecución. Si un error de lógica hace que la condición de pausado se cumpla para el 80% de la cuenta en una sola corrida, sin ese límite de seguridad el script pausa efectivamente toda la cuenta de un plumazo.
4. No versionar los scripts. Editar el código directamente en el editor nativo de Google Ads sin mantener un historial de cambios en un repositorio externo (git, aunque sea uno simple) hace imposible identificar qué cambio introdujo un bug, o revertir a una versión anterior funcional cuando algo sale mal.
5. Ejecutar cambios estructurales sin testing previo en modo de solo lectura. Desplegar directamente la versión con permisos de escritura de un script nuevo, sin correrlo primero durante días o semanas en un modo que solo registre (Logger.log) qué acciones tomaría sin ejecutarlas realmente. Esta práctica de "dry-run" es la salvaguarda más simple y más frecuentemente ignorada.
6. Hardcodear IDs y valores sensibles directamente en el código. URLs de hojas de cálculo, direcciones de email de alerta o umbrales de negocio escritos como literales dentro del script, en lugar de variables de configuración claramente identificadas al inicio del archivo, dificultan el mantenimiento y aumentan el riesgo de error al adaptar el script a otra cuenta.
7. No considerar la zona horaria de la cuenta. Comparar fechas usando la zona horaria del servidor de ejecución en lugar de AdsApp.currentAccount().getTimeZone(), lo cual genera resultados inconsistentes en cuentas cuya zona horaria no coincide con la del entorno de ejecución de Apps Script.
8. Confundir rangos de fecha predefinidos. Usar LAST_7_DAYS asumiendo que incluye el día de hoy cuando en realidad corresponde a los siete días anteriores completos, generando comparaciones erróneas entre "hoy" y "el promedio reciente" si no se valida explícitamente qué días abarca cada rango.
Buenas Prácticas de Seguridad y Control de Cambios Antes de Dar Permisos de Escritura
Dar permisos de escritura a un script —es decir, permitirle pausar, activar o modificar presupuestos y pujas de forma autónoma— es una decisión que debería tomarse con el mismo nivel de rigor que dar acceso de administrador a una persona nueva en el equipo. Estas son las prácticas que aplicamos en Old Fox antes de habilitar cualquier script en modo de escritura sobre una cuenta de cliente:
Modo de solo lectura obligatorio durante al menos dos semanas. Todo script nuevo corre primero registrando en log o en una hoja de cálculo qué acción tomaría, sin ejecutar ningún cambio real, permitiendo validar que la lógica se comporta como se espera antes de exponer presupuesto real al riesgo.
Límite máximo de entidades afectadas por ejecución. Ningún script de pausado o modificación debería poder afectar más de un número acotado de entidades en una sola corrida (por ejemplo, un máximo de 20 keywords pausadas por ejecución), de forma que un error de lógica no pueda desactivar la cuenta completa de una sola vez.
Registro de auditoría de cada acción tomada. Cada vez que un script ejecuta una acción de escritura, debería quedar un registro (en una hoja de cálculo o log externo) de qué se cambió, cuándo y bajo qué condición, para poder reconstruir el historial de decisiones automatizadas si algo sale mal.
Alertas obligatorias ante cualquier acción de escritura, no solo ante anomalías. Un script que pausa 15 keywords silenciosamente, sin notificar a nadie, es un riesgo de gobernanza incluso si la lógica es correcta: el equipo humano siempre debería enterarse de qué cambios automatizados se ejecutaron.
Control de acceso sobre quién puede editar scripts en producción. En cuentas MCC con múltiples usuarios, restringir quién tiene permiso de editar directamente el código de scripts en producción, versionando cualquier cambio antes de desplegarlo.
Revisión de código antes de cada despliegue, incluso para cambios generados por IA. Como mencionamos en la sección anterior sobre IA generativa, ningún script generado por un modelo de lenguaje debería pasar a producción sin revisión humana explícita, sin importar cuán simple parezca la lógica solicitada.
Plan de rollback definido de antemano. Antes de habilitar un script con permisos de escritura, tener claro cómo revertir manualmente sus efectos (reactivar keywords pausadas, restaurar presupuestos anteriores) si el script produce un resultado no deseado.
Este mismo nivel de rigor es el que aplicamos al automatizar cualquier proceso que hoy forma parte de nuestra checklist de auditoría técnica de cuentas de Google Ads: la automatización acelera la detección de problemas, pero nunca debería reemplazar la validación humana antes de una acción que impacta presupuesto real.
Auditá la Automatización de tu Cuenta →
Glosario Técnico de Google Ads Scripts
| Término | Definición |
|---|---|
AdsApp |
Objeto global que expone la API de Google Ads Scripts dentro de una cuenta individual |
AdsManagerApp |
Objeto equivalente a AdsApp para scripts que corren a nivel de cuenta MCC (administradora) |
| GAQL | Google Ads Query Language, el lenguaje de consulta usado en AdsApp.report() para extraer métricas agregadas |
| Selector | Mecanismo de AdsApp (por ejemplo AdsApp.keywords()) que permite filtrar y recorrer entidades de la cuenta |
executeInParallel() |
Método de scripts MCC que ejecuta la misma lógica sobre múltiples cuentas cliente de forma simultánea |
PropertiesService |
Servicio de Apps Script usado para persistir datos entre ejecuciones distintas de un mismo script |
| Dry-run | Modo de ejecución de solo lectura donde el script registra qué acción tomaría sin ejecutarla realmente |
Logger.log() |
Función usada para registrar mensajes de depuración visibles en el historial de ejecuciones del script |
MailApp |
Servicio nativo de Apps Script usado para el envío de emails de alerta desde un script |
| Trigger | Configuración de programación que define con qué frecuencia se ejecuta un script de forma automática |
Ejemplos Reales: Resultados con Automatización de Scripts en Cuentas de Old Fox
Una cuenta de ecommerce de indumentaria que gestiona presupuestos elevados durante eventos de alta estacionalidad implementó el script de alerta de variación de CPA descripto en esta guía durante un Hot Sale: el tiempo de detección de una anomalía de costo pasó de un promedio de 3 días (revisión manual periódica) a 4 horas, lo que permitió pausar una campaña con configuración incorrecta de puja antes de que erosionara una porción significativa del presupuesto extraordinario asignado al evento, evitando un gasto ineficiente estimado en 14% del presupuesto total del período.
Una empresa de servicios B2B con más de 3.000 keywords activas implementó el script de pausado automático por Quality Score bajo sostenido, con las salvaguardas de límite de entidades por ejecución descriptas en esta guía: en 45 días, el Quality Score promedio de la cuenta subió de 4.2 a 6.8, y el CPC promedio de las campañas afectadas se redujo un 23%, liberando presupuesto que se redistribuyó hacia keywords de mejor rendimiento sin necesidad de intervención manual diaria por parte del equipo de cuentas.
Una cadena retail que gestiona 14 cuentas cliente bajo una misma estructura MCC implementó el script de monitoreo de presupuesto agotado antes de las 12hs, corriendo simultáneamente sobre las 14 cuentas vía executeInParallel(), durante un evento de Hot Sale regional: el monitoreo automatizado permitió detectar y corregir en tiempo real 5 sedes cuyo presupuesto se agotaba sistemáticamente antes del mediodía, perdiendo visibilidad durante las horas de mayor tráfico de la tarde; al redistribuir presupuesto entre sedes según el patrón detectado, los ingresos totales capturados durante el evento crecieron 18% sin aumentar la inversión publicitaria total del grupo.
Cómo Old Fox Usa Automatización e IA en la Gestión de Cuentas
En Old Fox llevamos más de una década gestionando cuentas de Google Ads, y la automatización vía scripts es hoy parte integral de cómo monitoreamos y protegemos el presupuesto de cada cliente, no un complemento opcional. Nuestro proceso combina scripts propios desarrollados y mantenidos internamente, revisión de código sistemática antes de cualquier despliegue en modo de escritura, e integración de IA generativa como acelerador de desarrollo y capa de análisis adicional sobre los datos que nuestros scripts exportan diariamente.
Como Google Premier Partner Top 3% del país, mantenemos acceso directo al equipo técnico de Google, lo cual nos permite anticipar cambios en la API de Google Ads Scripts y en GAQL antes de que afecten la estabilidad de nuestros scripts en producción.
Con más de 130 cuentas activas en Latinoamérica y un ROAS promedio de 4.5x, aplicamos la misma disciplina de automatización con salvaguardas a cuentas de ecommerce, generación de leads B2B y negocios locales con presencia física: todo script que gestionamos para un cliente pasa primero por un período de solo lectura, queda documentado en un repositorio interno versionado, y cuenta con alertas automáticas ante cualquier fallo silencioso de ejecución, exactamente el mismo estándar que describimos a lo largo de esta guía.
Nuestro proceso de onboarding para automatización en una cuenta nueva empieza siempre por un relevamiento de qué reglas de negocio ya existen como automatizaciones nativas o reglas manuales del cliente, para evitar duplicar lógica o generar condiciones contradictorias entre un script nuevo y una regla automatizada preexistente. Solo después de ese relevamiento diseñamos qué automatización conviene resolver con Scripts, cuál con reglas nativas, y cuál —en cuentas de mayor escala— eventualmente justifica una integración vía API.
Nuestros Servicios de Automatización y Scripts para Google Ads
Auditoría técnica de scripts existentes. Revisamos la lógica, las salvaguardas de seguridad y el manejo de errores de cualquier script que ya esté corriendo en tu cuenta, identificando riesgos de fallo silencioso o de pausado agresivo sin control.
Desarrollo de scripts personalizados de monitoreo y alertas. Diseñamos e implementamos scripts de alerta de variación de métricas, monitoreo de presupuesto y detección temprana de anomalías, adaptados a los KPIs específicos de tu negocio.
Implementación de dashboards automatizados en Google Sheets. Exportamos métricas de campañas, asset groups y productos a hojas de cálculo estructuradas para revisión ejecutiva semanal o mensual.
Automatización de reglas de pausado con salvaguardas de seguridad. Implementamos lógica de pausado condicional con límites de entidades afectadas, modo de solo lectura previo y alertas obligatorias ante cada acción ejecutada.
Integración de IA generativa para análisis de datos exportados. Conectamos los datos que nuestros scripts exportan a modelos de lenguaje para detección de anomalías y generación de resúmenes ejecutivos automáticos.
Gestión de scripts a escala en cuentas MCC multi-cuenta. Implementamos automatización simultánea sobre decenas de cuentas cliente usando executeInParallel(), con reportes consolidados a nivel de grupo.
Documentación y control de versiones de scripts. Versionamos todo el código de automatización en un repositorio propio, con historial de cambios y capacidad de rollback ante cualquier comportamiento inesperado.
Capacitación interna de equipos en Google Ads Scripts. Entrenamos a equipos internos de marketing en la lectura y mantenimiento básico de scripts existentes, para reducir la dependencia de terceros en mantenimiento rutinario.
Si querés entender primero cómo está la salud técnica general de tu cuenta antes de sumar automatización, te recomendamos empezar por una auditoría gratuita de Google Ads: automatizar reglas sobre una cuenta con problemas estructurales de tracking o de estructura de campañas solo automatiza el error, no lo corrige.
Preguntas Frecuentes sobre Google Ads Scripts y Automatización
¿Necesito saber programar para usar Google Ads Scripts?
Sí, es necesario un conocimiento básico de JavaScript para escribir y mantener scripts propios, aunque hoy es común usar herramientas de IA generativa como punto de partida para generar una primera versión del código, que igual requiere revisión técnica antes de implementarse en producción.
¿Los scripts de Google Ads tienen algún costo adicional?
No, Google Ads Scripts es una funcionalidad nativa e incluida sin costo adicional dentro de cualquier cuenta de Google Ads. El costo real está en el tiempo de desarrollo y mantenimiento, no en una tarifa de la plataforma.
¿Cuál es la diferencia entre Google Ads Scripts y la Google Ads API?
Scripts corre dentro de la infraestructura de Google, con un límite de 30 minutos de ejecución por cuenta y sin necesidad de servidores propios. La API requiere una aplicación propia con su infraestructura, autenticación OAuth y mantenimiento, pero no tiene ese límite de tiempo y permite construir productos completos de gestión multicuenta.
¿Puedo programar un script para que corra cada 5 minutos?
No. La frecuencia mínima de ejecución programada desde la interfaz nativa de Google Ads es de una hora. Para monitoreo con mayor frecuencia se necesita una integración externa vía API.
¿Qué pasa si mi script falla a mitad de ejecución?
Si no implementaste manejo de errores (try/catch) ni alertas de fallo, el script simplemente se detiene sin que nadie se entere, dejando cualquier acción pendiente sin ejecutar. Por eso recomendamos que todo script notifique explícitamente cuando su propia ejecución falla.
¿Es seguro dejar que un script pause keywords o campañas automáticamente?
Es seguro únicamente si se implementan salvaguardas: límite máximo de entidades afectadas por ejecución, período previo de solo lectura, y alertas obligatorias ante cada acción tomada. Sin esas salvaguardas, un error de lógica puede pausar una porción significativa de la cuenta sin que nadie lo note a tiempo.
¿Los scripts funcionan igual en cuentas MCC que en cuentas individuales?
No exactamente. En cuentas individuales se usa el objeto AdsApp; en cuentas MCC se usa AdsManagerApp, que permite iterar sobre cuentas cliente y ejecutar la misma lógica en paralelo sobre múltiples cuentas con executeInParallel().
¿Puedo usar Google Ads Scripts para exportar datos a un sistema propio, fuera de Google Sheets?
Sí, usando UrlFetchApp es posible enviar datos a cualquier API externa que acepte solicitudes HTTP, sujeto a las cuotas diarias de llamadas externas del entorno de Apps Script.
¿La inteligencia artificial puede escribir scripts completos sin revisión humana?
Puede generar una primera versión funcional a partir de una descripción en lenguaje natural, pero no recomendamos desplegar en producción ningún script generado por IA sin revisión técnica humana previa, especialmente si el script tiene permisos de escritura sobre presupuesto o estructura de campaña.
¿Qué diferencia hay entre un script y una regla automatizada nativa de Google Ads?
Las reglas automatizadas nativas cubren condiciones simples de una sola variable sin necesidad de código. Los scripts permiten lógica condicional arbitrariamente compleja, comparaciones entre múltiples períodos, exportación de datos y automatización a escala MCC, a costa de requerir conocimiento de programación.
¿Cómo sé si mi cuenta necesita scripts o si las reglas automatizadas nativas alcanzan?
Si la lógica de negocio se puede expresar como una sola condición simple ("pausar si X supera Y"), una regla automatizada nativa alcanza. Si necesitás combinar múltiples métricas, comparar períodos de tiempo, exportar datos a un sistema externo o replicar la lógica sobre múltiples cuentas, necesitás scripts.
¿Qué pasa si cambio de agencia o de gestor de cuenta y hay scripts corriendo?
Es fundamental que la documentación y el código fuente de cualquier script en producción quede accesible para quien tome la gestión de la cuenta después. La ausencia de documentación de scripts activos es un problema recurrente que encontramos en auditorías de cuentas que cambiaron de agencia sin ese traspaso de información.
¿Los scripts pueden modificar pujas manuales o solo pausar entidades?
Pueden modificar prácticamente cualquier atributo editable de una entidad, incluyendo pujas manuales, presupuestos de campaña y estados de activación, siempre que el tipo de estrategia de puja de la campaña lo permita (las estrategias de Smart Bidding no admiten ajuste manual de puja por keyword, por ejemplo).
¿Con qué frecuencia hay que revisar y actualizar los scripts existentes?
Recomendamos una revisión trimestral como mínimo, dado que Google actualiza periódicamente la sintaxis de GAQL y los métodos disponibles en AdsApp, y un script que funcionaba correctamente puede dejar de hacerlo silenciosamente tras un cambio de la plataforma si no se monitorea activamente.
¿Vale la pena migrar de AWQL a GAQL en scripts antiguos?
Sí, es altamente recomendable. AWQL fue el lenguaje de consulta original de Google Ads Scripts pero está en proceso de deprecación progresiva a favor de GAQL, que además ofrece acceso a campos y recursos más recientes de la plataforma, incluyendo los necesarios para reportar sobre Performance Max y otros formatos modernos de campaña.
¿Un script puede usar un umbral fijo y uno estadístico (desviación estándar) al mismo tiempo?
Sí, y de hecho lo recomendamos en cuentas maduras: un umbral fijo simple para condiciones de negocio no negociables (por ejemplo, "nunca gastar más del presupuesto mensual aprobado") combinado con un umbral estadístico basado en desviación estándar para detectar anomalías de comportamiento que un porcentaje fijo no captura bien, como mostramos en el ejemplo de detección de anomalías de esta guía.
¿Qué pasa si dos scripts distintos intentan modificar la misma entidad al mismo tiempo?
Google Ads Scripts no garantiza bloqueo (locking) entre ejecuciones simultáneas de scripts distintos, por lo que si dos scripts programados corren en paralelo y ambos intentan modificar la misma campaña o keyword, puede producirse una condición de carrera con resultado impredecible. Recomendamos evitar superposición de horarios entre scripts que escriben sobre las mismas entidades, y centralizar la lógica de escritura en un único script cuando sea posible.
¿Cómo pruebo un script antes de dar permisos de escritura en una cuenta de cliente real?
La práctica que aplicamos en Old Fox es correr toda nueva lógica primero en modo dry-run (registrando en log o en una hoja de cálculo qué acción tomaría, sin ejecutarla), durante al menos dos semanas, y —cuando la cuenta lo permite— validar además sobre una cuenta de prueba con datos representativos antes de habilitar escritura sobre la cuenta de producción del cliente.
Llevá la Automatización de tu Cuenta al Siguiente Nivel
Google Ads Scripts es, hoy por hoy, la herramienta más versátil dentro del ecosistema nativo de Google Ads para quienes gestionan cuentas con volumen y complejidad reales: permite detectar problemas antes de que erosionen presupuesto, liberar horas de trabajo manual repetitivo, y construir reportes que la interfaz nativa simplemente no ofrece. Pero como mostramos a lo largo de esta guía, la diferencia entre un script que protege una cuenta y uno que la daña casi nunca está en la sintaxis del código, sino en las salvaguardas de seguridad, el testing previo en modo de solo lectura, y la disciplina de revisión humana antes de otorgar permisos de escritura.
En Old Fox auditamos automatización de cuentas todas las semanas, y encontramos con la misma frecuencia scripts mal diseñados que scripts ausentes donde claramente harían falta. La combinación correcta de IA generativa para acelerar el desarrollo, código propio versionado y revisado, y salvaguardas explícitas de seguridad es lo que separa la automatización que efectivamente mejora resultados de la que simplemente traslada el riesgo de un error humano a un error de código que corre sin supervisión.
Si querés saber si tu cuenta ya tiene automatización mal implementada, o si simplemente no sabés por dónde empezar a automatizar el monitoreo de tus campañas, pedí una auditoría gratuita. La entregamos en 48 horas, sin compromiso.
Para profundizar en cómo se estructura y optimiza el tipo de campaña que más se beneficia de monitoreo automatizado, te recomendamos también nuestra guía completa de Performance Max, y si tu foco está en entender cómo funciona la puja automatizada detrás de las campañas que monitoreás con scripts, nuestra guía de Smart Bidding y puja automatizada te va a dar el marco técnico complementario. También podés revisar nuestra nota sobre optimización de pujas en Google Ads para entender cómo se combinan puja manual, Smart Bidding y automatización propia en una misma cuenta.
