Raport wyszukiwanych haseł w Shopping, którego Google ci nie da

Dodaj jeden parametr URL do swoich kampanii Shopping i Performance Max, a w ciągu tygodnia GA4 odda ci raport, który Google po cichu wycofał: każde płatne kliknięcie sparowane jako zapytanie × produkt — z sesjami, konwersjami i przychodem w komplecie. To właśnie w tej parze ukrywają się pieniądze — które produkty ściągają śmieciowy ruch, które tytuły mijają się z realnym popytem, które zapytania przepalają budżet i nigdy nie sprzedają. Cała budowa to ten jeden parametr; reszta tego artykułu jest o tym, co robisz z tym, co wraca.

Jeśli prowadzisz kampanie Shopping albo Performance Max, znasz raport wyszukiwanych haseł. Czego możesz nie zauważyć — bo Google nigdy o tym nie wspomina — to to, czego w nim brakuje: produktu.

Widzisz, że ktoś wpisał „odkurzacz bezprzewodowy do 200”. Widzisz kliknięcia i koszt. Nie widzisz, który z twoich 5000 produktów to zapytanie wywołało, na którym wylądowało albo który sprzedało.

Lata temu AdWords API dawało ci to parowanie. Dziś już nie. A dla konta e-commerce to nie jest kosmetyczna luka — zapytanie-do-produktu to miejsce, gdzie żyje prawdziwa optymalizacja: czy twoje tytuły pasują do realnego popytu, które produkty przyciągają śmieciowy ruch, dlaczego produkt dostaje kliknięcia, ale nigdy nie konwertuje.

Zanim zapytasz: nie, nie ma na to żadnego ustawienia. Żadnego raportu, żadnego pola API, żadnego skryptu, który by to przywrócił po stronie Google. Musisz odbudować to sam — a odbudowa jest niemal żenująco prosta.

Rozwiązanie: jeden parametr, dwa wymiary GA4

Auto-tagowanie i ręczny UTM nie walczą ze sobą: gclid nadal obsługuje źródło, medium i kampanię; twój UTM niesie tylko ID produktu.

Wiedz, co dostajesz (i czego nie)

Wyciąganie raportu z GA4

W interfejsie: Eksploracja → format dowolny. Wymiary: Treść reklamy z ręcznego tagowania (sesja) + Zapytanie Google Ads (sesja). Dane: sesje, konwersje, przychody z zakupów. Filtr: źródło/medium sesji = google / cpc.

Przez Data API — do czegokolwiek poważnego to zasila dashboard albo złączenie w 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"),
    )),
)

Połącz sessionManualAdContent ze swoim feedem produktowym (id → tytuł, cena, kategoria) i raport jest kompletny: zapytanie × produkt × tytuł × ekonomia.

Zweryfikowane, nie wymyślone

Wdrożyliśmy to na żywym koncie — czeskim sprzedawcy elektroniki z 22 włączonymi kampaniami Shopping — i sprawdziliśmy GA4 siedem dni później:

Teraz zabawna część: co mówią ci te pary

1 · Luka w tytule

Postaw zapytania obok tytułu i opisu, które wywołały. Niedopasowanie wyskakuje od razu:

Roadmapa feedu pisze się sama. I tu wzbogacanie feedu przez AI przestaje być działaniem na wiarę, a staje się mierzalną pętlą: przepisz tytuł wokół popytu, który właśnie udowodniłeś, a potem patrz, jak CTR i współczynnik konwersji na zapytanie się ruszają.

2 · Kto jeszcze jest na „twoim” zapytaniu — i z jakim produktem

Jednej rzeczy nie możesz zrobić: dodać wykluczających słów kluczowych per produkt. Google nie daje ci takiej dźwigni w Shopping ani PMax. Więc kiedy para zapytanie × produkt nie dowozi, pytanie nie brzmi „jak ją wykluczyć” — tylko „dlaczego nie dowozi”.

Weź zapytanie i pobierz dla niego żywą stronę wyników. Konkretnie: DataForSEO, endpoint serp/google/organic/live/advanced — jeden POST z treścią zapytania i location_code twojego rynku, a dostajesz z powrotem całą stronę wyników jako ustrukturyzowany JSON: płatne reklamy, bloki shopping z nazwami sprzedawców i cenami, organiczne pod spodem. Przy ~0,0035 $ za zapytanie sprawdzenie 200 zapytań kosztuje około 0,70 $.

Typowe znalezisko: twój śpiwór ze średniej półki zbiera kliknięcia na ogólnym zapytaniu — a to samo zapytanie pokazuje trzy budżetowe marki w tej samej kategorii za połowę twojej ceny. Twój produkt nie jest zły; jest przebity ceną w tej konkretnej aukcji.

