Poročilo o iskalnih poizvedbah za Shopping, ki ti ga Google ne da

Svojim akcijam Shopping in Performance Max dodaj en URL-parameter in v enem tednu ti GA4 postreže poročilo, ki ga je Google tiho ukinil: vsak plačani klik povezan kot poizvedba × izdelek — s sejami, konverzijami in prihodkom zraven. Prav v tem paru se skriva denar — kateri izdelki privlačijo smetni promet, kateri naslovi zgrešijo resnično povpraševanje, katere poizvedbe kurijo proračun in nikoli ne prodajo. Vsa postavitev je ta en parameter; preostanek članka govori o tem, kaj počneš s tem, kar pride nazaj.

Če vodiš akcije Shopping ali Performance Max, poznaš poročilo o iskalnih poizvedbah. Česar morda nisi opazil — ker Google na to nikoli ne opozori — je tisto, kar v njem manjka: izdelek.

Vidiš, da je nekdo iskal „brezžični sesalnik pod 200”. Vidiš klike in stroške. Ne vidiš, katerega od tvojih 5.000 izdelkov je ta poizvedba sprožila, na katerega je pripeljala ali katerega je prodala.

Pred leti ti je AdWords API to povezavo dajal. Danes je ne. In za e-commerce račun to ni kozmetična vrzel — poizvedba na izdelek je tam, kjer živi resnična optimizacija: ali se tvoji naslovi ujemajo z resničnim povpraševanjem, kateri izdelki privlačijo smetni promet, zakaj izdelek dobiva klike, a nikoli ne konvertira.

Preden vprašaš: ne, za to ni nastavitve. Ni poročila, ni polja v API-ju, ni skripta, ki bi to vrnil z Googlove strani. Sam moraš to znova sestaviti — in ponovna izgradnja je skoraj sramotno preprosta.

Rešitev: en parameter, dve dimenziji GA4

Samodejno označevanje in ročni UTM se ne tepeta med seboj: gclid še naprej skrbi za vir, medij in akcijo; tvoj UTM nosi le ID izdelka.

Vedi, kaj dobiš (in česa ne)

Kako poročilo potegniti iz GA4

V vmesniku: Raziskovanje → prosta oblika. Dimenziji: Ročna vsebina oglasa seje + Iskalna poizvedba Google Ads seje. Metrike: seje, konverzije, prihodek od nakupov. Filter: vir/medij seje = google / cpc.

Prek Data API — za vse resno to napaja nadzorno ploščo ali združevanje v BigQuery:

from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import (
    RunReportRequest, DateRange, Dimension, Metric, FilterExpression, Filter
)

request = RunReportRequest(
    property=f"properties/{GA4_PROPERTY_ID}",
    dimensions=[
        Dimension(name="sessionManualAdContent"),  # product ID
        Dimension(name="sessionGoogleAdsQuery"),    # search term
    ],
    metrics=[
        Metric(name="sessions"),
        Metric(name="conversions"),
        Metric(name="purchaseRevenue"),
    ],
    date_ranges=[DateRange(start_date="30daysAgo", end_date="today")],
    dimension_filter=FilterExpression(filter=Filter(
        field_name="sessionSourceMedium",
        string_filter=Filter.StringFilter(value="google / cpc"),
    )),
)

Združi sessionManualAdContent s svojim product feedom (id → naslov, cena, kategorija) in poročilo je popolno: poizvedba × izdelek × naslov × ekonomika.

Preverjeno, ne teoretizirano

To smo uvedli na živem računu — češkem prodajalcu elektronike z 22 vklopljenimi akcijami Shopping — in GA4 preverili sedem dni pozneje:

Zdaj zabavni del: kaj ti pari povedo

1 · Vrzel v naslovu

Postavi poizvedbe ob naslov in opis, ki so ga sprožile. Neujemanje takoj skoči v oči:

Načrt za feed se napiše sam. In tu obogatitev feeda z AI preneha biti skok v vero in postane merljiva zanka: prepiši naslov okoli povpraševanja, ki si ga pravkar dokazal, nato opazuj, kako se CTR in stopnja konverzije na poizvedbo premakneta.

2 · Kdo še tekmuje za „tvojo” poizvedbo — in s katerim izdelkom

Ena stvar, ki je ne moreš narediti: dodati negativne ključne besede na izdelek. Google ti v Shoppingu ali PMax ne ponuja takega vzvoda. Ko torej par poizvedba × izdelek slabo deluje, vprašanje ni „kako ga izključim” — temveč „zakaj slabo deluje”.

