Cosa è cambiato quest'anno nelle API di Google — ed esattamente cosa farci

Tutto l’anno in una frase

Due date fisse manderanno in crisi il tuo stack se le ignori — la Content API for Shopping chiude il 18 agosto 2026 e i Dynamic Search Ads passano automaticamente ad AI Max a settembre 2026 — e un terzo cambiamento, la nuova cadenza di rilascio mensile, fa invecchiare in silenzio la tua versione API più in fretta di prima. Tutto il resto che Google ha rilasciato quest’anno è opportunità, non obbligo. Questo pezzo affronta ogni cambiamento allo stesso modo: cosa è cambiato, perché conta per il tuo account, e la chiamata, il payload o la migrazione esatta da eseguire — in ordine di priorità, prima la scadenza più dura.

Non lascerò niente al livello di “dovresti migrare”. A ogni passo trovi l’artefatto concreto — l’endpoint che sostituisce quello vecchio, il payload dell’esperimento, la query GAQL — così vedi esattamente cosa costruire prima che arrivi la data.

Una parola sul perché tutto questo conta. Per anni le API di Google Ads e Merchant sono state una superficie a movimento lento che potevi toccare una volta l’anno. È finita. La piattaforma ora rilascia ogni mese, due delle sue superfici più grandi vengono spente e il controllo che tenevi a mano viene affidato ai modelli. Gli account che ne escono avanti sono quelli che hanno trattato quest’anno come un progetto di migrazione, non di manutenzione.

Scadenza #1 — Content API for Shopping → Merchant API (18 ago 2026)

È la data più dura dell’anno, quindi va per prima.

Cosa è cambiato. La Content API for Shopping v2.1 chiude il 18 agosto 2026. Il suo successore, la Merchant API v1, è andata in GA a luglio 2025, e la v1beta intermedia è già stata dismessa il 28 febbraio 2026. Il vecchio monolite è sostituito da sub-API focalizzate — datasources, products, inventories, reports, notifications.

Perché conta per il tuo account. Tutto ciò che tocca il tuo feed attraverso la vecchia API smette di funzionare quella data: upload dei feed, feed supplementari, custom label, aggiornamenti di prezzo e stock, letture delle disapprovazioni. Non un “carino migrare” — un taglio netto. Se uno script quotidiano tiene i tuoi prezzi sincronizzati, ammutolisce il 18 agosto e il tuo feed va lentamente fuori data finché qualcuno si accorge del fatturato perso.

Cosa fare. Ricostruisci sulla struttura a sub-API. La forma della migrazione è meccanica — cambiano host, path e modello delle risorse, l’intento resta lo stesso. Ecco il prima/dopo per la chiamata più comune in assoluto, un upsert di prodotto:

# 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 '{ "channel": "ONLINE", "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "attributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Gli host degli endpoint e la suddivisione in sub-API arrivano dai documenti di Google; conferma il body esatto della richiesta per la tua risorsa sulla reference della Merchant API prima di rilasciare — sono cambiati i nomi dei campi, non solo l’URL.)

La destinazione è davvero migliore di ciò che sostituisce, ed è la parte che nessuno ti dice. Tre miglioramenti che erediti gratis migrando:

Se da tempo pensavi di irrobustire la strumentazione del tuo feed, lo spegnimento è la spinta che serve: ricostruisci una volta ed esci con una gestione degli errori più pulita e meno round-trip di quanti la v2.1 abbia mai permesso.

Scadenza #2 — Dynamic Search Ads → AI Max (set 2026)

Il secondo cambiamento con una data, e quello che ridisegna quanto controllo tieni.

Cosa è cambiato. AI Max for Search è arrivato in GA il 15 aprile 2026 dopo essere partito in beta a maggio 2025. Da settembre 2026 Google aggiorna automaticamente tutti i DSA rimanenti, gli asset creati automaticamente e la corrispondenza generica a livello di campagna in AI Max. Dopodiché non puoi creare una nuova campagna DSA — né nella UI, né in Editor, né tramite API.

Perché conta per il tuo account. Lo scambio è controllo in cambio di incremento. Con l’intero set di funzionalità — corrispondenza per query di ricerca, più personalizzazione del testo, più espansione dell’URL finale — Google riporta circa +7 % di conversioni o valore di conversione rispetto alla sola corrispondenza per query. In cambio affidi al modello la corrispondenza, il testo degli asset e la scelta dell’URL di destinazione. Se hai regole di brand o compliance impostate a mano nel tuo setup DSA, un upgrade silenzioso di settembre può iniziare in sordina a mandare traffico verso URL e copy che non hai approvato.

Cosa fare. Non aspettare di scoprire cosa fa l’upgrade ai tuoi numeri — misuralo ora. Google ha rilasciato i guardrail e gli hook di misurazione tramite l’API in parallelo alla funzionalità, così puoi fare l’A/B del passaggio sui tuoi dati prima che diventi obbligatorio:

La mossa pratica è l’ultima: crea un esperimento ADOPT_AI_MAX sugli account, lascialo girare, poi leggi il delta reale con una normale estrazione GAQL — invece di scoprirlo dopo che l’upgrade è irreversibile:

