Een jaar Google Ads API: twee harde deadlines, de rest is kans

In januari bracht Google v23 van de Ads API uit en kondigde aan dat er vanaf dat moment elke maand een nieuwe versie zou verschijnen. Ik las het bericht twee keer. Ik schrijf al twaalf jaar code tegen deze API, en het grootste deel van die tijd was het een traag oppervlak dat je één keer per jaar bezocht, versienummer omhoog, vergeten.

Toen deed ik wat die jaren me hebben geleerd. Ik opende onze codebase bij Lynt en zocht naar shoppingcontent.googleapis.com. Elke hit is een script dat sterft op 18 augustus 2026, de dag waarop de Content API for Shopping uitgaat. Direct daarachter zit een tweede datum. In september 2026 wordt elke overgebleven Dynamic Search Ads-campagne automatisch omgezet naar AI Max, of je dat nu wilt of niet.

Die twee klokken zijn de verplichtingen van Googles API-jaar. Al het andere dat het platform uitbracht is kans. AI-diensten voor creatives, verkooprapportage op productniveau, de Merchant API binnen Google Ads Scripts. Ik loop het jaar dus door op prioriteit, hardste deadline eerst. Per verandering: wat het is, waarom het jouw account raakt en de exacte call, payload of migratie om te draaien.

Ik laat niets hangen bij “je zou moeten migreren.” Een deadline zonder concreet artefact is alleen maar stress. Bij elke stap krijg je de endpoint die de oude vervangt, de experiment-payload of de GAQL-query, zodat je precies ziet wat je moet bouwen voordat de datum er is.

Deadline één: de Content API for Shopping sterft op 18 augustus 2026

Dit is de hardste datum van het jaar, dus die gaat voor.

Wat er veranderde. De Content API for Shopping v2.1 gaat op 18 augustus 2026 uit. Zijn opvolger, de Merchant API v1, is sinds juli 2025 GA, en de tussenstap v1beta ging al op 28 februari 2026 uit. De oude monoliet wordt vervangen door gerichte sub-API’s. datasources, products, inventories, reports, notifications.

Waarom het jouw account raakt. Alles wat via de oude API aan je feed komt, stopt die dag met werken. Feeduploads, aanvullende feeds, aangepaste labels, prijs- en voorraadupdates, het uitlezen van afkeuringen. Dit is geen “zou mooi zijn om te migreren”, dit is een harde knip. Als een dagelijks script je prijzen synchroon houdt, valt het op 18 augustus stil en drijft je feed langzaam van de werkelijkheid weg tot iemand de gemiste omzet opmerkt. Ik heb dat faalpatroon op echte accounts gezien, en het dure deel is nooit de storing zelf, het zijn de weken waarin niemand het merkt.

Wat te doen. Herbouw tegen de sub-API-structuur. De migratie is mechanisch. Host, pad en resourcemodel veranderen, de bedoeling blijft. Hier is het voor-en-na van de meest voorkomende call van allemaal, een product-upsert:

# 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"} } }'

(De endpoint-hosts en de sub-API-indeling komen uit Googles documentatie. Controleer de exacte request-body voor jouw resource in de Merchant API-referentie voordat je live gaat, want de veldnamen zijn veranderd, niet alleen de URL.)

De bestemming is eerlijk gezegd beter dan wat ze vervangt, en dat is het deel dat niemand je vertelt. Drie verbeteringen die je gratis erft door te migreren:

Als je al langer je feedtooling wilde verstevigen, is de afsluiting het gedwongen moment. Herbouw één keer en kom eruit met schonere foutafhandeling en minder round-trips dan v2.1 ooit toestond.

Deadline twee: Dynamic Search Ads worden in september 2026 AI Max

De tweede gedateerde verandering, en degene die herschikt hoeveel controle je houdt.

Wat er veranderde. AI Max for Search bereikte GA op 15 april 2026 na de bètalancering in mei 2025. Vanaf september 2026 zet Google alle resterende DSA, automatisch gemaakte assets en breed zoeken op campagneniveau automatisch om naar AI Max. Daarna kun je geen nieuwe DSA-campagne meer aanmaken. Niet in de interface, niet in Editor, niet via de API.

Waarom het jouw account raakt. De ruil is controle voor groei. Met de volledige featureset (zoektermmatching plus tekstpersonalisatie plus final-URL-expansie) meldt Google circa +7 % conversies of conversiewaarde tegenover alleen matching. In ruil geef je het model de matching, de assetteksten en de keuze van de landingspagina. Heb je merk- of complianceregels handmatig in je DSA-setup gebakken, dan kan een stille september-upgrade verkeer gaan sturen naar URL’s en teksten die je nooit hebt goedgekeurd. Automatisering die je niet hebt gemeten, is automatisering die je niet beheerst.

Wat te doen. Wacht niet af wat de upgrade met je cijfers doet. Meet het nu. Google leverde de vangrails en de meethaken via de API gelijktijdig met de feature, dus je kunt de omschakeling A/B-testen op je eigen data voordat ze verplicht wordt:

De praktische zet is de laatste. Maak een ADOPT_AI_MAX-experiment aan over je accounts en laat het lopen. De CPA- en ROAS-delta lees je af door de campagnes van de experimentarm te vergelijken met de controle. Een gewone GAQL-pull laat je vervolgens zien wat de keywordloze expansie werkelijk matchte en opleverde:

-- 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 is een van de nieuwe experimenttypes uit v24.1; targeting_expansion_view is de rapportageresource uit v22. Controleer de veldbeschikbaarheid in de release notes van de versie die je aanroept.)

