Ett år med Google Ads API: två hårda deadlines, resten är möjligheter

I januari släppte Google v23 av Ads API:et och meddelade att en ny version från och med då skulle landa varje månad. Jag läste noteringen två gånger. Jag har skrivit kod mot det här API:et i tolv år, och större delen av den tiden var det en trög yta man besökte en gång om året, höjde versionsnumret och glömde.

Sedan gjorde jag det de åren har lärt mig att göra. Jag öppnade vår kodbas på Lynt och sökte efter shoppingcontent.googleapis.com. Varje träff är ett skript som dör den 18 augusti 2026, dagen då Content API for Shopping stängs av. Direkt bakom sitter ett andra datum. I september 2026 uppgraderas varje kvarvarande Dynamic Search Ads-kampanj automatiskt till AI Max, vare sig du bett om det eller inte.

De två klockorna är skyldigheterna i Googles API-år. Allt annat plattformen levererade är möjlighet. AI-tjänster för kreativt material, försäljningsrapportering på produktnivå, Merchant API inne i Google Ads Scripts. Så jag går igenom året i prioritetsordning, hårdaste deadline först. För varje förändring: vad den är, varför den rör ditt konto och exakt vilket anrop, vilken payload eller vilken migrering du ska köra.

Jag tänker inte lämna något vid “du borde migrera.” En deadline utan en konkret artefakt är bara ångest. Vid varje steg får du endpointen som ersätter den gamla, experiment-payloaden eller GAQL-frågan, så att du ser exakt vad du ska bygga innan datumet kommer.

Deadline ett: Content API for Shopping dör den 18 augusti 2026

Det här är årets hårdaste datum, så det går först.

Vad som ändrades. Content API for Shopping v2.1 stängs av den 18 augusti 2026. Efterträdaren, Merchant API v1, blev GA i juli 2025, och mellansteget v1beta stängdes redan av den 28 februari 2026. Den gamla monoliten ersätts av fokuserade under-API:er. datasources, products, inventories, reports, notifications.

Varför det rör ditt konto. Allt som rör din feed via det gamla API:et slutar fungera den dagen. Feeduppladdningar, kompletterande feeds, anpassade etiketter, pris- och lageruppdateringar, läsning av underkännanden. Det här är inget “vore trevligt att migrera”, det är ett hårt avbrott. Om ett dagligt skript håller dina priser i synk tystnar det den 18 augusti, och din feed glider sakta bort från verkligheten tills någon märker de förlorade intäkterna. Jag har sett det felmönstret på riktiga konton, och det dyra är aldrig själva avbrottet, det är veckorna då ingen märker det.

Vad du ska göra. Bygg om mot under-API-strukturen. Migreringen är mekanisk. Värden, sökvägen och resursmodellen ändras, avsikten består. Här är före och efter för det vanligaste anropet av alla, en 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-värdarna och under-API-uppdelningen kommer från Googles dokumentation. Bekräfta den exakta request-bodyn för din resurs mot Merchant API-referensen innan du släpper, för fältnamnen ändrades, inte bara URL:en.)

Destinationen är ärligt talat bättre än det den ersätter, och det är den delen ingen berättar. Tre förbättringar du ärver gratis genom att migrera:

Om du länge tänkt härda din feedtooling är avstängningen det tvingande tillfället. Bygg om en gång och gå ut med renare felhantering och färre rundresor än v2.1 någonsin tillät.

Deadline två: Dynamic Search Ads blir AI Max i september 2026

Den andra daterade förändringen, och den som ritar om hur mycket kontroll du behåller.

Vad som ändrades. AI Max for Search nådde GA den 15 april 2026 efter betalanseringen i maj 2025. Från september 2026 uppgraderar Google automatiskt alla kvarvarande DSA, automatiskt skapade tillgångar och bred matchning på kampanjnivå till AI Max. Efter det kan du inte skapa en ny DSA-kampanj. Inte i gränssnittet, inte i Editor, inte via API:et.

Varför det rör ditt konto. Bytet är kontroll mot lyft. Med hela funktionsuppsättningen (söktermsmatchning plus textanpassning plus final-URL-expansion) rapporterar Google cirka +7 % konverteringar eller konverteringsvärde jämfört med enbart matchning. I gengäld lämnar du över matchningen, tillgångstexterna och valet av landningssida till modellen. Har du varumärkes- eller complianceregler handbyggda i din DSA-uppsättning kan en tyst septemberuppgradering börja skicka trafik till URL:er och texter du aldrig godkänt. Automation du inte har mätt är automation du inte styr.

Vad du ska göra. Vänta inte på att få se vad uppgraderingen gör med dina siffror. Mät det nu. Google levererade skyddsräckena och mätkrokarna via API:et i takt med funktionen, så du kan A/B-testa bytet på din egen data innan det blir obligatoriskt:

Det praktiska draget är det sista. Skapa ett ADOPT_AI_MAX-experiment över dina konton och låt det rulla. CPA- och ROAS-deltat läser du av genom att jämföra experimentarmens kampanjer mot kontrollen. En vanlig GAQL-hämtning visar dig sedan vad den nyckelordslösa expansionen faktiskt matchade och drog in:

