Un anno di Google Ads API: due scadenze tassative, il resto è opportunità

A gennaio Google ha rilasciato la v23 dell’Ads API e ha annunciato che da quel momento sarebbe uscita una nuova versione ogni mese. L’ho letto due volte. Scrivo codice contro questa API da dodici anni, e per la maggior parte del tempo è stata una superficie lenta che visitavi una volta l’anno, alzavi il numero di versione e dimenticavi.

Poi ho fatto quello che quegli anni mi hanno insegnato a fare. Ho aperto il nostro codice in Lynt e ho cercato shoppingcontent.googleapis.com. Ogni risultato è uno script che muore il 18 agosto 2026, il giorno in cui si spegne la Content API for Shopping. Subito dietro c’è una seconda data. A settembre 2026 ogni campagna Dynamic Search Ads rimasta passa automaticamente ad AI Max, che tu lo voglia o no.

Questi due orologi sono gli obblighi dell’anno API di Google. Tutto il resto che la piattaforma ha rilasciato è opportunità. Servizi di IA per le creatività, reporting delle vendite a livello di prodotto, la Merchant API dentro Google Ads Scripts. Quindi percorrerò l’anno in ordine di priorità, la scadenza più dura per prima. Per ogni cambiamento, cos’è, perché riguarda il tuo account e la chiamata, il payload o la migrazione esatta da eseguire.

Non lascerò nulla al livello di “dovresti migrare”. Una scadenza senza un artefatto concreto è solo ansia. A ogni passo hai l’endpoint che sostituisce quello vecchio, il payload dell’esperimento o la query GAQL, così vedi esattamente cosa costruire prima che la data arrivi.

Scadenza numero uno: la Content API for Shopping muore il 18 agosto 2026

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

Cosa è cambiato. La Content API for Shopping v2.1 si spegne il 18 agosto 2026. Il suo successore, la Merchant API v1, è in GA da luglio 2025, e l’intermedia v1beta si è già spenta il 28 febbraio 2026. Il vecchio monolite è sostituito da sotto-API focalizzate. datasources, products, inventories, reports, notifications.

Perché riguarda il tuo account. Tutto ciò che tocca il tuo feed attraverso la vecchia API smette di funzionare quel giorno. Caricamenti di feed, feed supplementari, etichette personalizzate, aggiornamenti di prezzo e stock, letture delle disapprovazioni. Questo non è un “sarebbe bello migrare”, è un taglio netto. Se uno script giornaliero ti tiene i prezzi sincronizzati, il 18 agosto ammutolisce e il feed si allontana lentamente dalla realtà finché qualcuno non nota il fatturato perso. Ho visto questo tipo di guasto su account reali, e la parte costosa non è mai il blackout in sé, sono le settimane in cui nessuno se ne accorge.

Cosa fare. Ricostruisci contro la struttura a sotto-API. La migrazione è meccanica. Cambiano host, percorso e modello delle risorse, l’intento resta lo stesso. Ecco il prima e dopo della chiamata più comune di tutte, l’upsert di un 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 '{ "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "productAttributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Gli host degli endpoint e la suddivisione in sotto-API vengono dalla documentazione di Google. Verifica il body esatto della richiesta per la tua risorsa nella reference della Merchant API prima del deploy, perché sono cambiati i nomi dei campi, non solo l’URL.)

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

Se da tempo volevi irrobustire i tuoi strumenti per i feed, lo spegnimento è la spinta che serviva. Ricostruisci una volta ed esci con una gestione errori più pulita e meno round-trip di quanti la v2.1 abbia mai permesso.

Scadenza numero due: le Dynamic Search Ads diventano AI Max a settembre 2026

Il secondo cambiamento con data, e quello che ridefinisce quanto controllo mantieni.

Cosa è cambiato. AI Max for Search ha raggiunto la GA il 15 aprile 2026 dopo il lancio in beta a maggio 2025. Da settembre 2026 Google fa passare automaticamente ad AI Max tutte le DSA rimaste, gli asset creati automaticamente e la corrispondenza generica a livello di campagna. Dopo, una nuova campagna DSA non la crei più. Non nell’interfaccia, non in Editor, non via API.

Perché riguarda il tuo account. Lo scambio è controllo in cambio di crescita. Con il set completo di funzionalità (matching dei termini più personalizzazione del testo più espansione dell’URL finale) Google riporta circa +7 % di conversioni o valore di conversione rispetto al solo matching. In cambio consegni al modello il matching, i testi degli asset e la scelta della pagina di destinazione. Se hai regole di brand o compliance montate a mano nel tuo setup DSA, un passaggio silenzioso a settembre può iniziare a mandare traffico verso URL e testi che non hai mai approvato. L’automazione che non hai misurato è automazione che non controlli.

