Poročilo o iskalnih izrazih 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 izrazih, nato poročilo o izdelkih, in ju ni bilo mogoče povezati. Še danes ni mogoče. 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. Povezava med poizvedbo in izdelkom je tam, kjer živi resnična optimizacija: prav ta ti pove, ali se tvoji naslovi ujemajo z resničnim povpraševanjem, kateri izdelki privlačijo promet za v smeti in zakaj izdelek dobiva klike, a nikoli ne konvertira.

Dvanajst let gradnje na Google Ads API-ju 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 kampanjo; 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 feedom izdelkov (id → naslov, cena, kategorija) in poročilo je popolno. Poizvedba, izdelek, naslov, konverzije in prihodek v eni tabeli.

Preverjeno, ne teoretizirano

To smo uvedli na živem računu češkega prodajalca elektronike z 22 vklopljenimi Shopping kampanjami. Sedem dni pozneje sem preveril GA4:

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 če sem odkrit, je šibkost celotne kategorije dokazovanje učinka. To poročilo to reši. Prepiši naslov tako, da se ujame s povpraševanjem, ki si ga pravkar dokazal, nato opazuj, kako se CTR in stopnja konverzije premikata po poizvedbi. Obogatitev feeda z AI preneha biti stvar zaupanja in postane merljiva zanka.

2 · Kdo še tekmuje za »tvojo« poizvedbo, in s katerim izdelkom

Ne moreš pa dodati negativnih ključnih besed na ravni posameznega izdelka. 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. Uporabljam končno točko serp/google/organic/live/advanced v storitvi DataForSEO. 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 ter 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 poceni 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 kampanjo 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 postavi segmentacijo Shoppinga na dokaze namesto na občutek.

4 · Zdravstveni pregled za PMax

PMax ti o iskanju ne pove skoraj ničesar. To poročilo je najbližje reviziji, kar je mogoče: za vsak izdelek pokaže, kaj PMax na iskalni površini dejansko kupuje zate.

Poglej, kako korak za korakom obdelam en pravi izvoz

Vse doslej je bilo o tem zakaj. Zdaj pride kako: kaj preneseš, kaj gledaš in katera prava številka pride nazaj.

Podatki v tem razdelku so z drugega računa, srednje velike češke spletne trgovine v nizkocenovnem segmentu. Ne gre za trgovino z elektroniko iz zgornjega okvira GA4. To spletno trgovino sem izbral, ker je njen katalog dovolj širok, da se vsak vzorec pokaže v polnem obsegu. Njeno surovo poročilo o iskalnih izrazih za Shopping sem prek Google Ads API-ja potegnil v lokalno tabelo SQLite in v njej 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 spodnje številke dovolj jasno pokažejo, za kaj se denar dejansko porablja.

Vir za vsako številko v tem razdelku: poročilo o iskalnih izrazih 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 izrazih za Shopping prek Google Ads API-ja (search_term_view) v katero koli orodje, ki podpira GROUP BY, na primer 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. Ti dve številki imata eno samo nalogo: pokazati, da ročno pregledovanje vsake vrstice ne pride v poštev. Edina pot naprej je, da podatke agregiraš po dimenziji, ki plačuje račune.

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

Preštej vrstice z nič kliki, nato jih izfiltriraj. Poročilo o iskalnih izrazih 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 skrči 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 spremeni tvoj pogled na račun

Kliknjene vrstice razvrsti v dve skupini: tiste z vsaj eno konverzijo in tiste brez konverzij. Nato seštej stroške v vsaki skupini. Prav ta razdelitev spremeni »račun je v redu, ROAS je 6,8« v »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 največja težava tega računa. In videl si jo le zato, ker si vsako poizvedbo zložil na skupino izdelkov, pod katero je bila prikazana.

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 izmeri, kolikšen delež skupnih stroškov držijo. To določi tvojo taktiko. Če peščica izrazov kuri proračun, jih zaustaviš in to je to. Če je zapravljanje tanko razpršeno, je zaustavljanje izrazov nesmiselno in potrebuješ strukturne popravke:

Zapravljanje je tanko razpršeno. Zgornji 1 % dragih vrstic predstavlja komaj desetino stroškov, zato zaustavitev 20 slabih izrazov ne spremeni ničesar. Namesto da loviš posamezne poizvedbe, popravi strukturo: odloči se, kateri izdelek sodi v katero kampanjo in s katerim ciljem. 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 vsak iskalni izraz preštej, pod koliko različnimi skupinami izdelkov je bil prikazan. 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 klik.

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. Poizvedba »lego technic« je bila prikazana pod 300 različnimi skupinami oglasov in izdelkov.

Skoraj polovica poizvedb je razmazana čez več skupin izdelkov, najhujše pa dosežejo tisoče. Od tod izvira zavora ničelne konverzije iz koraka 3. In je 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, pod katero je bila prikazana. Agregatne številke pokažejo obseg težave. Te tri vrstice pa pokaži svojemu šefu:

Poizvedba »ovratnica za dresuro psov« je bila prikazana pod skupino Torbice. Poizvedba »naprava proti lajanju« je bila prikazana pod Izdelki za dojenčke. Skupina izdelkov nima nobene zveze s poizvedbo. Google je poizvedbo ujemal s širokimi signali 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×. Celotno delo je v tem, da najdeš tistih 0,25 % vrstic, zaščitiš njihov proračun in vse drugo prestrukturiraš tako, da ne tekmuje več za isti denar. In nič od tega ne deluje, dokler vsaka vrstica ne navede izdelka iz kliknjenega oglasa. Podatek o izdelku prihaja iz enega samega vira: parametra utm_content={product_id}, ki si ga nastavil na začetku.

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.