Leto z Google Ads API-jem: dva trda roka, ostalo je priložnost

Januarja je Google izdal v23 Ads API-ja in napovedal, da bo odtlej nova različica izšla vsak mesec. Sporočilo sem prebral dvakrat. Dvanajst let pišem kodo, ki kliče ta API, in večino tega časa se je spreminjal dovolj počasi, da si vanj pogledal enkrat na leto, dvignil številko različice in nanj spet pozabil.

Potem sem naredil to, česar so me ta leta naučila. Odprl sem našo kodo v Lyntu in poiskal shoppingcontent.googleapis.com. Vsak zadetek je skripta, ki umre 18. avgusta 2026, na dan, ko ugasne Content API for Shopping. Za tem datumom je še drugi, ki ga je Google že prestavil: od februarja 2027 vsaka preostala kampanja Dynamic Search Ads samodejno preide na AI Max, pa če to hočeš ali ne. Septembra 2026 se najprej nadgradijo kampanje, ki uporabljajo samodejno ustvarjene elemente in široko ujemanje na ravni kampanje.

Ta dva datuma sta obvezni del letošnjega leta z Google Ads API-jem. Vse ostalo, kar je platforma izdala, je priložnost: AI storitve za kreative, poročanje o prodaji na ravni izdelka, Merchant API znotraj Google Ads Scripts. Zato bom leto prehodil po prioriteti, najtrši rok najprej. Za vsako spremembo: kaj je, zakaj zadeva tvoj račun in kateri točen klic, payload ali migracijo pognati.

Ničesar ne bom pustil pri »moral bi migrirati«. Rok brez konkretnega artefakta je samo tesnoba. Na vsakem koraku dobiš endpoint, ki nadomešča starega, payload eksperimenta ali poizvedbo GAQL, da natančno vidiš, kaj zgraditi, preden datum pride.

Rok številka ena: Content API for Shopping umre 18. avgusta 2026

To je najtrši datum leta, zato gre prvi.

Kaj se je spremenilo. Content API for Shopping v2.1 ugasne 18. avgusta 2026. Njegov naslednik, Merchant API v1, je v GA od julija 2025, vmesna v1beta pa je že ugasnila 28. februarja 2026. Stari monolit nadomeščajo namenski pod-API-ji. datasources, products, inventories, reports, notifications.

Zakaj zadeva tvoj račun. Vse, kar se tvojega feeda dotika prek starega API-ja, tisti dan preneha delovati. Nalaganje feedov, dopolnilni feedi, oznake po meri, posodobitve cen in zalog, branje zavrnitev. To ni »lepo bi bilo migrirati«, to je trd rez. Če ti dnevna skripta sinhronizira cene, 18. avgusta utihne in feed se počasi razide z resničnostjo, dokler kdo ne opazi izgubljenega prihodka. Ta vzorec odpovedi sem videl na resničnih računih in drag ni nikoli sam izpad, dragi so tedni, ko ga nihče ne opazi.

Kaj storiti. Prepiši svojo integracijo na novo strukturo pod-API-jev. Migracija je mehanska. Spremenijo se gostitelj, pot in model virov, namen ostane. Tu je stanje prej in potem pri najpogostejšem klicu od vseh, pri upsertu izdelka:

# 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"} } }'

(Gostitelji endpointov in delitev na pod-API-je prihajajo iz Googlove dokumentacije. Točen body zahteve za svoj vir pred objavo preveri v referenci Merchant API, ker so se spremenila imena polj, ne le URL.)

Merchant API v1 je boljši API od Content API-ja, ki ga nadomešča, in prav tega ti nihče ne pove. Tri izboljšave, ki jih z migracijo podeduješ zastonj:

Če se že dolgo pripravljaš utrditi svoja orodja za feede, te bo ugasnitev končno prisilila, da to res narediš. Prepiši enkrat in dobil boš čistejše ravnanje z napakami in manj klicev v obe smeri, kot jih je v2.1 kdaj dopuščal.

Rok številka dve: Dynamic Search Ads februarja 2027 postane AI Max