Cosa fare. Non aspettare di scoprire cosa fa l’aggiornamento ai tuoi numeri. Misuralo adesso. Google ha rilasciato i guardrail e gli agganci di misurazione via API di pari passo con la funzionalità, quindi 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 sui tuoi account e lascialo girare. Il delta di CPA e ROAS lo leggi confrontando le campagne del braccio sperimentale con il controllo. Una normale query GAQL ti mostra poi cosa ha davvero abbinato e fruttato l’espansione senza parole chiave:

-- 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 è uno dei nuovi tipi di esperimento della v24.1; targeting_expansion_view è la risorsa di reporting della v22. Verifica la disponibilità dei campi nelle release notes della versione che chiami.)

La scadenza mobile: un rilascio ogni mese

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

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

Perché riguarda il tuo account. Accesso più rapido alle funzionalità, e obsolescenza più rapida. Le versioni scadono secondo un calendario pubblicato. La v20 arriva al fine vita a giugno 2026, la v21 ad agosto, la v22 a ottobre. Un bump minore mensile non rompe nulla. Perdere il sunset di una versione maggiore significa che i tuoi script iniziano a restituire errori senza altro avviso che una data in un calendario che non stavi guardando.

Cosa fare. Fissa la tua versione e sorveglia il calendario dei sunset. L’assicurazione più economica è un controllo ricorrente che sa quale versione chiami e ti avvisa circa 60 giorni prima della scadenza. Il tutto sta in 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"}  # 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 spenta è un blackout autoinflitto. Tratta la governance delle versioni come un compito ricorrente permanente, non come un’esercitazione antincendio.

Ora il vantaggio: l’IA si trasferisce in creatività e feed

Sistemate le scadenze, il resto dell’anno è leva che adotti con i 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, beta chiusa). Generazione di testi e immagini con IA, con miglioramento ed estrazione delle immagini per PMax; la v23.2 ha aggiunto VideoEnhancement per i video generati da Google. La produzione creativa esce dall’interfaccia ed entra in uno strato programmabile.
• Product Studio (Merchant API, alpha da aprile 2025). Titoli e descrizioni di prodotto generati dall’IA, più AutomatedDiscounts per i prezzi in tempo reale. Riscrivere i titoli a livello di API significa migliorare in blocco migliaia di SKU senza lavoro manuale.

La metà feed me la prendo sul personale. In Lynt abbiamo passato due anni a costruire Boostera, uno strato di IA che arricchisce i feed del Merchant Center, perché la qualità del feed è il tetto delle performance di Shopping e PMax. Titoli migliori spostano più fatturato della maggior parte delle modifiche alle offerte. Product Studio porta un pezzo di quella capacità direttamente nella piattaforma.

La pipeline che questo sblocca legge uno SKU dal feed, genera un titolo, una descrizione e asset immagine conformi e li spinge dritti nel gruppo di asset, senza passaggio manuale in 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.

L’idraulica: Ads e Merchant finalmente insieme

Il cambiamento più sottovalutato dell’anno non ha alcun glamour. Le due metà di un account e-commerce finiscono nello stesso posto.

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

Perché riguarda il tuo account. La vecchia separazione, campagne in Scripts e feed gestito altrove, significava che un prodotto disapprovato continuava a bruciare budget finché un umano non se ne accorgeva. Ora un solo script può reagire a una disapprovazione nel feed mettendo in pausa una campagna o togliendo lo SKU da un gruppo di schede PMax. E CartDataSalesView porta nell’API i ricavi per SKU venduto dai dati del carrello. Contiene i ricavi, non la spesa, quindi il vero ROAS per SKU richiede due query. Parti dal lato ricavi:

-- 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

Poi estrai il lato costi da shopping_performance_view e unisci i due risultati su 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

Quelle righe unite sono l’input di un tiering di redditività che prima ricostruivi a mano ogni mese. Per i clienti gestiamo business reporting a livello di cliente in BigQuery, e metà del lavoro è sempre stata cucire i dati pubblicitari a quelli di prodotto. La cucitura ora vive in due chiamate API invece che in un export del feed, e puoi validarla. Controlla che gli item ID coincidano su entrambi i lati prima di fidarti del rapporto. (La risorsa è cart_data_sales_view, rilasciata nella v24; verifica la disponibilità dei segmenti nelle release notes della tua versione.)

L’anno su un’unica timeline

Ogni versione maggiore qui sotto viene dalle release notes ufficiali; le pietre miliari Merchant dalle Merchant API latest updates. La colonna di destra è l’unica che dovrebbe guidare il tuo calendario. Tutto ciò che è marcato TASSATIVO non è negoziabile.

La prima ora di lavoro

Non l’intera migrazione. Un grep. Cerca shoppingcontent.googleapis.com nel tuo codice e annota ogni job che salta fuori. Quella lista è la tua esposizione al 18 agosto, e ti è costata dieci minuti.

Dedica il resto dell’ora a creare un esperimento ADOPT_AI_MAX sull’account dove le DSA pesano di più, così settembre arriva come un cambiamento misurato e non come una sorpresa. Le scadenze sono di Google. Se ti colpiranno come blackout o come upgrade, è ancora una tua scelta.

FAQ