Un año de Google Ads API: dos fechas límite duras, el resto es oportunidad

En enero, Google lanzó la v23 de la Ads API y anunció que a partir de entonces saldría una versión nueva cada mes. Lo leí dos veces. Llevo doce años escribiendo código que llama a esta API, y durante la mayor parte de ese tiempo cambiaba tan despacio que pasabas por ella una vez al año, subías el número de versión y te olvidabas de ella.

Luego hice lo que esos años me han enseñado a hacer. Abrí nuestro código en Lynt y busqué shoppingcontent.googleapis.com. Cada resultado es un script que muere el 18 de agosto de 2026, el día en que se apaga la Content API for Shopping. Justo detrás hay una segunda fecha, y Google ya la ha movido: desde febrero de 2027, cada campaña de Dynamic Search Ads que quede se actualiza automáticamente a AI Max, lo pidas o no. En septiembre de 2026 pasan primero a AI Max las campañas que usan recursos creados automáticamente y concordancia amplia a nivel de campaña.

Esas dos fechas son las obligaciones que Google te impone este año. Todo lo demás que lanzó la plataforma es una oportunidad: servicios de IA para creatividades, informes de ventas a nivel de producto, la Merchant API dentro de Google Ads Scripts. Así que recorreré el año por prioridad, la fecha más dura primero. Para cada cambio: qué es, por qué afecta a tu cuenta y la llamada, el payload o la migración exacta que tienes que ejecutar.

No voy a dejar nada en «deberías migrar». Una fecha límite sin un artefacto concreto es solo ansiedad. En cada paso tienes el endpoint que sustituye al viejo, el payload del experimento o la consulta GAQL, para que veas exactamente qué construir antes de que llegue la fecha.

Fecha límite uno: la Content API for Shopping muere el 18 de agosto de 2026

Es la fecha más dura del año, así que va primero.

Qué cambió. La Content API for Shopping v2.1 se apaga el 18 de agosto de 2026. Su sucesora, la Merchant API v1, llegó a GA en julio de 2025, y la intermedia v1beta ya se apagó el 28 de febrero de 2026. El viejo monolito se sustituye por sub-APIs enfocadas. datasources, products, inventories, reports, notifications.

Por qué afecta a tu cuenta. Cualquier cosa que toque tu feed a través de la API vieja deja de funcionar ese día. Subidas de feeds, feeds complementarios, etiquetas personalizadas, actualizaciones de precio y stock, lecturas de rechazos. Esto no es un «estaría bien migrar», es un corte en seco. Si un script diario mantiene tus precios sincronizados, el 18 de agosto se queda mudo y tu feed se aleja poco a poco de la realidad hasta que alguien nota los ingresos perdidos. He visto ese modo de fallo en cuentas reales, y lo caro nunca es la caída en sí, lo caro son las semanas en que nadie la nota.

Qué hacer. Reconstruye tu integración para la nueva estructura de sub-APIs. La migración es mecánica. Cambian el host, la ruta y el modelo de recursos, la intención se mantiene. Aquí tienes el antes y el después de la llamada más común de todas, el upsert de un producto:

# OLD: Content API for Shopping v2.1 (off on 2026-08-18)
curl -X POST \
  "https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "title": "...", "price": {"value":"19.90","currency":"EUR"} }'

# NEW: Merchant API v1 (productInputs sub-API)
curl -X POST \
  "https://merchantapi.googleapis.com/products/v1/accounts/{account}/productInputs:insert?dataSource=accounts/{account}/dataSources/{ds}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "productAttributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Los hosts de los endpoints y la división en sub-APIs vienen de la documentación de Google. Confirma el body exacto de la petición para tu recurso en la referencia de la Merchant API antes de desplegar, porque cambiaron los nombres de campo, no solo la URL.)

La Merchant API v1 es una API mejor que la Content API a la que sustituye, y esa es la parte que nadie te cuenta. Tres mejoras que heredas gratis al migrar:

Si llevabas tiempo queriendo endurecer tus herramientas de feed, el apagado es lo que por fin te obliga a hacerlo. Reconstruye una vez y sal de ahí con un manejo de errores más limpio y menos idas y vueltas de las que v2.1 permitió jamás.

Fecha límite dos: las Dynamic Search Ads pasan a AI Max en febrero de 2027

Este es el segundo cambio con fecha fija, y redefine cuánto control conservas.

