Report vyhledávacích dotazů Shopping, který vám Google nedá

Přidáte jeden URL parametr ke svým kampaním Shopping a Performance Max a do týdne vám GA4 vydá report, který Google potichu zrušil: každý placený proklik spárovaný jako dotaz × produkt — s relacemi, konverzemi a tržbami u toho. Právě v tomhle páru se schovávají peníze — které produkty tahají odpadní provoz, které titulky míjejí reálnou poptávku, které dotazy pálí rozpočet a nikdy neprodají. Celá stavba je ten jeden parametr; zbytek článku je o tom, co s tím, co se vrátí, uděláte.

Pokud provozujete kampaně Shopping nebo Performance Max, znáte report vyhledávacích dotazů. Čeho jste si možná nevšimli — protože vás na to Google nikdy neupozorní — je to, co v něm chybí: produkt.

Vidíte, že někdo hledal „aku vysavač do 200”. Vidíte prokliky a náklady. Nevidíte, který z vašich 5 000 produktů ten dotaz vyvolal, kam uživatel dorazil ani co se prodalo.

Před lety vám tohle párování AdWords API dalo. Dnes už ne. A pro e-commerce účet to není kosmetická mezera — právě v páru dotaz–produkt žije skutečná optimalizace: jestli vaše názvy odpovídají reálné poptávce, které produkty přitahují odpadní provoz, proč produkt dostává prokliky, ale nikdy nekonvertuje.

Než se zeptáte: ne, žádné nastavení pro tohle neexistuje. Žádný report, žádné API pole, žádný skript, který by to vrátil ze strany Googlu. Musíte si to poskládat sami — a to skládání je až trapně jednoduché.

Řešení: jeden parametr, dvě GA4 dimenze

Auto-tagging a manuální UTM si nelezou do zelí: gclid se dál stará o zdroj, médium a kampaň; vaše UTM nese jen ID produktu.

Vězte, co dostáváte (a co ne)

Jak report z GA4 vytáhnout

V UI: Prozkoumat → volná forma. Dimenze: Manuální obsah inzerce relace + Vyhledávací dotaz Google Ads relace. Metriky: relace, konverze, tržby z nákupu. Filtr: zdroj/médium relace = google / cpc.

Přes Data API — pro cokoli vážnějšího; tohle krmí dashboard nebo join 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"),  # ID produktu
        Dimension(name="sessionGoogleAdsQuery"),    # vyhledávací dotaz
    ],
    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"),
    )),
)

Spojte sessionManualAdContent se svým produktovým feedem (id → název, cena, kategorie) a report je kompletní: dotaz × produkt × název × ekonomika.

Ověřeno, ne vyteoretizováno

Nasadili jsme to na živém účtu — český prodejce elektroniky s 22 zapnutými Shopping kampaněmi — a o sedm dní později jsme zkontrolovali GA4:

A teď ta zábava: co vám páry prozradí

1 · Mezera v názvu

Postavte dotazy vedle názvu a popisu, který vyvolaly. Nesoulad bije do očí:

Roadmapa feedu se napíše sama. A právě tady přestává být AI obohacování feedu skokem do tmy a stává se z něj měřitelná smyčka: přepište název kolem poptávky, kterou jste právě prokázali, a sledujte, jak se hýbe CTR a konverzní poměr na dotaz.

2 · Kdo další je na „vašem” dotazu — a s jakým produktem

Jedna věc, kterou nemůžete: přidávat vylučující klíčová slova na úrovni produktu. Google vám v Shoppingu ani PMaxu takovou páku nedá. Takže když pár dotaz × produkt podává slabý výkon, otázka nezní „jak ho vyloučím” — ale „proč podává slabý výkon”.

Vezměte ten dotaz a oscrapujte si k němu živou stránku s výsledky. Konkrétně: DataForSEO, endpoint serp/google/organic/live/advanced — jeden POST s textem dotazu a location_code vašeho trhu a dostanete zpět celou výsledkovou stránku jako strukturovaný JSON: placené reklamy, Shopping bloky se jmény prodejců a cenami, organika pod nimi. Při ~$0.0035 za dotaz vyjde kontrola 200 dotazů zhruba na $0.70.