Teraz masz realne opcje: zmień cenę; wepchnij wyróżnik w tytuł („wypełnienie puchowe, komfort −15 °C”); przenieś produkt do kampanii ze strategią ustalania stawek pasującą do realiów marży; albo zaakceptuj zapytanie jako górny lejek i oceniaj je po metrykach wspomaganych zamiast po ostatnim kliknięciu.

3 · Decyzje o strukturze i ustalaniu stawek

Produkty przyciągające zapytania o wysokiej intencji zasługują na własne grupy plików i budżety. Produkty zbierające tylko ogólny ruch należą do zbiorczych grup z konserwatywnymi celami. Ten raport to baza dowodowa dla segmentacji Shopping — nie przeczucie na czuja.

4 · Badanie kondycji PMax

PMax mówi ci niemal nic o wyszukiwaniu. Ten raport to najbliższe, co dostaniesz, do audytu tego, co PMax faktycznie kupuje dla ciebie na powierzchni wyszukiwania — per produkt.

Patrz, jak przechodzę przez jeden realny eksport, krok po kroku

Wszystko powyżej to dlaczego. Tu jest jak to naprawdę wygląda — każdy krok, co pobierasz, na co się gapisz i jaka realna liczba wraca.

Dane to drugie konto: inny średniej wielkości czeski e-sklep (nie sprzedawca elektroniki z ramki GA4 powyżej — biorę go, bo jego katalog jest na tyle szeroki, że każdy wzorzec pokazuje się w pełnej skali). Wyciągnąłem jego surowy raport wyszukiwanych haseł Shopping przez Google Ads API do lokalnej tabeli SQLite i puściłem na nim poniższe agregacje. Jedno zastrzeżenie na start: ten surowy raport daje ci grupę reklam / grupę produktów, pod którą zapytanie zostało wyświetlone, nie pojedynczy produkt. To dokładnie ta luka, którą zamyka sztuczka z UTM — ale nawet na poziomie grupy produktów wyniki pośrednie są na tyle głośne, by zrobić swoje.

Źródło każdej liczby w tej sekcji: raport wyszukiwanych haseł Shopping (Google Ads), jedno średniej wielkości czeskie konto e-sklepu, ~22,6 mln wierszy, dane wyciągnięte w kwietniu 2026.

Krok 1 · Wyciągnij surowy raport i zmierz stos

Co robisz: wyeksportuj raport wyszukiwanych haseł Shopping przez Google Ads API (search_term_view) do lokalnej tabeli — SQLite albo BigQuery, cokolwiek, na czym puścisz GROUP BY. Dlaczego najpierw to: zanim cokolwiek złączysz, musisz poczuć, jak duży i jak zaszumiony jest surowy stos. Ten jeden fakt resetuje każde oczekiwanie, które przyjdzie potem.

Puść zwykłe COUNT(*) i parę SUM-ów, a oto co ląduje:

Co masz: 22,6 miliona wierszy, 5,4 miliona unikalnych zapytań. Tego nikt nie czyta. Jedynym zadaniem tej liczby jest powiedzieć ci następny ruch — zwiń ten stos po wymiarze, który płaci rachunki — i ostrzec cię, że jakakolwiek ręczna selekcja wiersz po wierszu jest beznadziejna.

Krok 2 · Wyrzuć 96 % zanim cokolwiek przeanalizujesz

Co robisz: policz wiersze z zerową liczbą kliknięć, potem je odfiltruj. Dlaczego: raport wyszukiwanych haseł Shopping loguje każde zapytanie, na które twoja reklama się pokazała, a w większość z nich nikt nie kliknął. Te wiersze tylko z wyświetleniami nie mogą cię nic kosztować ani nic skonwertować — to szum, który sprawia, że tabela wygląda przerażająco.

Sytuacja: 22,6 mln wierszy, nie wiesz, od czego zacząć. Akcja: WHERE clicks > 0. Wynik: tabela zwija się do 738 444 wierszy — rozmiar do ogarnięcia.

Co masz: 96,7 % przerażającej liczby nigdy nie było niczym innym niż szumem. Pracujesz teraz na tabeli 738 tys. wierszy, nie 22,6 mln — a każda poniższa agregacja działa na tej części, która faktycznie wydaje pieniądze.

Krok 3 · Zadaj jedno pytanie, które przemalowuje konto

Co robisz: na klikniętych wierszach rozdziel wydatki na „skonwertowało co najmniej raz” vs „nigdy nie skonwertowało” i zsumuj koszt każdej grupy. Dlaczego: to jest liczba, która zamienia „konto jest okej, ROAS to 6,8” w „większość budżetu nie robi nic”. To kluczowy wynik pośredni — policz go przed jakimkolwiek pomysłem na optymalizację.