Qué cambió. AI Max for Search llegó a GA el 15 de abril de 2026 tras lanzarse en beta en mayo de 2025. El despliegue se hace en dos pasos: desde septiembre de 2026, Google actualiza automáticamente a AI Max las campañas que usan recursos creados automáticamente y concordancia amplia a nivel de campaña, mientras que el cierre y la migración automática de las DSA empiezan en febrero de 2027, después de que Google los aplazara respecto a la fecha de septiembre anunciada inicialmente. Después de eso no puedes crear una campaña DSA nueva. Ni en la interfaz, ni en Google Ads Editor, ni por API.

Por qué afecta a tu cuenta. Cedes control a cambio de mejora. Con el conjunto completo de funciones (concordancia de términos más personalización de texto más expansión de URL final) Google reporta cerca de un +7 % en conversiones o valor de conversión frente a la concordancia de términos de búsqueda por sí sola. A cambio, le entregas al modelo la concordancia, el texto de los recursos y la elección de la página de destino. Si tienes reglas de marca o compliance montadas a mano en tu configuración de DSA, una migración automática silenciosa puede empezar a mandar tráfico a URLs que nunca autorizaste y a utilizar textos de anuncio que nunca aprobaste. La automatización que no mediste es automatización que no controlas.

Qué hacer. No esperes a descubrir qué hace la actualización con tus números. Mídelo ahora. Google lanzó por API las salvaguardas y los puntos de medición al mismo ritmo que la función, así que puedes hacer un A/B del cambio con tus propios datos antes de que sea obligatorio:

La medida práctica es el experimento ADOPT_AI_MAX. Crea uno en tus cuentas y déjalo en marcha. El delta de CPA y ROAS lo lees comparando las campañas del brazo experimental con las campañas de control. Una consulta GAQL normal te muestra después qué emparejó y cuánto ingresó de verdad la expansión sin palabras clave:

-- After ADOPT_AI_MAX runs: inspect automated expansion performance.
-- Calculate trial/control delta separately from the experiment arm campaigns.
SELECT campaign.name,
       metrics.conversions,
       metrics.conversions_value,
       metrics.cost_micros
FROM targeting_expansion_view
WHERE segments.date DURING LAST_30_DAYS

(ADOPT_AI_MAX es uno de los nuevos tipos de experimento de la v24.1; targeting_expansion_view es el recurso de informes de la v22. Confirma la disponibilidad de campos en las release notes de la versión que llames.)

La fecha límite rodante: una versión cada mes

No es una fecha única, sino un reloj que ahora no deja de correr.

Qué cambió. Desde la v23 (28 de enero de 2026) la Google Ads API pasó a una cadencia mensual de versiones. Cuatro versiones mayores al año más versiones menores mensuales, con un año de soporte por versión mayor.

Por qué afecta a tu cuenta. Acceso más rápido a las funciones, y obsolescencia más rápida. Las versiones caducan según un calendario publicado. La v20 llega a su fin de vida en junio de 2026, la v21 en agosto, la v22 en octubre. Una subida de versión menor mensual no rompe nada. Perderte el sunset de una versión mayor significa que tus scripts empiezan a devolver errores sin más aviso que una fecha en un calendario que no estabas mirando.

Qué hacer. Fija tu versión y vigila el calendario de sunsets. El seguro más barato es una comprobación recurrente que sabe qué versión utilizas y avisa unos 60 días antes de que caduque esa versión. Todo cabe en unas pocas líneas:

# Recurring guardrail: alert ~60 days before your pinned version sunsets.
from datetime import date

PINNED = "v22"                 # the version your client is pinned to
SUNSET = {"v20": "2026-06-01", "v21": "2026-08-01", "v22": "2026-10-01"}  # sunset-dates page
sunset = SUNSET.get(PINNED)    # None until your version reaches the published calendar
if sunset and (date.fromisoformat(sunset) - date.today()).days < 60:
    alert(f"{PINNED} sunsets {sunset}; schedule the version bump")  # major bump needs a re-test

Un 404 de una versión caducada es una caída autoinfligida. Trata la gobernanza de versiones como una tarea recurrente permanente, no como una urgencia de última hora.

Ahora la ventaja: la IA entra en las creatividades y en el feed

Con las fechas límite resueltas, tú marcas el ritmo del resto del año. Dos servicios convirtieron el trabajo de recursos y feed en algo que puedes automatizar en miles de SKUs.

