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

Naročnik mi je nekoč zastavil vprašanje, ki bi moralo imeti odgovor na en klik. Nekdo je iskal „brezžični sesalnik pod 200”, kliknil Shopping oglas in račun je to plačal. Na katerega od 5.000 izdelkov v feedu je ta klik pristal? Odprl sem poročilo o iskalnih poizvedbah, nato poročilo o izdelkih, in ju ni bilo mogoče povezati. Še danes ju ni. Google ti pokaže poizvedbo in pokaže ti izdelek, a nikoli skupaj.

Pred leti ti je stari AdWords API dajal točno ta par. Potem je tiho izginil in nobena nastavitev, nobeno poročilo, nobeno API-polje ga ne vrne. Za spletno trgovino ta vrzel ni kozmetična. 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.

Dvanajst let programiranja ob Google Ads API me je naučilo, da se poročilo, ki ga Google ukine, ne vrne. Zato sem ga znova sestavil sam, in ta rekonstrukcija je skoraj sramotno preprosta. En URL-parameter. V enem tednu ti GA4 postreže vsak plačani klik kot par poizvedba × izdelek, s sejami, konverzijami in prihodkom zraven. Postavitev vzame nekaj minut; preostanek članka govori o tem, kaj narediš s tem, kar pride nazaj.

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 GA4 odpri Raziskovanje in sestavi tabelo proste oblike. Dimenziji sta Ročna vsebina oglasa seje in Iskalna poizvedba Google Ads seje. Metrike so seje, ključni dogodki (prej konverzije) in prihodek od nakupov. Filtriraj vir/medij seje na google / cpc.

Za vse resno boš hotel Data API, ker to poročilo sodi v nadzorno ploščo ali v združevanje v BigQueryju, ne v zavihek brskalnika:

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="keyEvents"),
        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 in ekonomika v eni tabeli.

Preverjeno, ne teoretizirano

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

Zdaj zabavni del: kaj ti pari povedo

1 · Vrzel v naslovu

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

Načrt za feed se napiše sam. Zadnji dve leti gradim AI-orodje za obogatitev feedov in poštena šibkost celotne kategorije je dokazovanje učinka. To poročilo to reši. Prepiši naslov okoli povpraševanja, ki si ga pravkar dokazal, nato opazuj, kako se CTR in stopnja konverzije premikata po poizvedbi. Obogatitev feeda z AI preneha biti skok v vero in postane merljiva zanka.

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

Ene stvari ne moreš narediti. Ne moreš dodati negativnih ključnih besed na izdelek. Google ti v Shoppingu in PMaxu ne ponuja takega vzvoda. Ko torej par poizvedba × izdelek slabo deluje, vprašanje, kako ga izključiti, ne pripelje nikamor. Produktivno vprašanje je, zakaj slabo deluje.

Vzemi poizvedbo in zanjo postrgaj živo stran z rezultati. Jaz uporabljam DataForSEO, končno točko serp/google/organic/live/advanced. En POST z besedilom poizvedbe in location_code tvojega trga vrne celotno stran z rezultati kot strukturiran JSON, plačane oglase, shopping bloke z imeni trgovcev in cenami, organske rezultate spodaj. DataForSEO zaračunava po SERP-u, en SERP pa pokrije do 10 rezultatov. Pri trenutni osnovni ceni približno 0,002 $ na SERP stane preverjanje 200 poizvedb s privzeto globino okoli 0,40 $, brez plačljivih naprednih parametrov.

Tipična ugotovitev. Tvoja spalna vreča srednjega razreda nabira klike na generični poizvedbi, ista poizvedba pa prikazuje tri proračunske znamke v isti kategoriji za polovico tvoje cene. Izdelek je v redu. Cena izgublja točno to dražbo.

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 pa 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 da segmentaciji Shoppinga dokazno podlago in nadomesti občutek v želodcu.

4 · Zdravstveni pregled za PMax

