En resumen: La automatización del PPC no pasó a ser posible de repente. Pasó a ser asequible. La IA no añadió capacidades; desplomó el periodo de amortización de las que teníamos desde 2019 y convirtió desarrollos de seis meses en desarrollos de dos semanas. Ganan los súper-seniors que por fin pueden montar los flujos que antes nunca compensaban, como limpiar miles de consultas basura con un modelo que corre en un PC normal.
Una vez vi a nuestro arquitecto de sistemas, un hombre con veinticinco años de ingeniería a la espalda, pasarse dos días enteros leyendo la documentación de la Google Ads API antes de que una sola consulta devolviera datos. Dos días, una consulta. Es el mejor ingeniero que conozco, y aun así le llevó dos días. Esa era, sencillamente, la entrada que cobraba la plataforma a cualquiera que quisiera el poder de verdad.
Llevo unos veinte años en PPC, doce de ellos escribiendo código contra esa API. Entre 2015 y 2017 mantuve ppc-scripts.eu, un pequeño blog sobre Google Ads Scripts, cuando automatizar el PPC todavía no estaba de moda. Luego dejé de escribir. No porque se me secaran las ideas. La brecha entre «esto es posible» y «esto vale la pena para un cliente» se mantuvo tercamente ancha durante una década, y las formas de describir herramientas que nadie puede pagar se agotan pronto.
Esta primavera entregué un análisis de expansión a nuevos mercados, dieciséis productos con precios en cinco países y mapas de calor, en unas seis horas. Hecho a mano son alrededor de 400 horas de trabajo. Construido como software a medida a la antigua, son dos meses de desarrollo y una factura de 16.000 a 20.000 € que ningún cliente quiso pagar jamás. El mismo entregable, y el precio se hundió. El análisis no se volvió más listo esta primavera. Lo que se rompió fue la economía de construirlo.
Casi todo lo que has leído sobre la IA acabando con el especialista en PPC entiende el mecanismo al revés. La IA no cambió qué se puede hacer en la búsqueda de pago. Casi todo era posible desde siempre, y casi todo existía ya en 2019. Lo que cambió es quién puede permitírselo. Este artículo es la prueba, contada desde dentro de las herramientas con las que construyo de verdad. Dos eras que hicieron la automatización demasiado cara como para molestarse, el momento en que las cuentas dieron la vuelta, y un trabajo real, limpiar consultas de búsqueda basura con un modelo open source en local, desglosado paso a paso.
- La IA no añadió casi ninguna capacidad nueva al PPC. Desplomó el periodo de amortización de las que teníamos desde 2019, y solo eso reescribe qué vale la pena construir.
- La moneda decisiva dejaron de ser las líneas de código. Lo escaso ahora son las ideas más el conocimiento del dominio, saber qué construir y qué datos cruzar.
- El oficio se está partiendo en dos. Quien deja pasar las herramientas se congela; quien conoce la Google Ads API hasta el tuétano y combina datos con imaginación se despega.
- El ejemplo desglosado aquí dentro muestra un modelo open source en local limpiando miles de consultas basura en minutos, un trabajo que antes era estrictamente manual.
La era de los Scripts: unos días para un script «sencillo»
El techo nunca fue la tecnología, y quiero enseñártelo desde la primerísima herramienta que toqué. Los Google Ads Scripts parecían magia cuando llegaron. JavaScript, dentro de la cuenta, recorriendo campañas. En la práctica, un script «sencillo», digamos pausar palabras clave por encima de un umbral de CPA o marcar URLs finales rotas, eran unos días de escribir y depurar en cuanto lidiabas con los casos límite, las cuotas y los fallos silenciosos.
Luego venía la parte que nadie presupuestaba. Ejecutarlo en varias cuentas significaba una copia del script por cuenta, desincronizándose, rompiéndose en silencio cuando la nomenclatura de un cliente no encajaba con las demás. Escalarlo y distribuirlo era un trabajo en sí mismo. Por eso la mayoría de los scripts que circulaban nunca pasaron del reporting, volcar unos números a una hoja de cálculo a intervalos fijos. Cualquier cosa que de verdad cambiara la cuenta era demasiado frágil y demasiado cara de mantener.
Hasta la capa fácil de automatización estaba limitada por el coste de mantenimiento, no por la capacidad. Quédate con eso. Es el patrón de todo lo que sigue.
La era de la API: dos días hasta la primera consulta, dos años hasta una herramienta
La Google Ads API, la AdWords API por entonces, era el poder de verdad y el muro de verdad. Los dos días que mi compañero pasó en la documentación no eran una pulla hacia él. Esa era la superficie a la que se apuntaba cualquiera.
Aun así fuimos a por todas y construimos PPC Robot, una herramienta de reporting y operaciones profundamente personalizable. Técnicamente preciosa, potente de verdad. También costó dos desarrolladores, a jornada completa, dos años, y el desarrollo que necesitaba para seguir viva rondaba los 100.000 € al año. Nunca se amortizó. Cubría una fracción de lo que nuestros especialistas en PPC necesitaban de verdad, así que al final la aparcamos en un modo interno limitado. No porque fuera mala. Porque las cuentas nunca cuadraron.
Y aun así sacamos cosas reales sobre esa API, hace cuatro y cinco años:
Lo que ese motor de verdad produjo
- Verificador de URLs finales rotas / 404 en todas las cuentas lanzado
- Generador de campañas de Shopping a partir del feed lanzado
- Segmentación de Shopping / Performance Max lanzado
- Pipeline de BigQuery + reporting a Sheets / Excel lanzado
- Comprobaciones del estado de la cuenta de Merchant Center lanzado
Mira esa lista y fíjate en una cosa. Nada de eso es exótico para los estándares de hoy. Todo era posible. Solo que costaba una fortuna construirlo y otra fortuna mantenerlo vivo. Cada función con sentido, una herramienta de keyword research, una de expansión, la traducción de anuncios, un generador de Shopping, se medía en meses de dos seniors, y ningún cliente pagaría lo que eso cuesta.
El techo nunca fue la tecnología. Era el periodo de amortización.
El primer trabajo que se liberó: las consultas de búsqueda basura
«La IA lo cambió todo» es una afirmación que deberías negarte a aceptar por fe. Así que aquí van dos trabajos que antes no salían rentables y ahora sí. Los dos son cosas que ejecuto, no hipótesis, y del primero te voy a enseñar el flujo entero.
Limpiar términos de búsqueda irrelevantes de una cuenta es de altísimo valor y embota la mente, y hasta hace poco no había forma honesta de automatizarlo. Las reglas cazan un token exacto, pero decidir si «historia del nike air max» merece un clic pagado exige comprensión lectora. Así que el trabajo seguía siendo un rastreo semimanual por miles de consultas, detectando patrones a ojo, añadiendo negativas a mano. Imagínate una tienda de zapatillas de running pagando clics por «reparación de zapatillas de running», «historia del nike air max» y «zapatillas de running gratis», nada de lo cual vende ni repara. Multiplícalo por miles de filas, cada semana, en cada cuenta. Ese es el trabajo que nadie quiere y todo el mundo necesita.
Esto es lo que cambió. Un script de Python saca las consultas de la Google Ads API y se las pasa a un modelo open source, la Gemma 4 de Google, que casi cualquier PC actual puede ejecutar. Lee miles de consultas en unos minutos. Y cuando lo anclas en contexto sobre el cliente, el sitemap, la estructura del sitio y de la base de datos, la taxonomía de migas de pan, el product feed, deja de adivinar y empieza a razonar. Excluye bien y nombra los patrones que hay detrás de la basura, más rápido que cualquier repaso humano. Aquí tienes ese flujo en cinco pasos concretos.
PULL · consigue los términos de búsqueda en bruto
Saca el informe de términos de búsqueda de la Google Ads API. Consulta, clics, coste, conversiones. Por qué primero: esta es la evidencia, el dinero real ya gastado en cada término. Conviene tener el coste pegado a cada fila para que el modelo distinga la basura cara de la basura inofensiva. Obtienes: una tabla plana con cada término que la cuenta ha pagado en el periodo.
GROUND · arma un paquete de contexto sobre el sitio
Reúne lo que el sitio de verdad es, en un formato que el modelo pueda leer. El sitemap XML, la taxonomía de migas de pan, el product feed (id, título, categoría) y la estructura de base de datos y categorías. Por qué aquí está todo el juego: un modelo sin contexto adivina; un modelo que sabe que no tienes categoría de «reparación» ni de «alquiler» razona. Obtienes: un paquete de contexto que convierte al modelo de un adivino en algo que conoce tu catálogo.
ASK · clasifica las consultas y nombra los patrones
Pídele a Gemma 4, con los términos y el paquete de contexto delante, que clasifique cada consulta como relevante o irrelevante para lo que vendes y, lo importante, que devuelva los patrones detrás de las irrelevantes (un token, una intención, un desajuste de categoría). Por qué patrones y no filas: marcar 200 consultas basura te ahorra una tarde; nombrar la categoría de basura excluye las próximas mil que aún no has visto. Obtienes: una lista de consultas irrelevantes y, encima, el puñado de reglas que la generó.
REVIEW · valida las reglas, no las filas
Un humano lee los patrones, de cinco a diez, no 5.000 filas sueltas. Por qué aquí está el ahorro de tiempo: el criterio se aplica una vez por regla en lugar de una vez por consulta, y una regla equivocada salta a la vista de un modo en que una sola fila mal etiquetada nunca lo hace. Obtienes: una lista corta y de confianza de patrones de exclusión que un humano de verdad ha aprobado.
PUSH · añade las negativas al nivel correcto
Devuelve las negativas aprobadas a través de la API al nivel correcto, grupo de anuncios, campaña o lista compartida, según lo amplio que sea el patrón. Por qué importa el nivel: un token basura común a todo el sitio («gratis», «wikipedia») va en una lista compartida, no enterrado en un grupo de anuncios. Obtienes: la cuenta limpia y una lista de negativas reutilizable que sigue funcionando la semana siguiente.
Para ver por qué funciona, mira lo que el paso ASK devuelve de verdad para nuestra tienda de zapatillas de running. Las filas son ilustrativas, la forma es exactamente lo que vuelve, y el premio es el bloque del final:
Query Verdict Why
free running shoes irrelevant freebie intent, no purchase
running shoes repair irrelevant service we don't offer
nike air max history irrelevant informational, no buy intent
running shoes wikipedia irrelevant reference-seeker
→ PATTERN: tokens "free", "repair", "history", "wikipedia"
= non-commercial modifiers absent from our taxonomy.
Recommend excluding as a shared negative list.Cuatro filas se convirtieron en una regla. Un humano lee esa línea, confirma que es correcta, y la regla sigue cazando basura del estilo «zapatillas de running envío gratis devoluciones» que aún no has visto. Ese es el momento en que una tarea semanal que embota la mente se convierte en una revisión de diez minutos.
El titular silencioso es que basta con un modelo open source corriendo en local. No necesitas una API de frontera para que esto salga rentable, y tus datos no salen de casa. Eso es la economía moviéndose, no la capacidad.
El segundo trabajo: el keyword research
Este antes era una partida presupuestaria por sí solo. El keyword research de verdad, el que asigna la demanda a tus páginas de destino y te dice qué le falta al sitio, significaba decenas de horas de extracción de datos (AdWords API, cajas de sugerencias, OpenRefine), limpieza semimanual, clasificación por página de destino y, encima, reporting de tendencias, volúmenes y brechas.
Un proyecto de keyword research, antes y ahora
- La forma de siempre (extraer, limpiar, clasificar, reportar) 50–100 h
- Lo que el cliente pagaba por eso ≈ 2.000–4.000 €
- El mismo proyecto hoy, con una buena skill un puñado de horas
- Y el resultado es más preciso
No es solo más barato. Es mejor, más preciso, con las horas puestas en validación y criterio en lugar de en fontanería. Más barato y mejor es exactamente la combinación que se suponía imposible. He desglosado la versión moderna de principio a fin en el blueprint de expansión a nuevos mercados y en el análisis de brechas de contenido, los dos con el resultado intermedio real mostrado en cada paso.
La parte que todavía me sorprende es la cadencia. Una investigación así antes era un proyecto anual que el cliente aprobaba una vez. El mismo pipeline puede correr ahora a diario, viendo moverse la demanda en lugar de fotografiarla una vez al año.
La economía, antes y después
Esta es toda la tesis en una tabla. Mismos trabajos, mismo listón de calidad; solo se movió el coste de hacerlos. Cifras documentadas donde las tengo, orden de magnitud sacado de veinte años de agencia para el resto.
| El trabajo | La forma de siempre | Hoy |
|---|---|---|
| Análisis de expansión a mercados (precios multi-mercado) | ~400 h a mano · o 2 meses de dev, 16.000–20.000 € | 6 h |
| Keyword research (un proyecto) | 50–100 h · 2.000–4.000 € facturados | un puñado de horas · más preciso |
| Depuración de consultas irrelevantes | rastreo semimanual, miles de filas a mano | script + modelo local que nombra los patrones |
| Lanzar una función nueva de automatización | meses (2 devs × 2 años para una herramienta entera) | semanas |
| Mantener vivo un motor de reporting | ~100.000 € / año, nunca se amortizó | casi cero con un modelo local |
Lee la tabla de arriba abajo y el patrón se repite en cada fila. La columna de capacidad no se movió; todo esto ya sabíamos hacerlo en 2019. La columna de precio se hundió. Y el periodo de amortización es lo que decide si una idea inteligente llega a construirse alguna vez.
La IA no desbloqueó tanto capacidades nuevas de PPC como desplomó el periodo de amortización de las viejas. Cuando un desarrollo de seis meses pasa a ser uno de dos semanas, todo el backlog de «nos encantaría, pero nunca compensaría» se despeja de golpe.
Cómo se ve cuando te lo tomas en serio
Lynt ha sido una agencia volcada en la tecnología desde el primer día. Tenemos un arquitecto de sistemas, un ingeniero de seguridad, un analista de datos montando BI y un desarrollador a jornada completa en el equipo, algo que una agencia normal sencillamente no tiene. Durante años costaba apuntar ese músculo a los problemas de PPC, por todas las razones de amortización de arriba. Ahora se acumula.
Boostera, nuestra propia herramienta, llevó dos años de desarrollo. Enriquece los feeds de Google Merchant Center con IA, para que las campañas de Shopping trabajen con mejores datos de producto de los que da el feed en bruto. Alrededor de ella está la fontanería que la nueva economía por fin justifica. Scraping de precios de la competencia por mercado, del tipo que alimentó las tablas de precios del blueprint de expansión. Pipelines de keyword research que corren con calendario en lugar de una vez al año. Reporting de negocio a nivel de cliente en BigQuery con previsiones encima. Servidores MCP sobre cada servicio que tocamos, para que un agente de IA pueda tirar de cualquiera de ellos en mitad de una tarea.
Hace dos años habría tenido que defender cada uno de esos proyectos frente a la misma pregunta, si se amortizará algún día. Hoy la pregunta apenas aparece. Cuando construir se vuelve barato, la infraestructura deja de ser un lujo y empieza a ser el foso.
Qué significa esto de verdad para el sector
La lectura popular dice que la IA está acabando con el especialista en PPC. Entenderlo al revés tiene consecuencias reales en la carrera de quien lee esto, así que voy a clavar una bandera.
«La era de los especialistas en PPC se está acabando» es una tontería. Está pasando lo contrario. Los buenos especialistas se han pasado años frustrados porque lo inteligente, lo que veían con toda claridad, no valía la pena construirlo. Ahora les toca construirlo. De forma automática, rentable y a escala. Toda una estantería de estrategias de PPC que antes no salían rentables, o eran sencillamente absurdas de intentar, está de repente sobre la mesa.
Lo que sí está pasando es una división más nítida dentro del oficio. A un lado están quienes tratan la interfaz de la plataforma como si fuera todo el trabajo y dejan pasar las herramientas nuevas. Nadie los despide mañana. Se quedan congelados mientras el trabajo se mueve. Al otro están quienes conocen la Google Ads API hasta el tuétano, cruzan fuentes de datos que nadie más cruza y se montan dashboards especializados en lugar de esperar a que un proveedor lance la función. Doce años escribiendo código contra esa API me enseñaron dónde vive de verdad la ventaja del segundo grupo. El código se abarató. Lo que sigue siendo escaso es la imaginación y el conocimiento del dominio, saber qué datos combinar y por qué.
Y para matar el malentendido evidente, esto no va de un servicio más barato. Las herramientas, el cómputo y el desarrollo siguen costando dinero. El quid es que un proyecto que antes eran de cuatro a seis meses de dos desarrolladores senior ahora sale en semanas, así que la inversión por fin tiene sentido. El cliente recibe un servicio muchísimo mejor por un precio parecido.
Por qué vuelvo a escribir
Dejé de bloguear en 2017 porque la brecha entre una idea y una ejecución económicamente sensata era demasiado ancha para resultar interesante. Esa brecha se acaba de cerrar. Así que este blog retoma donde lo dejó ppc-scripts.eu, y se mantiene concreto. Casos prácticos con números reales, los flujos exactos, los resultados de verdad, con sus partes feas y sus límites incluidos. Los primeros análisis a fondo ya están publicados.
En algún lugar de tu propio backlog está la automatización que aparcaste hace años porque nunca se amortizaría. Desentiérrala y vuelve a echar las cuentas. Si han dado la vuelta como las mías, ya sabes qué construir ahora. Y si quieres comparar notas, ya sabes dónde encontrarme.
FAQ
¿Estás diciendo que las agencias deberían despedir a sus especialistas en PPC?
Justo lo contrario. Los especialistas que dominan la estrategia y las herramientas valen ahora más, porque por fin pueden ejecutar las ideas que antes no salían rentables. Lo que pierde valor es apretar botones en la interfaz de la plataforma y poco más.
¿La cifra de 100.000 €/año y dos devs durante dos años es exacta?
No, tómala como un orden de magnitud. El quid no es la cantidad exacta en euros. Un solo motor de reporting interno arrastraba un coste anual de seis cifras y aun así nunca se amortizó. De esas cuentas va todo el artículo.
¿Necesito un modelo de frontera caro para esto?
Para trabajos como la depuración de consultas irrelevantes, no. Un modelo open source capaz como Gemma 4, ejecutado en local y con buen contexto del sitio, hace el trabajo. Así tanto tus datos como tus costes siguen bajo tu control.
¿Esto va solo de consultas de búsqueda?
No, es solo el trabajo más fácil de ver en marcha. La misma economía se movió para el análisis de expansión a mercados (seis horas en lugar de ~400), el scraping de precios de la competencia por mercado, el keyword research que corre a diario en lugar de una vez al año y el enriquecimiento de feeds con Boostera. Elige la tarea que aparcaste y vuelve a echar sus cuentas.
¿Entonces esto es hype con una mano de pintura nueva?
Si lo fuera, no habría vuelto a escribir. El cambio es concreto y real, un periodo de amortización desplomado sobre capacidades que ya teníamos. Es un cambio de negocio, no de magia, y por eso el backlog se despeja de golpe.
¿Qué habrá de verdad en este blog?
Casos prácticos con números, los flujos que hay detrás y los resultados, con sus límites y sus modos de fallo incluidos. Menos manifiesto y más «esto es exactamente lo que ejecutamos y lo que devolvió».