Vzemi poizvedbo in postrgaj živo stran z rezultati zanjo. Konkretno: DataForSEO, končna točka serp/google/organic/live/advanced — en POST z besedilom poizvedbe in location_code tvojega trga in dobiš nazaj celotno stran z rezultati kot strukturiran JSON: plačani oglasi, shopping bloki z imeni trgovcev in cenami, organski rezultati spodaj. Pri ~0,0035 $ na poizvedbo preverjanje 200 poizvedb stane približno 0,70 $.

Tipična ugotovitev: tvoja spalna vreča srednjega razreda nabira klike na generično poizvedbo — in ista poizvedba prikazuje tri proračunske znamke v isti kategoriji za polovično ceno. Tvoj izdelek ni slab; v točno tej dražbi je premagan po ceni.

Zdaj imaš prave možnosti: na novo določi ceno; potisni razlikovalni element v naslov („polnilo iz puha, udobje do −15 °C”); premakni izdelek v akcijo z oblikovanjem ponudb, ki ustreza njegovi marži; ali poizvedbo sprejmi kot zgornji del lijaka in jo sodi po asistiranih metrikah namesto po zadnjem kliku.

3 · Odločitve o strukturi in oblikovanju ponudb

Izdelki, ki privlačijo poizvedbe z visokim namenom, si zaslužijo lastne skupine elementov in proračune. Izdelki, ki nabirajo le generični promet, sodijo v zbirne skupine s konservativnimi cilji. To poročilo je dokazna podlaga za segmentacijo Shopping — ne občutek v želodcu.

4 · Zdravstveni pregled za PMax

PMax ti o iskanju pove skoraj nič. To poročilo je najbližje, kar boš prišel reviziji tega, kaj PMax dejansko kupuje zate na iskalni površini — na izdelek.

Glej, kako korak za korakom prehodim en pravi izvoz

Vse zgornje je zakaj. Tukaj je kako to dejansko izgleda — vsak korak, kaj preneseš, v kaj buljiš in katera prava številka pride nazaj.

Podatki so iz drugega računa: drugega srednje velikega češkega e-shopa (ne prodajalca elektronike iz GA4-okvirja zgoraj — uporabljam ga, ker je njegov katalog dovolj širok, da se vsak vzorec pokaže v polni velikosti). Njegovo surovo poročilo o iskalnih poizvedbah za Shopping sem prek Google Ads API potegnil v lokalno tabelo SQLite in nad njim pognal spodnje agregacije. Najprej eno opozorilo: to surovo poročilo ti da skupino oglasov / skupino izdelkov, pod katero je bila poizvedba prikazana, ne posameznega izdelka. Točno to vrzel zapre trik z UTM-jem — a tudi na ravni skupine izdelkov so vmesni rezultati dovolj glasni, da dokažejo poanto.

Vir za vsako številko v tem razdelku: poročilo o iskalnih poizvedbah za Shopping (Google Ads), en srednje velik češki e-shop, ~22,6 mio. vrstic, podatki potegnjeni aprila 2026.

Korak 1 · Potegni surovo poročilo in izmeri kup

Kaj narediš: izvozi poročilo o iskalnih poizvedbah za Shopping prek Google Ads API (search_term_view) v lokalno tabelo — SQLite ali BigQuery, karkoli, nad čimer lahko poženeš GROUP BY. Zakaj prav to najprej: preden karkoli združiš, moraš začutiti, kako velik in kako hrupen je surovi kup. To eno dejstvo na novo nastavi vsako nadaljnje pričakovanje.

Poženi preprost COUNT(*) in nekaj SUM-ov in to pristane:

Kaj imaš: 22,6 milijona vrstic, 5,4 milijona edinstvenih poizvedb. Tega ne prebere noben človek. Edina naloga te številke je, da ti pove naslednjo potezo — ta kup zložiš po dimenziji, ki plačuje račune — in da te opozori, da je vsako ročno razvrščanje vrstico za vrstico brezupno.

Korak 2 · Zavrzi 96 % tega, preden karkoli analiziraš

Kaj narediš: preštej vrstice z nič kliki, nato jih izfiltriraj. Zakaj: poročilo o iskalnih poizvedbah za Shopping beleži vsako poizvedbo, za katero se je tvoj oglas prikazal, na večino pa nihče ni kliknil. Te vrstice zgolj s prikazi te ne morejo nič stati in ne morejo konvertirati — so šum, ki tabelo dela strašljivo.

Situacija: 22,6 mio. vrstic, ne veš, kje začeti. Dejanje: WHERE clicks > 0. Rezultat: tabela se sesede na 738.444 vrstic — obvladljiva velikost.

Kaj imaš: 96,7 % strašljive številke ni bilo nikoli nič drugega kot šum. Zdaj delaš z 738.000-vrstično tabelo, ne z 22,6-milijonsko — in vsaka spodnja agregacija teče nad delom, ki dejansko troši denar.

Korak 3 · Zastavi eno vprašanje, ki na novo preriše račun