PMax ti o iskanju pove skoraj nič. To poročilo je najbližje reviziji tega, kaj PMax na iskalni površini dejansko kupuje zate, 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, srednje velike češke spletne trgovine v ugodnostnem segmentu. Ni to prodajalec 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. Surovo poročilo ti da skupino oglasov ali skupino izdelkov, pod katero je bila poizvedba prikazana, ne posameznega izdelka. Točno to vrzel zapre trik z UTM. 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), ena srednje velika češka spletna trgovina, ~22,6 mio. vrstic, podatki potegnjeni aprila 2026. Zneski preračunani iz CZK po tečaju ~25 CZK/EUR.

Korak 1 · Potegni surovo poročilo in izmeri kup

Izvozi poročilo o iskalnih poizvedbah za Shopping prek Google Ads API (search_term_view) v karkoli, nad čimer lahko poženeš GROUP BY, v SQLite ali BigQuery. Preden karkoli združiš ali filtriraš, poženi preprost COUNT(*) in nekaj SUM-ov. Začutiti moraš, kako velik in kako hrupen je surovi kup, ker to eno dejstvo na novo nastavi vsako nadaljnje pričakovanje:

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

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

Preštej vrstice z nič kliki, nato jih izfiltriraj. Poročilo o iskalnih poizvedbah za Shopping beleži vsako poizvedbo, pri kateri se je tvoj oglas prikazal, večine teh poizvedb pa ni nihče nikoli kliknil. Vrstice zgolj s prikazi te ne morejo nič stati in ne morejo konvertirati. So šum, zaradi katerega je tabela videti strašljiva.

WHERE clicks > 0 sesede tabelo na 738.444 vrstic, na velikost, s katero se dejansko da delati.

96,7 % strašljive številke ni bilo nikoli nič drugega kot šum. Preden karkoli analiziraš, filtriraj na kliknjene vrstice, tako vsaka spodnja agregacija teče nad delom, ki dejansko troši denar.

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

Pri kliknjenih vrsticah razdeli stroške na „vsaj enkrat konvertiralo” in „nikoli ni konvertiralo” ter seštej stroške obeh skupin. To je številka, ki iz „račun je v redu, ROAS je 6,8” naredi „večina proračuna ne počne ničesar”. Izračunaj jo pred vsako idejo o optimizaciji:

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

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

Zavora je dolgi rep. Zgornji 1 % dragih vrstic drži komaj desetino stroškov, zato zaustavitev 20 slabih izrazov ne spremeni ničesar. Popravi strukturo, torej kateri izdelki sedijo v kateri akciji s katerim ciljem, namesto da loviš posamezne poizvedbe. In ne pozabi, da ti Google negativnih ključnih besed na izdelek tako ali tako ne dovoli.

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

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

Konkreten primer z računa. Poizvedba „naprava proti lajanju” je nenehno kurila proračun, zato sem zanjo pognal COUNT(DISTINCT ad_group). Prikazovala se je pod 139 različnimi skupinami oglasov in izdelkov, za 39 € in približno nič konverzij. „lego technic” se je dotaknil 300.

Skoraj polovica 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 svoj ID izdelka.

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

Potegni vrstice z najvišjimi stroški, ki nikoli niso konvertirale, in preberi poizvedbo ob skupini izdelkov, proti kateri je bila prodana. Agregatne številke prepričajo tvojo preglednico. Te tri vrstice prepričajo tvojega šefa:

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 široke signale feeda, pobral klik in ga zaračunal računu. S poizvedbo × izdelek to vidiš na en pogled; z Googlovim standardnim poročilom nikoli. (Kategorije prevedene in anonimizirane.)

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

Obrni korak 3. Izoliraj le vrstice, ki so konvertirale, in seštej njihove stroške in prihodek. To je razlog, da je celotna vaja pomembna. Ko znaš ločiti zmagovalce od zavore, zmagovalce zaščitiš, ostalo pa izstradaš.

Četrtina 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 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.

FAQ

CTA: Kateri tvoji izdelki si klike zaslužijo in kateri ti jih samo zaračunajo? Dodaj parameter danes in čez teden boš vedel. Ali pa mi pošlji svoj račun in poročilo prebereva skupaj.