Et år med Google Ads API: to hårde deadlines, resten er muligheder

I januar udgav Google v23 af Ads API’et og meldte ud, at der fra nu af ville lande en ny version hver måned. Jeg læste beskeden to gange. Jeg har skrevet kode mod det her API i tolv år, og det meste af tiden var det en træg overflade, man besøgte én gang om året, hævede versionsnummeret og glemte.

Så gjorde jeg det, de år har lært mig. Jeg åbnede vores kodebase hos Lynt og søgte efter shoppingcontent.googleapis.com. Hvert hit er et script, der dør den 18. august 2026, dagen hvor Content API for Shopping slukkes. Lige bagved lurer en dato mere. I september 2026 opgraderes hver tilbageværende Dynamic Search Ads-kampagne automatisk til AI Max, uanset om du har bedt om det eller ej.

De to ure er forpligtelserne i Googles API-år. Alt andet, platformen har leveret, er muligheder. AI-tjenester til kreativer, salgsrapportering på produktniveau, Merchant API inde i Google Ads Scripts. Så jeg gennemgår året efter prioritet, hårdeste deadline først. For hver ændring: hvad den er, hvorfor den rammer din konto, og det præcise kald, payload eller den migration, du skal køre.

Jeg efterlader ikke noget ved “du burde migrere.” En deadline uden et konkret artefakt er bare angst. Ved hvert trin får du endpointet, der erstatter det gamle, eksperiment-payloaden eller GAQL-forespørgslen, så du ser præcist, hvad du skal bygge, før datoen kommer.

Deadline nummer et: Content API for Shopping dør den 18. august 2026

Det er årets hårdeste dato, så den kommer først.

Hvad der ændrede sig. Content API for Shopping v2.1 slukkes den 18. august 2026. Afløseren, Merchant API v1, blev GA i juli 2025, og mellemtrinnet v1beta blev allerede slukket den 28. februar 2026. Den gamle monolit erstattes af fokuserede under-API’er. datasources, products, inventories, reports, notifications.

Hvorfor det rammer din konto. Alt, der rører dit feed gennem det gamle API, holder op med at virke den dag. Feed-uploads, supplerende feeds, brugerdefinerede etiketter, pris- og lageropdateringer, læsning af afvisninger. Det her er ikke “kunne være rart at migrere”, det er et hårdt snit. Hvis et dagligt script holder dine priser synkroniseret, bliver det stumt den 18. august, og dit feed glider langsomt væk fra virkeligheden, indtil nogen opdager den tabte omsætning. Jeg har set det fejlmønster på rigtige konti, og det dyre er aldrig selve nedbruddet, det er ugerne, hvor ingen opdager det.

Hvad du skal gøre. Byg om mod under-API-strukturen. Migrationen er mekanisk. Host, sti og ressourcemodel skifter, hensigten består. Her er før og efter for det mest almindelige kald af alle, 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-hosts og under-API-opdelingen stammer fra Googles dokumentation. Bekræft den præcise request-body for din ressource mod Merchant API-referencen, før du går live, for feltnavnene er ændret, ikke kun URL’en.)

Destinationen er ærligt talt bedre end det, den erstatter, og det er den del, ingen fortæller dig. Tre forbedringer, du arver gratis ved at migrere:

Hvis du længe har villet hærde dit feed-værktøj, er nedlukningen den tvungne anledning. Byg om én gang, og gå derfra med renere fejlhåndtering og færre rundture, end v2.1 nogensinde tillod.

Deadline nummer to: Dynamic Search Ads bliver til AI Max i september 2026

Den anden daterede ændring, og den, der flytter rundt på, hvor meget kontrol du beholder.

Hvad der ændrede sig. AI Max for Search nåede GA den 15. april 2026 efter beta-lanceringen i maj 2025. Fra september 2026 opgraderer Google automatisk alle tilbageværende DSA, automatisk oprettede aktiver og bredt match på kampagneniveau til AI Max. Derefter kan du ikke oprette en ny DSA-kampagne. Ikke i brugerfladen, ikke i Editor, ikke via API’et.

Hvorfor det rammer din konto. Byttet er kontrol for løft. Med det fulde funktionssæt (søgetermsmatching plus teksttilpasning plus final-URL-udvidelse) rapporterer Google cirka +7 % konverteringer eller konverteringsværdi i forhold til matching alene. Til gengæld overlader du matching, aktivtekster og valget af landingsside til modellen. Har du brand- eller compliance-regler bygget ind i din DSA-opsætning i hånden, kan en stille september-opgradering begynde at sende trafik til URL’er og tekster, du aldrig har godkendt. Automatisering, du ikke har målt, er automatisering, du ikke styrer.

Hvad du skal gøre. Vent ikke på at se, hvad opgraderingen gør ved dine tal. Mål det nu. Google leverede autoværnene og målekrogene via API’et i takt med funktionen, så du kan A/B-teste skiftet på dine egne data, før det bliver obligatorisk:

Det praktiske træk er det sidste. Opret et ADOPT_AI_MAX-eksperiment på tværs af dine konti, og lad det køre. CPA- og ROAS-deltaet aflæser du ved at sammenligne eksperimentarmens kampagner med kontrollen. Et almindeligt GAQL-træk viser dig derefter, hvad den søgeordsløse udvidelse faktisk matchede og tjente:

-- 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 er en af de nye eksperimenttyper fra v24.1; targeting_expansion_view er rapporteringsressourcen fra v22. Bekræft felttilgængeligheden mod release notes for den version, du kalder.)

Den rullende deadline: en udgivelse hver måned

Ikke en enkelt dato, men et ur, der nu altid tikker.

Hvad der ændrede sig. Fra v23 (28. januar 2026) er Google Ads API gået over til en månedlig udgivelseskadence. Fire major-versioner om året plus månedlige minor-versioner, med ét års support pr. major-version.

Hvorfor det rammer din konto. Hurtigere adgang til funktioner, og hurtigere forældelse. Versioner udløber efter en offentliggjort kalender. v20 når sit livsafslut i juni 2026, v21 i august, v22 i oktober. Et månedligt minor-bump ødelægger ikke noget. En overset major-slukning betyder, at dine scripts begynder at returnere fejl uden anden advarsel end en dato i en kalender, du ikke holdt øje med.

Hvad du skal gøre. Fastlås din version og hold øje med slukningskalenderen. Den billigste forsikring er et tilbagevendende tjek, der ved, hvilken version du kalder, og siger til cirka 60 dage før udløb. Det hele er få linjer:

# 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 fra en slukket version er et selvforskyldt nedbrud. Behandl versionsstyring som en fast tilbagevendende opgave, ikke som en brandøvelse.

Nu til gevinsten: AI flytter ind i kreativer og feed

Med deadlines på plads er resten af året løftestang, du tager i brug efter din egen plan. To tjenester har gjort aktiv- og feedarbejde til noget, du kan scripte hen over tusindvis af SKU’er.

• AssetGenerationService (Ads API, v22, lukket beta). AI-genereret tekst og billeder, med PMax-billedforbedring og -udtræk; v23.2 tilføjede VideoEnhancement til Google-genereret video. Kreativ produktion flytter ud af brugerfladen og ind i et programmerbart lag.
• Product Studio (Merchant API, alfa siden april 2025). AI-genererede produkttitler og -beskrivelser, plus AutomatedDiscounts til realtidspriser. At omskrive titler på API-niveau betyder at masseforbedre tusindvis af SKU’er uden håndarbejde.

Feed-halvdelen tager jeg personligt. Vi brugte to år hos Lynt på at bygge Boostera, et AI-lag, der beriger Merchant Center-feeds, fordi feedkvaliteten er loftet for Shopping- og PMax-performance. Bedre titler flytter mere omsætning end de fleste budændringer. Product Studio bringer en bid af den evne direkte ind i platformen.

Pipelinen, det låser op for, læser en SKU fra feedet, genererer en regelret titel, beskrivelse og billedaktiver og skubber dem direkte ind i aktivgruppen, uden manuelt Canva-trin i midten. Begge tjenester er pre-GA. Behandl dem som en pilot på en skive af kataloget, ikke som en udrulning over hele kataloget, indtil de bliver færdige.

VVS-arbejdet: Ads og Merchant endelig samme sted

Årets mest undervurderede ændring er uglamourøs. De to halvdele af en e-handelskonto ender samme sted.

Hvad der ændrede sig. Siden den 22. april 2026 kan Merchant API nås fra Google Ads Scripts. Kombineret med product_filters (betinget feed-deling med Google Ads, udgivet november 2025) og CartDataSalesView (v24) lukker løkken mellem feed-sundhed og annonceforbrug sig i ét miljø.

Hvorfor det rammer din konto. Den gamle opdeling, kampagner i Scripts og feedet styret et andet sted, betød, at et afvist produkt blev ved med at brænde budget, indtil et menneske opdagede det. Nu kan ét script reagere på en feed-afvisning ved at pause en kampagne eller trække SKU’en ud af en PMax-listegruppe. Og CartDataSalesView bringer omsætning pr. solgt SKU fra kurvdata ind i API’et. Den indeholder omsætning, ikke forbrug, så reel ROAS pr. SKU kræver to forespørgsler. Start med omsætningssiden:

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

Hent derefter omkostningssiden fra shopping_performance_view, og join de to resultater 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 joinede rækker er input til en rentabilitetsinddeling, du før genopbyggede i hånden hver måned. Vi kører forretningsrapportering på kundeniveau i BigQuery for klienter, og halvdelen af arbejdet har altid været at sy annoncedata sammen med produktdata. Sømmen ligger nu i to API-kald i stedet for et feed-eksport, og du kan validere den. Tjek at item-id’erne matcher på begge sider, før du stoler på forholdet. (Ressourcen er cart_data_sales_view, udgivet i v24; bekræft segmenttilgængeligheden i release notes for din version.)

Året på én tidslinje

Hver major-version nedenfor stammer fra de officielle release notes; Merchant-milepælene fra Merchant API latest updates. Højre kolonne er den eneste, der bør styre din kalender. Alt markeret HÅRD er ikke til forhandling.

Den første arbejdstime

Ikke hele migrationen. En grep. Søg i din kodebase efter shoppingcontent.googleapis.com, og skriv hvert job ned, der dukker op. Den liste er din eksponering mod den 18. august, og den tog dig ti minutter.

Brug resten af timen på at oprette ét ADOPT_AI_MAX-eksperiment på den konto, hvor DSA betyder mest, så september ankommer som en målt ændring i stedet for en overraskelse. Deadlines er Googles. Om de rammer dig som nedbrud eller som opgraderinger, er stadig dit valg.

FAQ