De rollende deadline: elke maand een release

Geen enkele datum, maar een klok die nu altijd tikt.

Wat er veranderde. Vanaf v23 (28 januari 2026) is de Google Ads API overgestapt op een maandelijkse releasecadans. Vier major-versies per jaar plus maandelijkse minor-versies, met één jaar ondersteuning per major-versie.

Waarom het jouw account raakt. Sneller toegang tot features, en sneller verouderen. Versies lopen af volgens een gepubliceerde kalender. v20 bereikt zijn einde in juni 2026, v21 in augustus, v22 in oktober. Een maandelijkse minor-bump breekt niets. Een gemiste major-sunset betekent dat je scripts fouten gaan teruggeven zonder andere waarschuwing dan een datum in een kalender waar je niet naar keek.

Wat te doen. Pin je versie en houd de sunsetkalender in de gaten. De goedkoopste verzekering is een terugkerende check die weet welke versie je aanroept en zo’n 60 dagen voor het verlopen aan de bel trekt. Het hele ding is een paar regels:

# 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

Een 404 van een afgesloten versie is een zelf veroorzaakte storing. Behandel versiebeheer als een vaste terugkerende taak, niet als een brandoefening.

Nu de winst: AI trekt in bij creative en feed

Met de deadlines geregeld is de rest van het jaar hefboom die je op je eigen schema inzet. Twee diensten maakten van asset- en feedwerk iets wat je over duizenden SKU’s kunt scripten.

• AssetGenerationService (Ads API, v22, gesloten bèta). AI-tekst- en beeldgeneratie, met PMax-beeldverbetering en -extractie; v23.2 voegde VideoEnhancement toe voor door Google gegenereerde video. Creative-productie verhuist uit de interface naar een programmeerbare laag.
• Product Studio (Merchant API, alfa sinds april 2025). AI-gegenereerde producttitels en -beschrijvingen, plus AutomatedDiscounts voor realtime prijzen. Titels herschrijven op API-niveau betekent duizenden SKU’s in bulk verbeteren zonder handwerk.

De feedhelft trek ik me persoonlijk aan. We hebben bij Lynt twee jaar aan Boostera gebouwd, een AI-laag die Merchant Center-feeds verrijkt, omdat feedkwaliteit het plafond is van Shopping- en PMax-prestaties. Betere titels verschuiven meer omzet dan de meeste biedingswijzigingen. Product Studio brengt een stuk van die capaciteit het platform zelf in.

De pipeline die dit ontgrendelt leest een SKU uit de feed, genereert een conforme titel, beschrijving en beeldassets en duwt ze rechtstreeks de assetgroep in, zonder handmatige Canva-stap ertussen. Beide diensten zijn pre-GA. Behandel ze als een pilot op een deel van de catalogus, niet als een uitrol over de hele catalogus, tot ze afstuderen.

Het loodgieterswerk: Ads en Merchant eindelijk samen

De meest onderschatte verandering van het jaar is onglamoureus. De twee helften van een e-commerce-account komen op één plek samen.

Wat er veranderde. Sinds 22 april 2026 is de Merchant API bereikbaar vanuit Google Ads Scripts. Gecombineerd met product_filters (voorwaardelijk feeds delen met Google Ads, uitgebracht in november 2025) en CartDataSalesView (v24) sluit de lus tussen feedgezondheid en advertentie-uitgaven binnen één omgeving.

Waarom het jouw account raakt. De oude scheiding, campagnes in Scripts en de feed elders beheerd, betekende dat een afgekeurd product budget bleef verbranden tot een mens het opmerkte. Nu kan één script op een feedafkeuring reageren door een campagne te pauzeren of de SKU uit een PMax-vermeldingsgroep te halen. En CartDataSalesView brengt de omzet per verkochte SKU uit winkelwagendata de API in. De view bevat omzet, geen uitgaven, dus echte ROAS per SKU vraagt twee query’s. Begin met de omzetkant:

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

Haal daarna de kostenkant uit shopping_performance_view en join de twee resultaten op 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

Die gejoinde rijen zijn de input voor een winstgevendheidstiering die je vroeger elke maand met de hand herbouwde. We draaien voor klanten businessrapportage op klantniveau in BigQuery, en het halve werk was altijd advertentiedata aan productdata naaien. De naad zit nu in twee API-calls in plaats van een feedexport, en je kunt hem valideren. Check dat de item-ID’s aan beide kanten matchen voordat je de verhouding vertrouwt. (De resource is cart_data_sales_view, uitgebracht in v24; controleer de segmentbeschikbaarheid in de release notes van jouw versie.)

Het jaar op één tijdlijn

Elke major-versie hieronder komt uit de officiële release notes; de Merchant-mijlpalen uit de Merchant API latest updates. De rechterkolom is de enige die je kalender zou moeten sturen. Alles met HARD is niet onderhandelbaar.

Het eerste uur werk

Niet de hele migratie. Een grep. Doorzoek je codebase op shoppingcontent.googleapis.com en schrijf elke job op die naar boven komt. Die lijst is je blootstelling aan 18 augustus, en hij kostte je tien minuten.

Besteed de rest van het uur aan één ADOPT_AI_MAX-experiment op het account waar DSA het meest telt, zodat september aankomt als een gemeten verandering in plaats van een verrassing. De deadlines zijn van Google. Of ze je raken als storingen of als upgrades, is nog altijd jouw keuze.

FAQ