Typický nález: váš středně drahý spacák sbírá prokliky na generický dotaz — a tentýž dotaz ukazuje tři levné značky ve stejné kategorii za polovinu vaší ceny. Váš produkt není špatný; je přestřelen na ceně v té konkrétní aukci.

Teď máte reálné možnosti: přecenit; protlačit do názvu odlišovač („péřová výplň, komfort −15 °C”); přesunout produkt do kampaně s biddingem, který sedí jeho marži; nebo dotaz přijmout jako horní část trychtýře a posuzovat ho podle asistovaných metrik místo last clicku.

3 · Rozhodnutí o struktuře a biddingu

Produkty přitahující dotazy s vysokým záměrem si zaslouží vlastní asset groups a rozpočty. Produkty sbírající jen generický provoz patří do sběrných skupin s konzervativními cíli. Tenhle report je důkazní základna pro segmentaci Shoppingu — ne pocit od břicha.

4 · Zdravotní prohlídka PMaxu

PMax vám o vyhledávání řekne skoro nic. Tenhle report je nejblíž auditu toho, co pro vás PMax na vyhledávací ploše skutečně nakupuje — po produktech.

Projdu s vámi jeden reálný export, krok po kroku

Všechno výše je proč. Tady je jak to doopravdy vypadá — každý krok, co stáhnete, na co koukáte a jaké reálné číslo se vrátí.

Data jsou z druhého účtu: jiný středně velký český e-shop (ne ten elektro prodejce z GA4 boxu výše — beru ho proto, že jeho katalog je dost široký, aby se každý vzorec ukázal v plném měřítku). Jeho surový report vyhledávacích dotazů ze Shoppingu jsem stáhl přes Google Ads API do lokální SQLite tabulky a pustil na něj agregace níže. Jedna výhrada hned na začátku: tenhle surový report vám dá reklamní / produktovou skupinu, pod kterou se dotaz zobrazil — ne konkrétní produkt. Přesně tuhle mezeru zavírá ten UTM trik — ale i na úrovni produktové skupiny jsou mezivýstupy dost hlasité na to, aby to dávalo smysl.

Zdroj všech čísel v této sekci: report vyhledávacích dotazů Shopping (Google Ads), jeden středně velký český e-shop, ~22,6 mil. řádků, data stažena duben 2026.

Krok 1 · Stáhněte surový report a změřte tu hromadu

Co uděláte: vyexportujete report vyhledávacích dotazů Shopping přes Google Ads API (search_term_view) do lokální tabulky — SQLite, BigQuery, cokoli, na čem spustíte GROUP BY. Proč zrovna tohle první: než cokoli spojíte, musíte vycítit, jak velká a jak zašuměná ta surová hromada je. Tahle jedna věc resetuje všechna další očekávání.

Pustíte prostý COUNT(*) a pár SUMů a přistane tohle:

Co máte: 22,6 milionu řádků, 5,4 milionu unikátních dotazů. To nikdo nepřečte. Jediný úkol toho čísla je říct vám další krok — zhroutit tu hromadu podle dimenze, která platí účty — a varovat vás, že ruční triáž po řádcích je beznadějná.

Krok 2 · Zahoďte 96 % dřív, než cokoli analyzujete

Co uděláte: spočítáte řádky s nulou prokliků a vyfiltrujete je. Proč: report vyhledávacích dotazů Shopping loguje každý dotaz, na který se vaše reklama zobrazila, a na většinu z nich nikdo neklikl. Tyhle čistě zobrazovací řádky vás nemůžou nic stát ani nic prodat — je to šum, kvůli kterému tabulka vypadá děsivě.

Situace: 22,6 mil. řádků, nevíte, kde začít. Akce: WHERE clicks > 0. Výsledek: tabulka spadne na 738 444 řádků — zvládnutelná velikost.

Co máte: 96,7 % toho děsivého čísla nebylo nikdy nic jiného než šum. Teď pracujete s tabulkou o 738 tisících řádcích, ne o 22,6 milionu — a všechny agregace níže běží na té části, která reálně utrácí peníze.

Krok 3 · Položte tu jednu otázku, která účet překreslí

Co uděláte: na proklikaných řádcích rozdělíte náklad na „aspoň jednou konvertoval” vs. „nikdy nekonvertoval” a sečtete náklad u každé skupiny. Proč: tohle je číslo, které z „účet je v pohodě, ROAS 6,8” udělá „většina rozpočtu nedělá nic”. Je to klíčový mezivýstup — spočítejte ho dřív než jakýkoli nápad na optimalizaci.

