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 contra esta API, y durante la mayor parte de ese tiempo fue una superficie lenta que visitabas una vez al año, subías el número de versión y te olvidabas.

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. En septiembre de 2026, cada campaña de Dynamic Search Ads que quede se actualiza automáticamente a AI Max, lo pidas o no.

Esos dos relojes son las obligaciones del año de las APIs de Google. Todo lo demás que lanzó la plataforma es 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, payload o migración exacta a 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 duro. 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 contra la 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 contra la referencia de la Merchant API antes de desplegar, porque cambiaron los nombres de campo, no solo la URL.)

El destino es honestamente mejor que lo 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 el empujón definitivo. Reconstruye una vez y sal 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 septiembre de 2026

El segundo cambio con fecha, y el que 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. Desde septiembre de 2026, Google actualiza automáticamente a AI Max todas las DSA restantes, los recursos creados automáticamente y la concordancia amplia a nivel de campaña. Después de eso no puedes crear una campaña DSA nueva. Ni en la interfaz, ni en Editor, ni por API.

Por qué afecta a tu cuenta. El trato es control a cambio de mejora. Con el conjunto completo de funciones (matching 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 al matching solo. A cambio, le entregas al modelo el matching, 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 actualización silenciosa en septiembre puede empezar a mandar tráfico a URLs y textos 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ó las barandillas y los ganchos de medición por API 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:

El movimiento práctico es el último. Crea un experimento ADOPT_AI_MAX en tus cuentas y déjalo correr. El delta de CPA y ROAS lo lees comparando las campañas del brazo experimental con el control. Una consulta GAQL normal te muestra después qué emparejó y qué 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 contra 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. Un bump 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 llamas y avisa unos 60 días antes de que caduque. 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 un simulacro de incendio.

Ahora la ventaja: la IA se muda a creatividades y feed

Con las fechas límite resueltas, el resto del año es palanca que adoptas a tu propio ritmo. Dos servicios convirtieron el trabajo de recursos y feed en algo que puedes automatizar sobre 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.

La mitad del feed me la tomo como algo personal. En Lynt pasamos dos años construyendo Boostera, 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 mueven más ingresos que la mayoría de los cambios de puja. Product Studio lleva una parte de esa capacidad a la propia plataforma.

La pipeline que esto desbloquea lee un SKU del feed, genera un título, una descripción y recursos de imagen conformes, y los empuja directo 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 se gradúen.

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. Combinado con product_filters (compartición condicional del feed con Google Ads, lanzada en noviembre de 2025) y CartDataSalesView (v24), el circuito entre la salud del feed y la inversión publicitaria se cierra dentro de un solo entorno.

Por qué afecta a tu cuenta. La vieja separación, campañas en Scripts y feed gestionado en otro sitio, significaba que 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. 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 el insumo de un tiering de rentabilidad que antes reconstruías a mano cada mes. Para nuestros clientes montamos informes de negocio a nivel de cliente en BigQuery, y la mitad del trabajo siempre fue coser datos publicitarios con datos de producto. La costura ahora vive en dos llamadas a la API en vez de en un export del feed, y puedes validarla. Comprueba que los item ID coinciden en ambos lados 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. Todo lo marcado LÍMITE 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 tu exposición al 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 septiembre 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