Kaj narediš: pri kliknjenih vrsticah razdeli stroške na „vsaj enkrat konvertiralo” proti „nikoli ni konvertiralo” in seštej stroške vsake skupine. Zakaj: to je številka, ki iz „račun je v redu, ROAS je 6,8” naredi „večina proračuna ne počne ničesar”. To je osrednji vmesni rezultat — izračunaj ga pred vsako idejo o optimizaciji.

Kaj imaš: 85 % proračuna je teklo skozi kombinacije poizvedba × skupina izdelkov, ki niso konvertirale niti enkrat. To ni napaka zaokroževanja, ki bi jo zgladil pozneje — to je glavni dogodek. In videl si ga le zato, ker si poizvedbo zložil na to, proti čemur je bila prodana.

Korak 4 · Preveri, ali je zapravljanje delo nekaj zlikovcev ali cele množice

Kaj narediš: kliknjene vrstice razvrsti po stroških, vzemi zgornji 1 % in zgornjih 10 % ter poglej, kolikšen del skupnih stroškov držijo. Zakaj: to določi tvojo taktiko. Če peščica poizvedb kuri proračun, jih zaustaviš in končal si. Če je zapravljanje tanko razpršeno, je zaustavljanje poizvedb nesmiselno — potrebuješ strukturne popravke.

Kaj imaš: zavora je dolgi rep, ne nekaj prestopnikov — zgornji 1 % dragih vrstic drži komaj desetino stroškov. Tako zaustavitev 20 slabih poizvedb ne spremeni ničesar. To je s podatki podprt razlog, da popraviš strukturo (kateri izdelek sedi v kateri akciji s katerim ciljem) namesto loviti posamezne poizvedbe — in opomnik, da ti Google negativnih na izdelek tako ali tako ne dovoli.

Korak 5 · Ugotovi, zakaj dolgi rep pušča: ena poizvedba, mnogo izdelkov

Kaj narediš: za vsako iskalno poizvedbo preštej, pod koliko različnimi skupinami izdelkov je bila prikazana. Zakaj: to mehanično pojasni zapravljanje. Shopping ujema poizvedbo s signali tvojega celotnega feeda, ne z ustreznostjo enega izdelka — tako ena sama poizvedba pušča v nepovezane kote tvojega kataloga in ti plačaš vsak zgrešeni zadetek.

Situacija: „naprava proti lajanju” nenehno kuri proračun. Dejanje: COUNT(DISTINCT ad_group) za ta izraz. Rezultat: prikazoval se je pod 139 različnimi skupinami oglasov / izdelkov za 976 CZK in ~0 konverzij. „lego technic” se je dotaknil 300.

Kaj imaš: skoraj polovica tvojih poizvedb je razmazana čez več skupin izdelkov, najhujše pa dosežejo tisoče. To je motor zavore ničelne konverzije iz Koraka 3 — in točno tisto, kar lahko končno vidiš, ko vsak klik nosi ID svojega izdelka.

Korak 6 · Z očmi preleti najhujša neujemanja — absurdna so

Kaj narediš: potegni vrstice z najvišjimi stroški, ki nikoli niso konvertirale, in preberi poizvedbo ob skupini izdelkov, proti kateri je bila prodana. Zakaj: agregatne številke prepričajo tvojo preglednico; te tri vrstice prepričajo tvojega šefa. So človeku berljiv obraz Koraka 5.

Poizvedba za ovratnico za dresuro psov, plačana pod skupino Torbice. Naprava proti lajanju, prodana proti Izdelkom za dojenčke. Skupina izdelkov nima nobene zveze s poizvedbo — Google je ujemal na grobe signale feeda, pobral klik in ti ga zaračunal. S poizvedbo × izdelek to vidiš na en pogled; z Googlovim standardnim poročilom nikoli. (Ilustrativni primer — kategorije prevedene in anonimizirane.)

Korak 7 · Zdaj nagrada: 0,25 %, ki plača celoten račun

Kaj narediš: obrni Korak 3 — izoliraj le vrstice, ki so konvertirale, in seštej njihove stroške in prihodek. Zakaj: to je razlog, da je celotna vaja pomembna. Ko zmagovalce ločiš od zavore, jih zaščitiš, ostale pa izstradaš.

Kaj imaš: četrtina enega odstotka vrstic teče pri 46,8× ROAS in dejansko nosi račun; preostalih 99,75 % vleče mešano številko navzdol na 6,8×. Najti to rezino, zaščititi njen proračun in vse drugo strukturno odmakniti od nje — to je celotno delo — in nič od tega ni mogoče, dokler vsaka vrstica ne nosi izdelka, proti kateremu je bila prodana. Točno to ti kupi UTM z enim parametrom z vrha tega članka.

{lpurl}?utm_content={product_id}

FAQ