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 che chiama questa API da dodici anni, e per la maggior parte del tempo è cambiata così piano che bastava occuparsene una volta l’anno, alzare il numero di versione e poi dimenticarsene.

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, che Google ha già spostato: da febbraio 2027 ogni campagna Dynamic Search Ads rimasta passa automaticamente ad AI Max, che tu lo voglia o no. A settembre 2026 tocca prima alle campagne che usano gli asset creati automaticamente e la corrispondenza generica a livello di campagna.

Queste due date sono gli obblighi che Google ti impone quest’anno. Tutto il resto che la piattaforma ha rilasciato è un’opportunità: servizi di AI per le creatività, reporting delle vendite a livello di prodotto, la Merchant API dentro Google Ads Scripts. Quindi passerò in rassegna l’anno in ordine di priorità, partendo dalla scadenza più tassativa. Per ogni cambiamento ti dico cos’è, perché riguarda il tuo account e qual è la chiamata, il payload o la migrazione esatta da eseguire.

Non mi fermerò al «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 scadenza più tassativa dell’anno, quindi viene per prima.

Cosa è cambiato. La Content API for Shopping v2.1 si spegne il 18 agosto 2026. La sua sostituta, 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 sub-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 la tua integrazione sulla nuova struttura delle sub-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 sub-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 Merchant API v1 è migliore della Content API a cui subentra, 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 è ciò che finalmente ti costringe a farlo. Ricostruisci una volta e ne esci con una gestione degli errori più pulita e meno round-trip di quanti la v2.1 ne abbia mai permessi.

Scadenza numero due: le Dynamic Search Ads diventano AI Max a febbraio 2027

Questo è il secondo cambiamento con una data fissa, e 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. Il passaggio avviene in due fasi: da settembre 2026 Google fa passare automaticamente ad AI Max le campagne che usano gli asset creati automaticamente e la corrispondenza generica a livello di campagna; lo spegnimento e il passaggio automatico delle DSA iniziano invece a febbraio 2027, dopo che Google ha rinviato la data annunciata inizialmente per settembre. Da quel momento una nuova campagna DSA non la crei più. Non nell’interfaccia, non in Editor, non via API.

Perché riguarda il tuo account. Cedi controllo in cambio di performance. Con il set completo di funzionalità (corrispondenza dei termini 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 dei termini di ricerca. In cambio consegni al modello la corrispondenza, i testi degli asset e la scelta della pagina di destinazione. Se hai regole di brand o compliance montate a mano nella tua configurazione DSA, un aggiornamento automatico silenzioso può iniziare a mandare traffico verso URL che non hai mai approvato e a usare testi pubblicitari che non hai mai autorizzato. 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 via API le protezioni e i punti di misurazione di pari passo con la funzionalità, quindi puoi testare il passaggio in A/B sui tuoi dati prima che diventi obbligatorio:

La scelta operativa è l’esperimento ADOPT_AI_MAX. Creane uno in ciascuno dei tuoi account e lascialo girare. Il delta di CPA e ROAS lo leggi confrontando le campagne del braccio sperimentale con le campagne di controllo. Una normale query GAQL ti mostra poi quali query ha effettivamente intercettato l’espansione senza parole chiave e quanto ha generato:

-- 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. L’aggiornamento mensile a una versione minore 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 che scada quella versione. 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’emergenza dell’ultimo minuto.

Ora il vantaggio: l’AI entra nelle creatività e nel feed

Sistemate le scadenze, il resto dell’anno procede al ritmo che decidi tu. 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 AI, 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’AI, 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.

Sul lato feed ho un interesse personale. In Lynt abbiamo passato due anni a costruire Boostora, uno strato di AI che arricchisce i feed del Merchant Center, perché la qualità del feed determina il massimo rendimento che Shopping e PMax possono raggiungere. Titoli migliori portano più fatturato di quanto faccia la 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 inserisce direttamente nel gruppo di asset, senza passaggi manuali intermedi in Canva. 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 arrivano alla GA.

Gli ingranaggi: 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. Combina questa possibilità con product_filters (condivisione condizionale del feed con Google Ads, rilasciata a novembre 2025) e CartDataSalesView (v24). Così il circuito che va dallo stato del feed alla spesa pubblicitaria si chiude in un unico ambiente.

Perché riguarda il tuo account. La vecchia separazione teneva le campagne in Scripts e il feed da un’altra parte. 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 dati sui ricavi del carrello, suddivisi per SKU venduto. La vista 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 la materia prima delle fasce di redditività che prima ricostruivi a mano ogni mese. In BigQuery gestiamo per gli account che seguiamo il reporting di business a livello di cliente finale, e metà del lavoro è sempre consistita nel collegare i dati pubblicitari a quelli di prodotto. Ora due chiamate API eseguono il collegamento che prima richiedeva un export del feed, e il risultato puoi verificarlo da solo. Controlla che gli item ID coincidano nelle due query 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 tappe Merchant dalle Merchant API latest updates. La colonna di destra è l’unica che dovrebbe guidare il tuo calendario. Ogni riga che porta l’etichetta HARD è inderogabile.

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 è tutto ciò che rischi il 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ì l’aggiornamento automatico arriva come un cambiamento misurato e non come una sorpresa. Le scadenze sono di Google. Che ti arrivino come blackout o come upgrade, dipende ancora da te.

FAQ