-- 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 är en av de nya experimenttyperna från v24.1; targeting_expansion_view är rapporteringsresursen från v22. Bekräfta fälttillgängligheten mot release notes för versionen du anropar.)

Den rullande deadlinen: en release varje månad

Inte ett enskilt datum, utan en klocka som nu alltid tickar.

Vad som ändrades. Från v23 (28 januari 2026) har Google Ads API gått över till månatlig releasetakt. Fyra major-versioner om året plus månatliga minor-versioner, med ett års support per major-version.

Varför det rör ditt konto. Snabbare tillgång till funktioner, och snabbare föråldring. Versioner löper ut enligt en publicerad kalender. v20 når sitt livsslut i juni 2026, v21 i augusti, v22 i oktober. En månatlig minor-höjning bryter ingenting. En missad major-avstängning betyder att dina skript börjar returnera fel utan annan varning än ett datum i en kalender du inte bevakade.

Vad du ska göra. Pinna din version och bevaka avstängningskalendern. Den billigaste försäkringen är en återkommande kontroll som vet vilken version du anropar och larmar cirka 60 dagar innan den löper ut. Hela grejen är några rader:

# 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

En 404 från en avstängd version är ett självförvållat avbrott. Behandla versionsstyrning som en stående återkommande uppgift, inte som en brandövning.

Nu uppsidan: AI flyttar in i kreativt material och feed

Med deadlinerna hanterade är resten av året hävstång du tar in enligt ditt eget schema. Två tjänster gjorde tillgångs- och feedarbete till något du kan skripta över tusentals SKU:er.

• AssetGenerationService (Ads API, v22, stängd beta). AI-genererad text och bild, med PMax-bildförbättring och -extraktion; v23.2 lade till VideoEnhancement för Google-genererad video. Kreativ produktion flyttar ut ur gränssnittet till ett programmerbart lager.
• Product Studio (Merchant API, alfa sedan april 2025). AI-genererade produkttitlar och beskrivningar, plus AutomatedDiscounts för priser i realtid. Att skriva om titlar på API-nivå betyder att massförbättra tusentals SKU:er utan handarbete.

Feedhalvan tar jag personligt. Vi ägnade två år på Lynt åt att bygga Boostera, ett AI-lager som berikar Merchant Center-feeds, eftersom feedkvaliteten är taket för Shopping- och PMax-prestandan. Bättre titlar flyttar mer intäkt än de flesta budändringar. Product Studio tar in en bit av den förmågan i själva plattformen.

Pipelinen det låser upp läser en SKU från feeden, genererar en regelrätt titel, beskrivning och bildtillgångar och trycker in dem direkt i tillgångsgruppen, utan manuellt Canva-steg i mitten. Båda tjänsterna är pre-GA. Behandla dem som en pilot på en skiva av katalogen, inte som en utrullning över hela katalogen, tills de examineras.

Rörmokeriet: Ads och Merchant äntligen på samma ställe

Årets mest underskattade förändring är oglamorös. De två halvorna av ett e-handelskonto hamnar på ett ställe.

Vad som ändrades. Sedan den 22 april 2026 nås Merchant API från Google Ads Scripts. Kombinerat med product_filters (villkorad feeddelning med Google Ads, släppt november 2025) och CartDataSalesView (v24) sluts loopen mellan feedhälsa och annonsutgifter inom en och samma miljö.

Varför det rör ditt konto. Den gamla uppdelningen, kampanjer i Scripts och feeden hanterad någon annanstans, innebar att en underkänd produkt fortsatte bränna budget tills en människa märkte det. Nu kan ett enda skript reagera på ett feedunderkännande genom att pausa en kampanj eller dra SKU:n ur en PMax-listgrupp. Och CartDataSalesView tar in intäkten per såld SKU från kundvagnsdata i API:et. Vyn bär intäkter, inte kostnader, så verklig ROAS per SKU kräver två frågor. Börja med intäktssidan:

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

Hämta sedan kostnadssidan från shopping_performance_view och joina de två resultaten på 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

De joinade raderna är indata till en lönsamhetsindelning du förr byggde om för hand varje månad. Vi kör affärsrapportering på kundnivå i BigQuery åt klienter, och halva jobbet har alltid varit att sy ihop annonsdata med produktdata. Sömmen ligger nu i två API-anrop i stället för en feedexport, och du kan validera den. Kontrollera att item-ID:na matchar på båda sidor innan du litar på kvoten. (Resursen är cart_data_sales_view, släppt i v24; bekräfta segmenttillgängligheten i release notes för din version.)

Året på en enda tidslinje

Varje major-version nedan kommer från de officiella release notes; Merchant-milstolparna från Merchant API latest updates. Högerkolumnen är den enda som borde styra din kalender. Allt märkt HÅRD är icke förhandlingsbart.

Den första arbetstimmen

Inte hela migreringen. En grep. Sök igenom din kodbas efter shoppingcontent.googleapis.com och skriv ner varje jobb som dyker upp. Den listan är din exponering mot den 18 augusti, och den tog dig tio minuter.

Ägna resten av timmen åt att skapa ett ADOPT_AI_MAX-experiment på kontot där DSA betyder mest, så att september kommer som en uppmätt förändring i stället för en överraskning. Deadlinerna är Googles. Om de träffar dig som avbrott eller som uppgraderingar är fortfarande ditt val.

FAQ