To je druga sprememba s fiksnim datumom in prerazporedi, koliko nadzora ti ostane.

Kaj se je spremenilo. AI Max for Search je dosegel GA 15. aprila 2026 po beta zagonu maja 2025. Uvajanje poteka v dveh korakih: septembra 2026 Google kampanje, ki uporabljajo samodejno ustvarjene elemente in široko ujemanje na ravni kampanje, samodejno prenese na AI Max, ukinitev in samodejna nadgradnja samih DSA pa se začneta februarja 2027, saj ju je Google prestavil s prvotno napovedanega septembra. Potem nove kampanje DSA ne ustvariš več. Ne v vmesniku, ne v Editorju, ne prek API-ja.

Zakaj zadeva tvoj račun. Nadzor menjaš za rast. S celotnim naborom funkcij (ujemanje izrazov plus prilagajanje besedila plus širitev končnih URL-jev) Google navaja približno +7 % konverzij ali vrednosti konverzij v primerjavi z zgolj ujemanjem iskalnih izrazov. V zameno modelu predaš ujemanje, besedila elementov in izbiro ciljne strani. Če imaš pravila znamke ali skladnosti ročno vgrajena v svojo postavitev DSA, lahko tihi samodejni prehod začne pošiljati promet na URL-je, ki jih nisi odobril, pri tem pa uporablja neodobrena besedila oglasov. Avtomatizacija, ki je nisi izmeril, je avtomatizacija, ki je ne nadzoruješ.

Kaj storiti. Ne čakaj, da vidiš, kaj bo prehod naredil tvojim številkam. Izmeri zdaj. Google je varovalke in merilne točke prek API-ja izdal sočasno s funkcijo, zato lahko prehod A/B testiraš na lastnih podatkih, preden postane obvezen:

Praktična poteza je eksperiment ADOPT_AI_MAX. Ustvari ga na svojih računih in ga pusti teči. Delto CPA in ROAS prebereš tako, da kampanje eksperimentalne veje primerjaš s kontrolnimi kampanjami. Običajna poizvedba GAQL ti nato pokaže, kaj je širitev brez ključnih besed v resnici ujela in zaslužila:

-- 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 je eden od novih tipov eksperimentov iz v24.1; targeting_expansion_view je poročevalski vir iz v22. Razpoložljivost polj preveri v release notes različice, ki jo kličeš.)

Drseči rok: izdaja vsak mesec

Ne en sam datum, ampak ura, ki zdaj tiktaka nenehno.

Kaj se je spremenilo. Od v23 (28. januarja 2026) je Google Ads API prešel na mesečni ritem izdaj. Štiri major različice na leto plus mesečne minor različice, z enim letom podpore na major različico.

Zakaj zadeva tvoj račun. Hitrejši dostop do funkcij in hitrejše zastaranje. Različice se iztečejo po objavljenem koledarju. v20 doseže konec življenjske dobe junija 2026, v21 avgusta, v22 oktobra. Mesečni minor dvig ničesar ne pokvari. Zamujena ugasnitev major različice pomeni, da tvoje skripte začnejo vračati napake brez drugega opozorila kot datuma v koledarju, ki ga nisi spremljal.

Kaj storiti. Pripni svojo različico in spremljaj koledar ugasnitev. Najcenejše zavarovanje je ponavljajoča se preverba, ki ve, katero različico kličeš, in se oglasi približno 60 dni pred iztekom. Vse skupaj je nekaj vrstic:

# 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

404 z ugasnjene različice je izpad, ki si si ga privoščil sam. Obravnavaj upravljanje različic kot stalno ponavljajočo se nalogo, ne kot nekaj, kar rešuješ v zadnjem trenutku.

Zdaj priložnost: AI se seli v kreative in feed

Z urejenimi roki preostanek leta poteka v ritmu, ki ga določiš sam. Dve storitvi sta delo z elementi in feedom spremenili v nekaj, kar skriptaš za tisoče SKU-jev.

