Ein Jahr Google Ads API: zwei harte Deadlines, der Rest ist Chance

Im Januar hat Google v23 der Ads API veröffentlicht und angekündigt, dass ab jetzt jeden Monat eine neue Version erscheint. Ich habe die Notiz zweimal gelesen. Ich schreibe seit zwölf Jahren Code, der diese API aufruft, und die meiste Zeit hat sie sich so langsam verändert, dass du einmal im Jahr vorbeischauen, die Versionsnummer hochziehen und sie wieder vergessen konntest.

Dann habe ich getan, was mir diese Jahre beigebracht haben. Ich habe unsere Codebase bei Lynt geöffnet und nach shoppingcontent.googleapis.com gesucht. Jeder Treffer ist ein Skript, das am 18. August 2026 stirbt, dem Tag, an dem die Content API for Shopping abgeschaltet wird. Direkt dahinter liegt ein zweites Datum, und Google hat es bereits verschoben: Ab Februar 2027 wird jede verbleibende Dynamic-Search-Ads-Kampagne automatisch auf AI Max umgestellt, ob du willst oder nicht. Im September 2026 kommen automatisch erstellte Assets und weitgehend passende Keywords auf Kampagnenebene zuerst dran.

Diese beiden Termine schreibt dir Googles API-Jahr vor. Alles andere, was die Plattform ausgeliefert hat, ist eine Chance: KI-Dienste für Creatives, Verkaufsreporting auf Produktebene, die Merchant API in Google Ads Scripts. Ich gehe das Jahr nach Priorität durch, härteste Deadline zuerst. Bei jeder Änderung: was sie ist, warum sie dein Konto betrifft und welcher Call, welcher Payload oder welche Migration konkret ansteht.

Ich belasse es nicht bei „du solltest migrieren“. Eine Deadline ohne konkretes Artefakt ist nur Angst. Bei jedem Schritt bekommst du den Endpoint, der den alten ersetzt, den Experiment-Payload oder die GAQL-Query, damit du genau siehst, was du bauen musst, bevor das Datum kommt.

Deadline eins: die Content API for Shopping stirbt am 18. August 2026

Das ist das härteste Datum des Jahres, also kommt es zuerst.

Was sich geändert hat. Die Content API for Shopping v2.1 wird am 18. August 2026 abgeschaltet. Ihr Nachfolger, die Merchant API v1, ist seit Juli 2025 GA, und die Zwischenstufe v1beta wurde bereits am 28. Februar 2026 abgeschaltet. Den alten Monolithen ersetzen fokussierte Sub-APIs. datasources, products, inventories, reports, notifications.

Warum es dein Konto betrifft. Alles, was über die alte API auf deinen Feed zugreift, hört an diesem Tag auf zu funktionieren. Feed-Uploads, ergänzende Feeds, benutzerdefinierte Labels, Preis- und Bestandsupdates, das Auslesen von Ablehnungen. Das ist kein „wäre schön zu migrieren“, das ist ein harter Schnitt. Wenn ein tägliches Skript deine Preise synchron hält, verstummt es am 18. August, und dein Feed driftet langsam von der Realität weg, bis jemand den verlorenen Umsatz bemerkt. Ich habe dieses Fehlerbild auf echten Konten gesehen, und teuer ist nie der Ausfall selbst, teuer sind die Wochen, in denen ihn niemand bemerkt.

Was zu tun ist. Bau deine Integration auf der neuen Sub-API-Struktur neu auf. Die Migration ist mechanisch. Host, Pfad und Ressourcenmodell ändern sich, die Absicht bleibt. Hier das Vorher-Nachher für den häufigsten Call überhaupt, ein Produkt-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"} } }'

(Endpoint-Hosts und der Sub-API-Schnitt stammen aus Googles Doku. Prüfe den exakten Request-Body für deine Ressource vor dem Deployment in der Merchant-API-Referenz, denn die Feldnamen haben sich geändert, nicht nur die URL.)

Die Merchant API v1 ist eine bessere API als die Content API, die sie ersetzt, und genau das erzählt dir niemand. Drei Verbesserungen, die du durch die Migration gratis erbst:

Wenn du dein Feed-Tooling schon lange härten wolltest, zwingt dich die Abschaltung jetzt dazu. Bau einmal neu, und du kommst mit saubererem Error Handling und weniger Round-Trips heraus, als v2.1 je erlaubt hat.

Deadline zwei: Dynamic Search Ads werden im Februar 2027 zu AI Max

