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 gegen diese API, und die meiste Zeit war sie eine träge Oberfläche, die du einmal im Jahr besucht hast, Versionsnummer hoch, vergessen.

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 sitzt ein zweites Datum. Im September 2026 wird jede verbleibende Dynamic-Search-Ads-Kampagne automatisch auf AI Max umgestellt, ob du willst oder nicht.

Diese zwei Uhren sind die Pflichten von Googles API-Jahr. Alles andere, was die Plattform ausgeliefert hat, ist Gelegenheit. 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 welchen exakten Call, Payload oder welche Migration du fährst.

Ich lasse nichts bei „du solltest migrieren” stehen. 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 deinen Feed über die alte API anfasst, 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 gegen die Sub-API-Struktur neu. 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 gegen die Merchant-API-Referenz, denn die Feldnamen haben sich geändert, nicht nur die URL.)

Das Ziel ist ehrlich besser als das, was es ersetzt, und genau den Teil erzählt dir niemand. Drei Verbesserungen, die du durch die Migration gratis erbst:

Wenn du dein Feed-Tooling schon lange härten wolltest, ist die Abschaltung der erzwungene Anlass. Bau einmal neu und geh mit saubererem Error Handling und weniger Round-Trips raus, als v2.1 je erlaubt hat.

Deadline zwei: Dynamic Search Ads werden im September 2026 zu AI Max

Die zweite datierte Änderung, und die, die neu sortiert, wie viel Kontrolle du behältst.

Was sich geändert hat. AI Max for Search erreichte am 15. April 2026 GA, nach dem Beta-Start im Mai 2025. Ab September 2026 stellt Google alle verbleibenden DSA, automatisch erstellten Assets und weitgehend passende Keywords auf Kampagnenebene automatisch auf AI Max um. 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. Der Deal lautet Kontrolle gegen Uplift. Mit dem vollen Funktionsumfang (Suchbegriff-Matching plus Textanpassung plus Final-URL-Expansion) meldet Google rund +7 % Conversions oder Conversion-Wert gegenüber reinem 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 gebacken hast, kann ein stilles September-Upgrade anfangen, Traffic auf URLs und Texte zu schicken, die du nie freigegeben 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:

Der praktische Zug ist der letzte. Leg ein ADOPT_AI_MAX-Experiment über deine Konten an und lass es laufen. Das CPA- und ROAS-Delta liest du ab, indem du die Kampagnen des Experiment-Arms mit der Kontrolle 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 gegen die Release Notes der Version, die du aufrufst.)

Die rollende 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. v20 erreicht ihr Lebensende im Juni 2026, v21 im August, v22 im Oktober. Ein monatlicher Minor-Bump bricht nichts. Ein verpasster Major-Sunset heißt, deine Skripte fangen 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 Feuerwehrübung.

Jetzt der Bonus: KI zieht in Creative und Feed ein

Mit den Deadlines im Griff ist der Rest des Jahres Hebel, den du nach eigenem Zeitplan einsetzt. Zwei Dienste haben Asset- und Feed-Arbeit in etwas verwandelt, das du über 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 zieht 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.

Die Feed-Hälfte nehme ich persönlich. Wir haben bei Lynt zwei Jahre lang Boostera gebaut, eine KI-Schicht, die Merchant-Center-Feeds anreichert, weil die Feed-Qualität die Decke der Shopping- und PMax-Performance ist. Bessere Titel bewegen 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 GA erreichen.

Die Klempnerei: Ads und Merchant endlich an einem Ort

Die am meisten unterschätzte Änderung des Jahres ist unglamourös. 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. Kombiniert mit product_filters (bedingtes Feed-Sharing mit Google Ads, ausgeliefert im November 2025) und CartDataSalesView (v24) schließt sich die Schleife zwischen Feed-Gesundheit und Werbeausgaben in einer Umgebung.

Warum es dein Konto betrifft. Die alte Trennung, Kampagnen in Scripts und der Feed woanders verwaltet, bedeutete, dass ein abgelehntes Produkt Budget verbrannte, 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 ein Profitabilitäts-Tiering, das 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. Die Naht liegt jetzt in zwei API-Calls statt in einem Feed-Export, und du kannst sie validieren. Prüfe, dass die Item-IDs auf beiden Seiten ü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. Alles mit HART 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. Diese Liste ist deine Exposition zum 18. August, 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 der September 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