Si haces SEO, llevas meses oyendo que AI Mode es otro golpe más al tráfico desde buscadores.
Si haces PPC, es posible que lleves semanas viendo que la API de Google Ads despliega cambios a un ritmo nuevo.
Es la misma película vociferada desde dos cocinas diferentes: Google está reescribiendo cómo se reparte el tráfico (orgánico y pagado) ya no solo en la SERP actual, sino también en la que está por venir. Y se ve antes en las release notes de sus productos que en cualquier keynote.
Toca mirarlo en equipo.
Ya sabes: cuando las barbas de tu vecino veas meter a remojar... En fin, nunca se me han dado bien los dichos. Pero me suena a “ojo, que vienen cosas”.
Si eres SEO, sigue leyendo, porque te interesa. De verdad.
Versión menor con upgrade obligatorio para novedades, cambios de infraestructura en Offline Conversion Imports con fluctuaciones de atribución reconocidas para perseguir mejoras en la justificación de inversión, subida de límites en BatchJob en la API y enforcement de Lookalike con fecha cerrada (30 de abril de 2026).
Si esto fuera solo cuestión técnica de un equipo de PPC, tampoco daría para newsletter.
La razón por la que conviene mirar es otra: la API de Ads ha dejado de ser un canal para gestionar campañas y se está convertiendo en el hilo que une los datos del anunciante (CRM, conversiones offline, audiencias) y los modelos de Google. Y Google lleva un año reforzándolo a velocidad inusual, justo cuando AI Overview y AI Mode empiezan a comer superficie a la SERP clásica donde viven los anuncios de toda la vida.
Para los SEOs hay un motivo estratégico: si la siguiente generación de formatos publicitarios (sponsored answers en AI Mode, ads dentro del razonamiento del agente, citas patrocinadas) se construye sobre esta API, lo que pasa aquí define cómo se reparte la SERP futura. La cuña que ya nos come tráfico desde la respuesta directa puede meter encima un formato pagado en el mismo flujo conversacional.
Para los PPCs es más obvio: la cadencia de despliegues ha cambiado y los números pueden dejar de significar “lo de siempre” antes de que te enteres.
AdWords se lanzó en los primeros años de los dosmiles como una capa relativamente sencilla de subastas por palabras clave.
La historia operativa de los últimos diez años ha sido un goteo continuo de automatización: enhanced CPC, smart bidding, broad match con ML, Performance Max (2021), Demand Gen, AI Max ampliándose este año a Shopping y Travel.
Cada paso ha movido las decisiones del anunciante a las manos de los modelos de Google. Dicho de otra manera, Google ha ido quitando control, poco a poco, a los anunciantes. Y se lo han dado a su IA.
Adivina qué incentivo tienen esos modelos. Sí, eso mismo que estás pensando. Ni lo voy a mencionar.
La consecuencia es obvia: la calidad de la atribución (offline conversions, enhanced conversions, GCLID recovery), el enforcement de audiencias (Lookalike, similar audiences) y las nuevas señales (VideoEnhancement, AppTopCombinationView, métricas de conversión nuevas en v23.2) son piezas de la misma maquinaria y dependen exclusivamente de Google.
Alimentar los modelos con datos limpios y obligar al ecosistema a actualizarse al ritmo del producto.
A esto se le suma el contexto: el negocio publicitario es la principal fuente de ingresos de Alphabet.
La presión de Perplexity, ChatGPT y la propia AI Mode (que es de Google y juega en el mismo tablero) está obligando a meter publicidad allá donde haya consulta. La API es el sitio donde se ve, antes que en notas de prensa, el movimiento real del producto.
Ahí entran también el Ads DevCast bisemanal (canal de Google Developers nuevo) y la frecuencia de release notes. La superficie de comunicación hacia developers no se amplía por casualidad.
La IA se mueve rápido y necesita poder generar anuncios con agilidad. Y, para poder hacerlo, necesita reglas que vengan de un entorno ya asistido mediante una mezcla de lógica determinista (lo que el anunciante configura) y automático (API + IA).
Sin ganas de meter miedo, pero tratando de alertar a quien lee esto:
v23.2 (marzo 2026), release menor. Nuevos recursos (VideoEnhancement, AppTopCombinationView, HotelSettingInfo en Demand Gen, métricas de conversión). Si quieres usarlos, hay que actualizar client libraries. Si no los necesitas, igualmente toca revisar que nada rompa.
Offline Conversion Imports a partir de abril de 2026, cambios de infraestructura orientados a mejorar atribución y recuperación de GCLIDs expirados. Google avisa de “fluctuaciones menores” en atribución durante el rollout. Traducción: si tu equipo mira los informes de conversiones offline y ve números raros en abril, no es necesariamente un fallo tuyo.
BatchJobService: los límites de tamaño por request han pasado de unos 10 MB a unos 42 MB. Para quien sube assets pesados (imágenes, por ejemplo) en batch, es relevante. Para el resto, es otra pieza que cambia sin pedir permiso y que ya apunta a la necesidad de Google por recoger recursos más pesados desde API.
Lookalike user lists: enforcement desde el 30 de abril de 2026. Duplicados bloqueados: ahora la API devuelve
DUPLICATE_LOOKALIKEen v24+. Si tienes flujos que crean listas similares automáticamente, revisa antes de esa fecha o tus jobs empezarán a fallar.
Pongamos las consecuencias en orden.
Qué sucede: la API se mueve más rápido y las integraciones que aparecen y desaparecen se notan antes. Higiene técnica.
Impacto directo: la mayoría de cambios apuntan a calidad de datos para los modelos (atribución más sólida, audiencias deduplicadas, señales nuevas).
Google está preparando una nueva generación de productos publicitarios que necesita datos del anunciante con menos huecos.
Consecuencia del impacto: si AI Mode acaba integrando publicidad de forma estable (sponsored answers, anuncios dentro del razonamiento del agente, citas patrocinadas), el inventario que hoy vive en la SERP clásica se desplaza.
Esto robará CTR del orgánico por dos vías.
La primera es la conocida: la respuesta directa baja el clic al enlace azul.
La segunda es nueva: cuando dentro de la respuesta haya además un ad contextual, el orgánico no es que pierda el primer hueco, es que compite con un formato distinto que el modelo presenta como parte del razonamiento. Es difícil mantener CTR contra eso sin trabajo específico de citabilidad y sin un setup de medición que entienda referidos de agente.
El estudio de BrightEdge de finales de abril (cinco superficies: ChatGPT, AIO, AI Mode, Gemini, Perplexity) ya muestra la baja superposición de fuentes entre motores pero alineación creciente en citas de marca. La SERP futura no es una; son varias capas, y AI Mode es la única donde Google controla a la vez el algoritmo, los datos del anunciante y la interfaz.
Para PPC esto significa que la API actual está siendo afinada precisamente para alimentar ese formato futuro.
Para SEO significa que el flanco publicitario va a presionar el orgánico desde un sitio nuevo y conviene mirar lo que se cuece en los fuegos de al lado.
Higiene mensual concreta:
Día fijo al mes para revisar las release notes del Google Ads Developer Blog. No leer todo: busca las palabras “breaking”, “enforcement”, “deprecation” y “fluctuation”.
Si tienes ETL o imports de conversiones, comprobar que la versión de la client library sigue siendo compatible. Smoke test en cuenta sandbox (o la de prueba que tengas) antes de tocar producción.
Si usas Lookalike o similar audiences, revisar antes del 30 de abril. Después de esa fecha, lo que no cumpla falla en silencio o con error explícito según versión.
Si tienes BigQuery como destino de datos de Ads, documentar la ventana de rollout de OCIs para que quien lea el informe sepa que abril puede traer variaciones de atribución que no son orgánicas.
Fuentes para no quedarse desfasado:
Google Ads Developer Blog: la fuente oficial para release notes, deprecations y enforcement. Suscribirse al RSS.
Ads DevCast (canal de Google Developers en YouTube): vídeos bisemanales de unos quince minutos con los cambios relevantes. Es relativamente nuevo y la mera existencia ya es señal de hacia dónde va el producto.
GitHub de las client libraries: google-ads-python, google-ads-php, google-ads-java, etc.: los release notes del repo suelen citar los cambios de la API que afectan al código. Si solo sigues una cosa, sigue las releases del repo en tu lenguaje.
Ginny Marvin (Google Ads Liaison) en LinkedIn y X: traduce mucho del producto antes que la documentación oficial.
Frederick Vallaeys (Optmyzr) y Aaron Levy en X y LinkedIn: lectura crítica del producto desde gente que lleva años haciendo PPC con criterio.
PPC Town Hall y newsletters tipo Optmyzr Insider o PPC Greg: feed semanal con cambios y casos.
Subreddit r/PPC: a veces el primer sitio donde alguien cuenta que algo se ha roto en producción.
Esto no es un cambio de estrategia. Es estar al día de algo que ya suena a truenos que anuncian tormenta. La misma que ya aplicas (o deberías) con los core updates de Google en SEO: ventanas de comparación, no pánico diario.
Si trabajas con datos de Ads en serio (anomalías, atribución cross-canal, cuadros de mando, ETLs propias), el sitio donde te quitas dependencia de la API en caliente es BigQuery.
Data Transfer Service: Google ofrece una ingesta diaria automática de datos de Ads en BigQuery. Una vez activada, el servicio crea tablas con datos crudos por día (no agregados) y backfill configurable.
La gracia es doble: sobrevive a los rate limits de la API en caliente y permite cruzar con GA4 export, Search Console export y los datos del cliente que ya tengas en tu data warehouse. Cualquier cambio de atribución (los OCIs de abril, por ejemplo) deja rastro auditable día a día.
Lo mínimo para tener un setup limpio:
Proyecto GCP con BigQuery y la API de Google Ads habilitadas.
Cuenta MCC de Google Ads vinculada (acceso Email Standard para quien va a configurar el transfer).
Data Transfer Service apuntando al CID o al MCC, con dataset destino y backfill (suele empezarse con 30 días).
Developer token de Google Ads vinculado al MCC (más sobre esto en el siguiente punto).
OAuth client
client_id,client_secret) yrefresh_tokendel MCC para los scripts que toquen la API por encima del transfer (lo necesitas para enriquecer, no para el transfer básico).
El developer token: pídelo cuanto antes, en serio.
El developer token va vinculado a tu MCC y tiene tres niveles de acceso:
Test access: solo cuentas de prueba; sirve para empezar.
Basic access: hasta unas 15.000 operaciones al día; suficiente para clientes pequeños o para fase inicial.
Standard access: sin límite operativo práctico; necesario para producción seria, agencias con muchas cuentas o cualquier ETL que mueva datos de muchos CIDs.
Pasar de basic a standard requiere solicitud y revisión por parte de Google.
La revisión no es un trámite cualquiera: piden URL del producto o del uso, casos concretos, capturas, política de tratamiento de datos. He visto procesos de tres días y procesos de dos meses, según el lío que tengan en el equipo de developer relations.
Si planeas usar la API en serio (Data Transfer va con tu token, las herramientas internas también), pide el standard access en cuanto tengas el setup mínimo, aunque todavía no lo necesites a tope. Bloquearse a final de mes con el token sin aprobar mientras un cliente espera un dashboard es un dolor evitable.
Y no veo ninguna razón para no estar preparado, sinceramente.
Otra cosa útil: documenta en algún sitio interno qué token usa cada cliente, qué CID está vinculado a qué MCC, qué refresh_token tienes y cuándo caduca. La gestión de credenciales de Ads cuando llevas ocho cuentas se descontrola en seis meses si no hay nadie mirando. Un YAML o una tabla en Notion con CID, MCC, token, fecha de aprobación y dueño técnico ahorra muchas reuniones.
Luego no digas que no te he avisado.
Esta capa (BigQuery + token con buen acceso + OAuth limpio) es lo que hace que cualquier cambio de la API (atribución, GCLID, fluctuations) tenga rastro fuera del producto de Google. Cuando llega el siguiente cambio (que llegará), tienes histórico para responder a “¿esto es Google o somos nosotros?” sin mirar al techo. Y si AI Mode acaba ofreciendo ads en su flujo, esos datos crudos serán la única forma de cruzar inversión, formato y resultado real cuando los informes nativos vayan agregados o tarden.
Esto es lo que diferencia a un equipo que vive la API de uno que la visita por Navidad. Tarde, lento, sin contexto. Mal.
Sin posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.