Hace unas semanas conté cómo había montado un sistema que genera y aplica palabras clave negativas en Google Ads de forma automática.
¿Cómo funciona?
- Un Sheet como fuente de verdad,
- un script que decide qué búsquedas son basura y cuáles no,
- y una tarea programada que lo dejaba todo corriendo sin que nadie tuviera que acordarse.
Funcionaba. El problema es que «funcionaba» tenía una letra pequeña: funcionaba mientras mi portátil estuviera encendido.
Esa dependencia se notaba rápido. Un día que se me olvidaba encenderlo, o que se iba a dormir a media tarde, las ejecuciones simplemente no pasaban y nadie se enteraba hasta que alguien miraba el gasto de la semana y veía un hueco raro.
Así que el siguiente paso no era mejorar la lógica de negativización, era quitarle al proceso entero la dependencia de una máquina concreta.
Sacar el proceso del portátil y meterlo en la nube
La tarea programada de Windows se convirtió en un Cloud Scheduler de Google Cloud, y el script que corría en local se convirtió en Cloud Functions. Mismo cerebro, mismas reglas, pero ejecutándose en un sitio que no se apaga nunca.
El Sheet sigue siendo la fuente de verdad — eso no cambió — pero ahora quien escribe en él es una función que vive en la nube, no un proceso que depende de que yo me acuerde de dejar el ordenador encendido.
No fue un cambio de un día. Empecé portando con Claude la pieza que menos duele si algo sale mal — un aviso por Telegram que detecta picos de gasto raros — y fui subiendo una a una el resto de tareas que tenía en local: la que genera las listas de negativas, la que compara los cambios de un día para otro, la que audita si las reglas se están aplicando de verdad en Ads, la que manda el resumen diario.
Cada una a su hora, y cada una validada comparando su salida contra la del script antiguo antes de apagar la versión local. Migrar sin fe, línea a línea.
El punto flaco que no había resuelto: las campañas por comunidad autónoma
La cuenta de formación sanitaria tiene una campaña por comunidad autónoma — Madrid, Andalucía, Aragón, y así hasta catorce. La idea es simple: quien busca «oposiciones radiodiagnóstico Madrid» debería caer en la campaña de Madrid, no en la genérica nacional. El problema es que el propio sistema de negativización, aplicado sin matices, se comía sus propias búsquedas buenas.
La primera versión de la regla protegía cualquier búsqueda que llevara el nombre de la región, a secas. Sonaba razonable y estaba mal: colaba basura real (una búsqueda de una academia de barrio que solo compartía el nombre de la ciudad) y protegía búsquedas que debían quedar fuera por política propia, como las de un curso concreto que ya no promocionamos por bajo rendimiento. Proteger solo por el nombre de la región era una malla demasiado ancha.
El ajuste fue exigir dos condiciones a la vez, no una: la región Y el rol o la especialidad. «Radiodiagnóstico Madrid» queda protegida, «Madrid» sola ya no. Con esa combinación las búsquedas basura vuelven a caer bajo la negativización y las que sí son intención real de una especialidad en esa comunidad se quedan intactas.
Un poco lío. Sí. 🙂
Nada de esto se hace a ojo ni una sola vez. Hay un dashboard que vigila las catorce campañas a diario y cruza dos cosas: qué búsquedas se están dejando fuera del sistema de negativización dentro de cada comunidad, y si ese hueco se traduce en gasto real «fugado» hacia la campaña general. Le llamo «Radar CCAA».
Cuando detecta algo, avisa mientras todavía es un problema pequeño, en vez de cuando ya se ha comido medio presupuesto del mes. 😉
Septiembre: se anima el sector y hay muchas más palabras que parar
Con septiembre entra en juego una variable que en verano apenas se nota: el sector de las oposiciones se reactiva. Puede haber nuevas convocatorias, la gente viene del verano con ganas, vuelve el volumen de búsqueda, y con el volumen vuelve mucha más variedad de búsquedas raras que en agosto ni aparecían.
La negativización tiene que trabajar más, no porque el sistema esté peor, sino porque hay muchas más palabras nuevas que aparecen y que hay que decidir si parar o no.
Esto abre una brecha real entre lo que el sistema ya sabe filtrar y lo que todavía no ha visto nunca.
- En temporada baja, la lista de negativas está prácticamente estable porque casi no entran búsquedas nuevas.
- En temporada alta, cada día trae términos que no estaban la semana anterior, y el margen entre «lo detecto hoy» y «lo detecto dentro de tres días» empieza a costar dinero de verdad.
Aquí es donde se nota si el sistema corre solo o si depende de que alguien se acuerde de mirarlo — y es justo la costura que quedó resuelta al sacarlo del portátil.
Lo que se ve en los números: menos impresiones, los mismos clics
Lo que más me convence de que esto funciona es la forma que toma el cambio, más que el ahorro en sí. Comparando el mismo periodo del año anterior, las impresiones bajan con claridad, porque hay muchas menos búsquedas irrelevantes activando el anuncio, y los clics apenas se mueven.
Vemos primero las impresiones, en media móvil 30 días, desde la implementación del cambio. En gris el año pasado.
Ese hueco entre las dos curvas es justo el presupuesto que antes se iba en gente que nunca iba a hacer clic ni a convertir.
Ahora los clics, salvo la bajada natural del verano, se ve cómo «no se mueven».
La consecuencia directa es que el CTR sube, y eso no es un número cosmético para un informe.
En nuestro caso, en Google Ads un mejor CTR alimenta el nivel de calidad, y un mejor nivel de calidad tira del ROAS para arriba. Por lo que muestran los datos, la negativización está recortando exactamente la parte que sobraba, no alcance a lo tonto.
Nada de esto salió perfecto a la primera. Hubo reglas que protegían de menos y otras que negativizaban de más, y las fui afinando según lo que mostraban los datos reales, no según lo que parecía razonable sobre el papel.
Pero con la parte de infraestructura resuelta — que corra sola, todos los días, sin depender de mi portátil — lo único que queda por hacer es seguir afinando la puntería. Y esa parte, con septiembre apretando, no va a parar de tener trabajo.