-- After ADOPT_AI_MAX runs: read the keywordless match, then the trial delta
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 è uno dei nuovi tipi di esperimento rilasciati in v24.1; targeting_expansion_view è la risorsa di reporting della v22. Conferma la disponibilità dei campi sulle release notes per la versione che chiami.)

Scadenza #3 (continua) — rilasci mensili, vita più breve

Non una singola data, ma un orologio che ora ticchetta sempre.

Cosa è cambiato. Dalla v23 (28 gennaio 2026) la Google Ads API è passata a una cadenza di rilascio mensile: quattro versioni maggiori all’anno più versioni minori mensili, con un anno di supporto per versione maggiore.

Perché conta per il tuo account. Accesso più rapido alle funzionalità, e obsolescenza più rapida. Le versioni invecchiano secondo un calendario pubblicato — la v20 arriva a fine vita a giugno 2026, la v21 ad agosto, la v22 a ottobre. Un bump minore mensile non rompe la compatibilità; saltare la dismissione di una maggiore significa che i tuoi script iniziano a restituire errori senza preavviso oltre a una data in un calendario che non stavi guardando.

Cosa fare. Fissa la tua versione e tieni d’occhio il calendario delle dismissioni. L’assicurazione più economica è un controllo ricorrente che sa quale versione chiami e avvisa ~60 giorni prima della scadenza — l’API riporta perfino la versione della richiesta, quindi il controllo è di poche righe:

# 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"}  # from 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 da una versione dismessa è un’interruzione che ti sei procurato da solo. Tratta la governance delle versioni come un compito ricorrente fisso, non come un’emergenza.

Ora il vantaggio — l’AI entra in creatività e feed

Gestite le scadenze, il resto dell’anno è leva che adotti ai tuoi tempi. Due servizi hanno trasformato il lavoro su asset e feed in qualcosa che puoi scriptare su migliaia di SKU:

• AssetGenerationService — Ads API, v22, closed beta: generazione di testo e immagini con l’AI, con miglioramento ed estrazione delle immagini per PMax; la v23.2 ha aggiunto VideoEnhancement per il video generato da Google. La generazione creativa esce dalla UI ed entra in un livello programmabile.
• Product Studio — Merchant API, in alpha da aprile 2025: titoli e descrizioni di prodotto generati dall’AI, più AutomatedDiscounts per il pricing in tempo reale. La qualità del feed è il tetto delle performance di Shopping e PMax, quindi riscrivere i titoli a livello di API significa migliorare in blocco migliaia di SKU senza lavoro manuale.

La pipeline concreta che questo abilita: leggi uno SKU dal feed → genera un titolo/descrizione conforme e asset immagine → caricali dritti nel gruppo di asset, senza alcun passaggio manuale su Canva nel mezzo. Entrambi i servizi sono pre-GA — trattali come un pilota su una fetta del catalogo, non come un rollout su tutto il catalogo, finché non si diplomano.

E poi l’impianto — Ads e Merchant in un unico posto

Il cambiamento più sottovalutato dell’anno è poco appariscente: le due metà di un account e-commerce finalmente si incontrano.

Cosa è cambiato. Dal 22 aprile 2026 la Merchant API è raggiungibile dai Google Ads Scripts. Insieme a product_filters (condivisione condizionale del feed con Google Ads, rilasciata a novembre 2025) e a CartDataSalesView (v24), il loop tra salute del feed e spesa pubblicitaria si chiude dentro un unico ambiente.

Perché conta per il tuo account. Il vecchio scollamento — campagne negli Scripts, feed gestito altrove — faceva sì che un prodotto disapprovato continuasse a bruciare budget finché un umano se ne accorgeva. Ora un solo script può reagire a una disapprovazione del feed mettendo in pausa una campagna o togliendo lo SKU da un listing group di PMax. E CartDataSalesView porta la segmentazione delle conversioni a livello di prodotto nell’API, così ottieni il ROAS a livello di SKU senza cucire a mano i dati di campagna al feed:

-- Product-level ROAS straight from the API (v24+), no manual feed stitching
SELECT segments.product_item_id,
       metrics.conversions_value,
       metrics.cost_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.conversions_value DESC

Quella singola query è l’input per una segmentazione per profittabilità che prima ricostruivi a mano ogni mese. (La risorsa è cart_data_sales_view, rilasciata in v24; conferma la disponibilità dei segmenti nelle release notes per la tua versione.)

L’anno in una sola timeline

Ogni versione maggiore qui sotto arriva dalle release notes ufficiali; le tappe Merchant dagli ultimi aggiornamenti della Merchant API. La colonna di destra è l’unica che dovrebbe guidare il tuo calendario — tutto ciò che ha una data non è negoziabile.

[HARD Aug 18] 1. Feed migration → off v2.1, onto Merchant sub-APIs
[HARD Sep]    2. DSA inventory → run ADOPT_AI_MAX A/B first
[ROLLING]     3. Version watch → alert 60 days pre-sunset
[upside]      4. Asset pipeline → AssetGenerationService / Product Studio
[upside]      5. SKU ROAS → cart_data_sales_view tiering
[upside]      6. Closed loop → Merchant-in-Scripts: disapproval → pause

FAQ