Das ist die zweite Änderung mit festem Datum, und sie verschiebt, wie viel Kontrolle du behältst.

Was sich geändert hat. AI Max for Search erreichte am 15. April 2026 den GA-Status, nach dem Beta-Start im Mai 2025. Der Rollout erfolgt in zwei Schritten: Ab September 2026 stellt Google Kampagnen mit automatisch erstellten Assets und weitgehend passenden Keywords auf Kampagnenebene automatisch um; die Abschaltung und automatische Umstellung der DSA selbst beginnen im Februar 2027, nachdem Google den ursprünglich angekündigten September-Termin verschoben hat. Danach kannst du keine neue DSA-Kampagne mehr anlegen. Nicht in der UI, nicht im Editor, nicht über die API.

Warum es dein Konto betrifft. Du tauschst Kontrolle gegen Uplift. Mit dem vollen Funktionsumfang (Suchbegriff-Matching plus Textanpassung plus Erweiterung der finalen URL) meldet Google rund +7 % Conversions oder Conversion-Wert gegenüber reinem Suchbegriff-Matching. Im Gegenzug gibst du dem Modell das Matching, die Asset-Texte und die Wahl der Landingpage. Wenn du Brand- oder Compliance-Regeln von Hand in dein DSA-Setup eingebaut hast, kann ein stilles Auto-Upgrade anfangen, Traffic auf URLs zu schicken, die du nie freigegeben hast, mit Anzeigentexten, die du nie abgenommen hast. Automatisierung, die du nicht gemessen hast, ist Automatisierung, die du nicht steuerst.

Was zu tun ist. Warte nicht ab, was das Upgrade mit deinen Zahlen macht. Miss es jetzt. Google hat die Leitplanken und die Mess-Hooks im Gleichschritt mit dem Feature über die API ausgeliefert, du kannst den Wechsel also auf deinen eigenen Daten A/B-testen, bevor er Pflicht wird:

Praktisch zählt vor allem das ADOPT_AI_MAX-Experiment. Leg eines kontenübergreifend an und lass es laufen. Das CPA- und ROAS-Delta liest du ab, indem du die Kampagnen des Experiment-Arms mit den Kontrollkampagnen vergleichst. Ein normaler GAQL-Pull zeigt dir dann, was die keywordlose Expansion tatsächlich gematcht und eingebracht hat:

-- 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 ist einer der neuen Experimenttypen aus v24.1; targeting_expansion_view ist die Reporting-Ressource aus v22. Prüfe die Feldverfügbarkeit in den Release Notes der Version, die du aufrufst.)

Die gleitende Deadline: jeden Monat ein Release

Kein einzelnes Datum, sondern eine Uhr, die jetzt immer tickt.

Was sich geändert hat. Ab v23 (28. Januar 2026) ist die Google Ads API auf eine monatliche Release-Kadenz umgestiegen. Vier Major-Versionen pro Jahr plus monatliche Minor-Versionen, mit einem Jahr Support pro Major-Version.

Warum es dein Konto betrifft. Schnellerer Zugriff auf Features, und schnelleres Veralten. Versionen laufen nach einem veröffentlichten Kalender aus. Der Support für v20 endet im Juni 2026, für v21 im August, für v22 im Oktober. Ein monatlicher Minor-Bump bricht nichts. Wenn du einen Major-Sunset verpasst, fangen deine Skripte an, Fehler zurückzugeben, ohne andere Warnung als ein Datum in einem Kalender, den du nicht beobachtet hast.

Was zu tun ist. Pinne deine Version und beobachte den Sunset-Kalender. Die billigste Versicherung ist ein wiederkehrender Check, der weiß, welche Version du aufrufst, und sich etwa 60 Tage vor Ablauf meldet. Das Ganze sind ein paar Zeilen:

# 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

Ein 404 von einer abgeschalteten Version ist ein selbstverschuldeter Ausfall. Behandle Versions-Governance als stehende, wiederkehrende Aufgabe, nicht als Notfall in letzter Minute.

Jetzt der Bonus: KI zieht in Creatives und Feeds ein

Mit den Deadlines im Griff bestimmst du beim Rest des Jahres das Tempo selbst. Zwei Dienste haben Asset- und Feed-Arbeit in etwas verwandelt, das du für Tausende SKUs skripten kannst.