Co masz: 85 % budżetu przepłynęło przez kombinacje zapytanie × grupa-produktów, które ani razu nie skonwertowały. To nie błąd zaokrąglenia, który optymalizujesz później — to główne wydarzenie. I mogłeś to zobaczyć tylko dlatego, że zwinąłeś zapytanie do tego, przeciwko czemu zostało sprzedane.

Krok 4 · Sprawdź, czy marnotrawstwo to kilku łotrów, czy cały tłum

Co robisz: posortuj kliknięte wiersze po koszcie, weź górny 1 % i górne 10 % i zobacz, ile całkowitych wydatków trzymają. Dlaczego: to decyduje o twojej taktyce. Jeśli garść haseł przepala budżet, pauzujesz je i koniec. Jeśli marnotrawstwo jest rozsmarowane cienko, pauzowanie haseł nic nie da — potrzebujesz poprawek strukturalnych.

Co masz: hamulec to długi ogon, nie kilku łotrów — górny 1 % kosztownych wierszy trzyma ledwie jedną dziesiątą wydatków. Więc pauzowanie 20 złych haseł nic nie zmieni. To poparty danymi powód, by naprawiać strukturę (który produkt siedzi w której kampanii z jakim celem) zamiast gonić pojedyncze zapytania — i przypomnienie, że Google i tak nie pozwoli ci dodać wykluczenia per produkt.

Krok 5 · Dowiedz się, dlaczego długi ogon przecieka: jedno zapytanie, wiele produktów

Co robisz: dla każdego wyszukiwanego hasła policz, pod iloma różnymi grupami produktów zostało wyświetlone. Dlaczego: to wyjaśnia marnotrawstwo mechanicznie. Shopping dopasowuje zapytanie do sygnałów całego twojego feedu, nie do trafności jednego produktu — więc pojedyncze zapytanie przecieka do niepowiązanych zakątków twojego katalogu, a ty płacisz za każde pudło.

Sytuacja: „urządzenie antyszczekowe” wciąż przepala budżet. Akcja: COUNT(DISTINCT ad_group) dla tego hasła. Wynik: zostało wyświetlone pod 139 różnymi grupami reklam / produktów za 976 CZK i ~0 konwersji. „lego technic” dotknęło 300.

Co masz: prawie połowa twoich zapytań jest rozsmarowana po wielu grupach produktów, a najgorsze sięgają tysięcy. To silnik hamulca zerowej konwersji z Kroku 3 — i dokładnie ta rzecz, którą wreszcie możesz zobaczyć, gdy każde kliknięcie niesie ID swojego produktu.

Krok 6 · Przyjrzyj się najgorszym niedopasowaniom — są absurdalne

Co robisz: wyciągnij najkosztowniejsze wiersze, które nigdy nie skonwertowały, i przeczytaj zapytanie obok grupy produktów, przeciwko której zostało sprzedane. Dlaczego: liczby zagregowane przekonują twój arkusz; te trzy wiersze przekonują twojego szefa. To czytelna dla człowieka twarz Kroku 5.

Zapytanie o obrożę treningową dla psa opłacone pod grupą Torebki. Urządzenie antyszczekowe sprzedane przeciwko Artykuły dla dzieci. Grupa produktów nie ma nic wspólnego z zapytaniem — Google dopasował na grubych sygnałach feedu, zebrał kliknięcie i naliczył ci je. Z zapytaniem × produkt widzisz to jednym spojrzeniem; ze standardowym raportem Google nigdy nie zobaczysz. (Przykład poglądowy — kategorie przetłumaczone i zanonimizowane.)

Krok 7 · Teraz wypłata: te 0,25 %, które płaci za całe konto

Co robisz: odwróć Krok 3 — wyizoluj tylko wiersze, które skonwertowały, i zsumuj ich koszt i przychód. Dlaczego: to jest powód, dla którego całe ćwiczenie ma znaczenie. Gdy potrafisz oddzielić zwycięzców od hamulca, chronisz zwycięzców i głodzisz resztę.

Co masz: ćwierć procenta wierszy działa z ROAS 46,8× i faktycznie niesie konto; pozostałe 99,75 % ciągnie mieszaną liczbę w dół do 6,8×. Znalezienie tego wycinka, ochrona jego budżetu i ustrukturyzowanie całej reszty z dala od niego to cała robota — i nic z tego nie jest możliwe, dopóki każdy wiersz nie niesie produktu, przeciwko któremu został sprzedany. To właśnie kupuje ci jednoparametrowy UTM z początku tego artykułu.

{lpurl}?utm_content={product_id}

FAQ