• AssetGenerationService (Ads API, v22, beta cerrada). Generación de texto e imágenes con IA, con mejora y extracción de imágenes para PMax; la v23.2 añadió VideoEnhancement para vídeo generado por Google. La generación creativa sale de la interfaz y entra en una capa programable.
• Product Studio (Merchant API, alfa desde abril de 2025). Títulos y descripciones de producto generados por IA, más AutomatedDiscounts para precios en tiempo real. Reescribir títulos a nivel de API significa mejorar miles de SKUs en bloque sin trabajo manual.

En la parte del feed tengo un interés personal. En Lynt pasamos dos años construyendo Boostora, una capa de IA que enriquece feeds de Merchant Center, porque la calidad del feed es el techo del rendimiento de Shopping y PMax. Unos títulos mejores generan más ingresos que la mayoría de los cambios de puja. Product Studio lleva una parte de esa capacidad a la propia plataforma.

El pipeline que esto desbloquea lee un SKU del feed, genera un título, una descripción y recursos de imagen conformes, y los envía directamente al grupo de recursos, sin paso manual por Canva en medio. Ambos servicios son pre-GA. Trátalos como un piloto sobre una parte del catálogo, no como un despliegue a todo el catálogo, hasta que lleguen a GA.

La fontanería: Ads y Merchant por fin juntos

El cambio más infravalorado del año no tiene glamur. Las dos mitades de una cuenta de e-commerce acaban en un mismo sitio.

Qué cambió. Desde el 22 de abril de 2026, la Merchant API es accesible desde Google Ads Scripts. Combina esa capacidad con product_filters (compartición condicional del feed con Google Ads, lanzada en noviembre de 2025) y CartDataSalesView (v24). Así, el circuito que va del estado del feed a la inversión publicitaria se cierra dentro de un solo entorno.

Por qué afecta a tu cuenta. La vieja separación dejaba las campañas en Scripts y el feed en otro sitio. Un producto rechazado seguía quemando presupuesto hasta que un humano lo notaba. Ahora un solo script puede reaccionar a un rechazo del feed pausando una campaña o sacando el SKU de un grupo de fichas de PMax. Y CartDataSalesView trae a la API los ingresos por SKU vendido desde los datos del carrito. La vista contiene ingresos, no inversión, así que el ROAS real por SKU exige dos consultas. Empieza por el lado de los ingresos:

-- Revenue per sold SKU from cart data (v24+)
SELECT segments.product_item_id,
       metrics.revenue_micros,
       metrics.all_revenue_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.revenue_micros DESC

Luego saca el lado de los costes de shopping_performance_view y une los dos resultados por product_item_id:

-- Cost per advertised SKU; join to the revenue query on product_item_id
SELECT segments.product_item_id,
       metrics.cost_micros,
       metrics.conversions_value
FROM shopping_performance_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.cost_micros DESC

Esas filas unidas son la materia prima de los niveles de rentabilidad que antes reconstruías a mano cada mes. En BigQuery montamos informes de negocio a nivel de cliente para las cuentas que gestionamos, y la mitad del trabajo siempre fue coser datos publicitarios con datos de producto. Ahora dos llamadas a la API hacen la costura que antes exigía un export del feed, y puedes comprobar el resultado tú mismo. Verifica que los item ID coinciden en las dos consultas antes de fiarte del ratio. (El recurso es cart_data_sales_view, lanzado en la v24; confirma la disponibilidad de segmentos en las release notes de tu versión.)

El año en una sola línea de tiempo

Cada versión mayor de abajo viene de las release notes oficiales; los hitos de Merchant, de las Merchant API latest updates. La columna derecha es la única que debería gobernar tu calendario. Cada fila que lleva la etiqueta HARD es innegociable.

La primera hora de trabajo

No la migración entera. Un grep. Busca en tu código shoppingcontent.googleapis.com y apunta cada job que aparezca. Esa lista es todo lo que tienes en riesgo el 18 de agosto, y te ha llevado diez minutos.

Dedica el resto de la hora a crear un experimento ADOPT_AI_MAX en la cuenta donde las DSA pesan más, para que la actualización llegue como un cambio medido y no como una sorpresa. Las fechas límite son de Google. Que te golpeen como caídas o como mejoras sigue siendo decisión tuya.

FAQ