• AssetGenerationService (Ads API, v22, zaprta beta). Besedila in slike, ki jih generira AI, z izboljšavo in izločanjem slik za PMax; v23.2 je dodala VideoEnhancement za video, ki ga generira Google. Ustvarjanje kreativ se seli iz vmesnika v programabilno plast.
• Product Studio (Merchant API, alpha od aprila 2025). Naslovi in opisi izdelkov, ki jih generira AI, plus AutomatedDiscounts za cene v realnem času. Prepisovanje naslovov na ravni API-ja pomeni množično izboljšanje tisočev SKU-jev brez ročnega dela.

Polovica, ki zadeva feede, je zame osebna stvar. V Lyntu smo dve leti gradili Boostoro, AI plast, ki bogati feede Merchant Centra, ker kakovost feeda določa zgornjo mejo učinkovitosti Shoppinga in PMaxa. Boljši naslovi prinesejo več prihodka kot večina sprememb ponudb. Product Studio prinaša kos te zmožnosti naravnost v platformo.

Pipeline, ki ga to odklene, prebere SKU iz feeda, generira skladen naslov, opis in slikovne elemente ter jih potisne naravnost v skupino elementov, brez ročnega koraka v Canvi vmes. Obe storitvi sta pre-GA. Obravnavaj ju kot pilot na rezini kataloga, ne kot uvedbo na cel katalog, dokler ne prideta v GA.

Infrastruktura: Ads in Merchant končno skupaj

Najbolj podcenjena sprememba leta je povsem neglamurozna. Obe polovici e-commerce računa se znajdeta na enem mestu.

Kaj se je spremenilo. Od 22. aprila 2026 je Merchant API dosegljiv iz Google Ads Scripts. Ko temu dodaš product_filters (pogojno deljenje feeda z Google Ads, izdano novembra 2025) in CartDataSalesView (v24), se zanka od stanja feeda do oglaševalske porabe zapre v enem okolju.

Zakaj zadeva tvoj račun. Stara delitev je držala kampanje v okolju Google Ads Scripts, feed pa nekje drugje. Zavrnjen izdelek je kuril proračun naprej, dokler tega ni opazil človek. Zdaj se lahko ena sama skripta odzove na zavrnitev v feedu tako, da ustavi kampanjo ali umakne SKU iz skupine vnosov v PMaxu. In CartDataSalesView prinaša v API prihodek po prodanem SKU-ju iz podatkov o košarici. Nosi prihodek, ne porabe, zato pravi ROAS po SKU zahteva dve poizvedbi. Začni s prihodkovno stranjo:

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

Nato potegni stroškovno stran iz shopping_performance_view in oba rezultata združi prek 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

Te združene vrstice so vhod v razrede donosnosti, ki si jih prej vsak mesec sestavljal ročno. Za stranke poganjamo poslovno poročanje na ravni kupca v BigQueryju in polovica dela je bila od nekdaj šivanje oglaševalskih podatkov s podatki o izdelkih. Šivanje, ki je prej terjalo izvoz feeda, zdaj opravita dva klica API-ja, rezultat pa lahko sam preveriš. Preveri, da se item ID-ji ujemajo v obeh poizvedbah, preden zaupaš razmerju. (Vir je cart_data_sales_view, izdan v v24; razpoložljivost segmentov preveri v release notes svoje različice.)

Leto na eni časovnici

Vsaka major različica spodaj prihaja iz uradnih release notes; mejniki Merchanta iz Merchant API latest updates. Desni stolpec je edini, ki naj bi vodil tvoj koledar. Vsaka vrstica z oznako HARD je obvezna.

Prva ura dela

Ne cela migracija. Grep. Poišči v kodi shoppingcontent.googleapis.com in zapiši vsako opravilo, ki se pojavi. Ta seznam je vse, kar ti je 18. avgusta ogroženo, vzel pa ti je deset minut.

Preostanek ure nameni ustvarjanju enega eksperimenta ADOPT_AI_MAX na računu, kjer DSA šteje največ, da nadgradnja pride kot izmerjena sprememba in ne kot presenečenje. Roki so Googlovi. Ali te zadenejo kot izpadi ali kot nadgradnje, je še vedno tvoja izbira.

FAQ