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 notisen två gånger. Jag har skrivit kod som anropar det här API:et i tolv år, och större delen av den tiden ändrades det så långsamt att du kunde titta förbi en gång om året, höja versionsnumret och glömma bort det.

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. Tätt inpå följer ett andra datum, och Google har redan flyttat det: Från februari 2027 uppgraderas varje kvarvarande Dynamic Search Ads-kampanj automatiskt till AI Max, vare sig du bett om det eller inte. Automatiskt skapade tillgångar och bred matchning på kampanjnivå uppgraderas först, i september 2026.

De två datumen är skyldigheterna i Googles API-år. Allt annat plattformen levererade är en 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 del-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 stopp. 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 din integration mot den nya strukturen med del-API:er. 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 uppdelningen i del-API:er kommer från Googles dokumentation. Bekräfta den exakta request-bodyn för din resurs i Merchant API-referensen innan du släpper, för fältnamnen ändrades, inte bara URL:en.)

Merchant API v1 är ett bättre API än det Content API det 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 så tvingar avstängningen dig till det nu. Bygg om en gång, så står du kvar med renare felhantering och färre anrop fram och tillbaka än v2.1 någonsin tillät.

Deadline två: Dynamic Search Ads blir AI Max i februari 2027

Det här är den andra förändringen med fast datum, och den 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. Utrullningen sker i två steg: från september 2026 uppgraderar Google automatiskt kampanjer som använder automatiskt skapade tillgångar och bred matchning på kampanjnivå, medan själva DSA-avvecklingen och den automatiska uppgraderingen börjar i februari 2027, en flytt från det septemberdatum Google först meddelade. 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. Du byter kontroll mot lyft. Med hela funktionsuppsättningen (söktermsmatchning plus textanpassning plus utökning av slutlig webbadress) rapporterar Google cirka +7 % konverteringar eller konverteringsvärde jämfört med enbart söktermsmatchning. I gengäld lämnar du över matchningen, tillgångstexterna och valet av målsida till modellen. Har du varumärkes- eller efterlevnadsregler handbyggda i din DSA-uppsättning kan en tyst automatisk uppgradering börja leda trafik till URL:er du aldrig har godkänt, samtidigt som den använder annonstexter du aldrig har godkänt. Automatisering du inte har mätt är automatisering 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ätmöjligheterna via API:et i takt med funktionen, så du kan A/B-testa bytet på din egen data innan det blir obligatoriskt:

Det mest praktiska är att köra ett ADOPT_AI_MAX-experiment. Skapa ett i dina konton och låt det rulla. CPA- och ROAS-deltat läser du av genom att jämföra experimentarmens kampanjer med kontrollkampanjerna. 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 i 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 slutet på sin livscykel 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. Lås fast 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 nödsituation i sista stund.

Nu uppsidan: AI flyttar in i kreativt material och feed

Med deadlinerna hanterade bestämmer du själv takten för resten av året. Två tjänster gjorde tillgångs- och feedarbete till något du kan skripta för 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.

Jag har ett personligt intresse i feedhalvan här. Vi ägnade två år på Lynt åt att bygga Boostora, ett AI-lager som berikar Merchant Center-feeds, eftersom feedkvaliteten är taket för Shopping- och PMax-prestandan. Bättre titlar ger mer omsättning än de flesta budändringar gör. Product Studio tar in en bit av den förmågan i själva plattformen.

Pipelinen som det här låser upp läser en SKU ur feeden, genererar en titel som följer reglerna, en 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 del av katalogen, inte som en utrullning över hela katalogen, tills de når GA.

Kopplingen: 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. När du kombinerar den åtkomsten med product_filters (villkorad feeddelning med Google Ads, släppt november 2025) och CartDataSalesView (v24) sluts loopen från feedens status till annonsutgifterna inom en och samma miljö.

Varför det rör ditt konto. Den gamla uppdelningen höll kampanjerna i Scripts och feeden någon annanstans. 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-listningsgrupp. Och CartDataSalesView tar in intäkten per såld SKU från kundvagnsdata i API:et. Vyn innehåller 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 de lönsamhetsnivåer du förr byggde om för hand varje månad. Vi kör affärsrapportering på kundnivå i BigQuery åt kunder, och halva jobbet har alltid varit att sy ihop annonsdata med produktdata. Två API-anrop sköter nu hopsyningen som förr krävde en feedexport, och du kan kontrollera resultatet själv. Se till att item-ID:na matchar i båda frågorna 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. Varje rad med flaggan HARD är icke förhandlingsbar.

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 allt du har i riskzonen 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 uppgraderingen 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