• AssetGenerationService (Ads API, v22, geschlossene Beta). KI-Text- und Bildgenerierung, mit PMax-Bildverbesserung und -Extraktion; v23.2 ergänzte VideoEnhancement für Google-generiertes Video. Die Creative-Erstellung wandert aus der UI in eine programmierbare Schicht.
• Product Studio (Merchant API, Alpha seit April 2025). KI-generierte Produkttitel und -beschreibungen, plus AutomatedDiscounts für Preise in Echtzeit. Titel auf API-Ebene umzuschreiben heißt, Tausende SKUs ohne Handarbeit in Serie zu verbessern.

Bei der Feed-Hälfte habe ich ein persönliches Interesse. Wir haben bei Lynt zwei Jahre lang Boostora gebaut, eine KI-Schicht, die Merchant-Center-Feeds anreichert, weil die Feed-Qualität die Obergrenze für Shopping- und PMax-Performance ist. Bessere Titel bringen mehr Umsatz als die meisten Gebotsänderungen. Product Studio bringt ein Stück dieser Fähigkeit direkt in die Plattform.

Die Pipeline, die das freischaltet, liest eine SKU aus dem Feed, generiert einen konformen Titel, eine Beschreibung und Bild-Assets und schiebt sie direkt in die Asset-Gruppe, ohne manuellen Canva-Zwischenschritt. Beide Dienste sind Pre-GA. Behandle sie als Pilot auf einem Ausschnitt des Katalogs, nicht als katalogweiten Rollout, bis sie den GA-Status erreichen.

Der Maschinenraum: Ads und Merchant endlich an einem Ort

Die am meisten unterschätzte Änderung des Jahres ist unspektakulär. Die zwei Hälften eines E-Commerce-Kontos landen an einem Ort.

Was sich geändert hat. Seit dem 22. April 2026 ist die Merchant API aus Google Ads Scripts erreichbar. Kombiniere das mit product_filters (bedingtes Feed-Sharing mit Google Ads, ausgeliefert im November 2025) und CartDataSalesView (v24), und die Schleife vom Feed-Zustand bis zu den Werbeausgaben schließt sich in einer einzigen Umgebung.

Warum es dein Konto betrifft. Früher lagen die Kampagnen in Scripts und der Feed irgendwo anders. Ein abgelehntes Produkt verbrannte weiter Budget, bis ein Mensch es bemerkte. Jetzt kann ein einziges Skript auf eine Feed-Ablehnung reagieren, indem es eine Kampagne pausiert oder die SKU aus einer PMax-Eintragsgruppe zieht. Und CartDataSalesView bringt den Umsatz pro verkaufter SKU aus den Warenkorbdaten in die API. Sie liefert Umsatz, keine Kosten, echter SKU-ROAS braucht also zwei Queries. Fang mit der Umsatzseite an:

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

Dann hol die Kostenseite aus shopping_performance_view und joine beide Ergebnisse über 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

Diese gejointen Zeilen sind der Input für die Profitabilitätsstufen, die du früher jeden Monat von Hand neu gebaut hast. Wir fahren für Kunden Business-Reporting auf Kundenebene in BigQuery, und die halbe Arbeit war schon immer das Vernähen von Werbedaten mit Produktdaten. Zwei API-Calls erledigen jetzt die Näharbeit, für die früher ein Feed-Export nötig war, und das Ergebnis kannst du selbst kontrollieren. Prüfe, ob die Item-IDs in beiden Queries übereinstimmen, bevor du dem Verhältnis traust. (Die Ressource ist cart_data_sales_view aus v24; prüfe die Segmentverfügbarkeit in den Release Notes deiner Version.)

Das Jahr auf einer Timeline

Jede Major-Version unten stammt aus den offiziellen Release Notes; die Merchant-Meilensteine aus den Merchant API latest updates. Die rechte Spalte ist die einzige, die deinen Kalender steuern sollte. Jede Zeile mit dem Flag HARD ist nicht verhandelbar.

Die erste Arbeitsstunde

Nicht die ganze Migration. Ein Grep. Durchsuche deine Codebase nach shoppingcontent.googleapis.com und schreib jeden Job auf, der auftaucht. Auf dieser Liste steht alles, was am 18. August für dich auf dem Spiel steht, und sie hat dich zehn Minuten gekostet.

Den Rest der Stunde nutzt du, um ein ADOPT_AI_MAX-Experiment auf dem Konto anzulegen, auf dem DSA am meisten zählt, damit das Upgrade als gemessene Änderung ankommt statt als Überraschung. Die Deadlines gehören Google. Ob sie dich als Ausfälle treffen oder als Upgrades, ist immer noch deine Entscheidung.

FAQ