Co máte: 85 % rozpočtu proteklo kombinacemi dotaz × produktová skupina, které ani jednou nekonvertovaly. To není zaokrouhlovací chyba, kterou doladíte později — to je hlavní událost. A viděli jste to jen proto, že jste dotaz zhroutili na to, proti čemu se prodával.

Krok 4 · Zjistěte, jestli je plýtvání pár padouchů, nebo celý dav

Co uděláte: seřadíte proklikané řádky podle nákladu, vezmete horní 1 % a 10 % a podíváte se, kolik celkového nákladu drží. Proč: tohle rozhodne o vaší taktice. Když rozpočet pálí hrstka dotazů, pozastavíte je a je hotovo. Když je plýtvání rozmázlé, pozastavování dotazů nemá smysl — potřebujete strukturální zásahy.

Co máte: brzda je dlouhý ocas, ne pár padouchů — horní 1 % nákladných řádků drží sotva desetinu nákladu. Takže pozastavení 20 špatných dotazů nezmění nic. Tohle je datovým podkladem podložený důvod opravovat strukturu (který produkt sedí v které kampani na jakém cíli) místo honění jednotlivých dotazů — a připomínka, že vylučující na úrovni produktu vám Google stejně přidat nedovolí.

Krok 5 · Zjistěte, proč dlouhý ocas protéká: jeden dotaz, mnoho produktů

Co uděláte: pro každý vyhledávací dotaz spočítáte, pod kolika různými produktovými skupinami se zobrazil. Proč: vysvětluje to plýtvání mechanicky. Shopping páruje dotaz proti signálům celého vašeho feedu, ne proti relevanci jednoho produktu — takže jeden dotaz protéká do nesouvisejících koutů katalogu a vy platíte za každý mimoběh.

Situace: „obojek proti štěkání” pořád pálí rozpočet. Akce: COUNT(DISTINCT ad_group) pro ten dotaz. Výsledek: zobrazil se pod 139 různými reklamními / produktovými skupinami za 976 Kč a ~0 konverzí. „lego technic” se dotkl 300.

Co máte: skoro polovina vašich dotazů je rozmázlá přes víc produktových skupin a ti nejhorší dosahují tisíců. To je motor brzdy nulových konverzí z Kroku 3 — a přesně to, co konečně uvidíte, jakmile každý proklik nese ID svého produktu.

Krok 6 · Prohlédněte si ty nejhorší nesoulady — jsou absurdní

Co uděláte: vytáhnete nejnákladnější řádky, které nikdy nekonvertovaly, a přečtete dotaz vedle produktové skupiny, proti které se prodával. Proč: agregátní čísla přesvědčí váš spreadsheet; tyhle tři řádky přesvědčí vašeho šéfa. Jsou lidsky čitelnou tváří Kroku 5.

Dotaz na výcvikový obojek pro psa zaplacený pod skupinou Kabelky. Obojek proti štěkání prodávaný proti Kojeneckým potřebám. Produktová skupina nemá s dotazem nic společného — Google spároval na hrubé signály feedu, sebral proklik a naúčtoval vám. S dotaz × produkt to vidíte na jeden pohled; ve standardním reportu Googlu nikdy. (Ilustrativní příklad — kategorie anonymizované.)

Krok 7 · A teď výplata: 0,25 %, které platí celý účet

Co uděláte: obrátíte Krok 3 — izolujete jen řádky, které konvertovaly, a sečtete jejich náklad a tržby. Proč: tohle je důvod, proč celé cvičení dává smysl. Jakmile oddělíte vítěze od brzdy, vítěze chráníte a zbytek vyhladovíte.

Co máte: čtvrt procenta řádků běží na 46,8× ROAS a fakticky nese celý účet; zbylých 99,75 % stahuje smíšené číslo dolů na 6,8×. Najít tu výseč, chránit její rozpočet a všechno ostatní od ní strukturně odsunout — to je celá ta práce. A nic z toho nejde, dokud každý řádek nenese produkt, proti kterému se prodával. Přesně to vám kupuje ten jednoparametrový UTM ze začátku článku.

{lpurl}?utm_content={product_id}

FAQ