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

Klient zadał mi kiedyś pytanie, które powinno mieć odpowiedź na jedno kliknięcie. Ktoś wpisał „odkurzacz bezprzewodowy do 200”, kliknął reklamę Shopping, a konto za to zapłaciło. Na którym z 5000 produktów w feedzie wylądowało to kliknięcie? Otworzyłem raport wyszukiwanych haseł, potem raport produktów, i nie dało się ich połączyć. Nadal się nie da. Google pokazuje ci zapytanie i pokazuje ci produkt, ale nigdy razem.

Lata temu dokładnie to parowanie dawało stare AdWords API. Potem po cichu zniknęło i żadne ustawienie, żaden raport, żadne pole API go nie przywróci. Dla sklepu internetowego 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 ściągają śmieciowy ruch. Dlaczego produkt dostaje kliknięcia, ale nigdy nie konwertuje.

Dwanaście lat pisania pod Google Ads API nauczyło mnie, że kiedy Google wycofuje raport, on już nie wraca. Więc odbudowałem go sam, a odbudowa jest niemal żenująco prosta. Jeden parametr URL. W ciągu tygodnia GA4 oddaje ci każde płatne kliknięcie sparowane jako zapytanie × produkt, z sesjami, konwersjami i przychodem w komplecie. Budowa zajmuje minuty; reszta tego artykułu jest o tym, co robisz z tym, co wraca.

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 GA4 otwórz Eksplorację i zbuduj tabelę w formacie dowolnym. Wymiary to Treść reklamy z ręcznego tagowania (sesja) i Zapytanie Google Ads (sesja). Dane to sesje, zdarzenia kluczowe (dawniej konwersje) i przychody z zakupów. Filtruj po źródle/medium sesji równym google / cpc.

Do czegokolwiek poważnego będziesz chcieć Data API, bo ten raport należy do dashboardu albo złączenia w BigQuery, nie do karty przeglądarki:

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"),
    )),
)

Połącz sessionManualAdContent ze swoim feedem produktowym (id do tytułu, ceny, kategorii) i raport jest kompletny. Zapytanie, produkt, tytuł i ekonomia w jednej tabeli.

Zweryfikowane, nie wymyślone

Wdrożyliśmy to na żywym koncie, czeskim sprzedawcy elektroniki z 22 włączonymi kampaniami Shopping, a ja sprawdziłem 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 samo:

Roadmapa feedu pisze się sama. Ostatnie dwa lata budowałem narzędzie AI do wzbogacania feedów i szczerą słabością całej tej kategorii jest udowadnianie wpływu. Ten raport to naprawia. Przepisz tytuł wokół popytu, który właśnie udowodniłeś, a potem patrz, jak CTR i współczynnik konwersji ruszają się per zapytanie. Wzbogacanie feedu przez AI przestaje być skokiem na wiarę i staje się mierzalną pętlą.

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

Wykluczających słów kluczowych per produkt dodać nie możesz. Google nie daje ci takiej dźwigni w Shopping ani w PMax. Więc kiedy para zapytanie × produkt nie dowozi, pytanie o to, jak ją wykluczyć, prowadzi donikąd. Produktywne pytanie to, dlaczego nie dowozi.

Weź zapytanie i zescrapuj dla niego żywą stronę wyników. Używam DataForSEO, endpoint serp/google/organic/live/advanced. Jeden POST z treścią zapytania i location_code twojego rynku zwraca całą stronę wyników jako ustrukturyzowany JSON, płatne reklamy, bloki shopping z nazwami sprzedawców i cenami, organiczne pod spodem. DataForSEO rozlicza się per SERP, a jeden SERP obejmuje do 10 wyników. Przy obecnej cenie bazowej około 0,002 $ za SERP sprawdzenie 200 zapytań o domyślnej głębokości kosztuje jakieś 0,40 $, zanim doliczysz płatne parametry zaawansowane.

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 z tej samej kategorii za połowę twojej ceny. Produkt jest w porządku. Cena przegrywa tę konkretną aukcję.

Teraz masz realne opcje. Zmień cenę. Wepchnij wyróżnik w tytuł („wypełnienie puchowe, komfort −15 °C”). Przenieś produkt do kampanii ze strategią stawek pasującą do realiów jego 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 stawkach

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 daje segmentacji Shopping bazę dowodową i zastępuje przeczucie.

4 · Badanie kondycji PMax

PMax nie mówi ci o wyszukiwaniu prawie nic. Ten raport to najbliższe audytowi tego, co PMax faktycznie kupuje dla ciebie na powierzchni wyszukiwania, per produkt.

Przejdę z tobą 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, średniej wielkości czeski sklep internetowy w segmencie tanich produktów. To nie jest 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. Surowy raport daje ci grupę reklam albo 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, żeby zrobić swoje.

Źródło każdej liczby w tej sekcji: raport wyszukiwanych haseł Shopping (Google Ads), jedno średniej wielkości czeskie konto sklepu internetowego, ~22,6 mln wierszy, dane wyciągnięte w kwietniu 2026. Kwoty przeliczone z CZK po kursie ~25 CZK/EUR.

Krok 1 · Wyciągnij surowy raport i zmierz stos

Wyeksportuj raport wyszukiwanych haseł Shopping przez Google Ads API (search_term_view) do czegokolwiek, na czym puścisz GROUP BY, do SQLite albo BigQuery. Zanim cokolwiek złączysz albo odfiltrujesz, puść zwykłe COUNT(*) i parę SUM-ów. Musisz poczuć, jak duży i jak zaszumiony jest surowy stos, bo ten jeden fakt resetuje każde oczekiwanie, które przyjdzie potem:

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

Krok 2 · Wyrzuć 96 % zanim cokolwiek przeanalizujesz

Policz wiersze z zerem kliknięć, potem je odfiltruj. Raport wyszukiwanych haseł Shopping loguje każde zapytanie, na które twoja reklama się pokazała, a w większość z nich nikt nigdy nie kliknął. Wiersze z samymi wyświetleniami nie mogą cię nic kosztować i nie mogą nic skonwertować. To szum, przez który tabela wygląda przerażająco.

WHERE clicks > 0 zwija tabelę do 738 444 wierszy, rozmiaru, na którym da się realnie pracować.

96,7 % przerażającej liczby nigdy nie było niczym innym niż szumem. Filtruj do klikniętych wierszy, zanim cokolwiek przeanalizujesz, a każda poniższa agregacja będzie działać na części, która faktycznie wydaje pieniądze.

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

Na klikniętych wierszach rozdziel wydatki na „skonwertowało co najmniej raz” i „nigdy nie skonwertowało” i zsumuj koszt każdej grupy. To jest liczba, która zamienia „konto jest okej, ROAS 6,8” w „większość budżetu nie robi nic”. Policz ją przed jakimkolwiek pomysłem na optymalizację:

85 % budżetu przepłynęło przez kombinacje zapytanie × grupa produktów, które ani razu nie skonwertowały.

To nie jest błąd zaokrąglenia, który zoptymalizujesz 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

Posortuj kliknięte wiersze po koszcie, weź górny 1 % i górne 10 % i zobacz, ile całkowitych wydatków trzymają. 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 daje i potrzebujesz poprawek strukturalnych:

Hamulec to długi ogon. Górny 1 % kosztownych wierszy trzyma ledwie jedną dziesiątą wydatków, więc pauzowanie 20 złych haseł nic nie zmienia. Naprawiaj strukturę, czyli który produkt siedzi w której kampanii z jakim celem, zamiast gonić pojedyncze zapytania. I pamiętaj, ż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

Dla każdego wyszukiwanego hasła policz, pod iloma różnymi grupami produktów zostało wyświetlone. To wyjaśnia marnotrawstwo mechanicznie. Shopping dopasowuje zapytanie do sygnałów całego twojego feedu, nie do trafności jednego produktu. Pojedyncze zapytanie przecieka do niepowiązanych zakątków katalogu, a ty płacisz za każde pudło.

Konkretny przypadek z konta. Zapytanie „urządzenie antyszczekowe” wciąż przepalało budżet, więc puściłem na nie COUNT(DISTINCT ad_group). Zostało wyświetlone pod 139 różnymi grupami reklam i produktów, za 39 € i mniej więcej zero konwersji. „lego technic” dotknęło 300.

Prawie połowa 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 widzisz, gdy każde kliknięcie niesie ID swojego produktu.

Krok 6 · Przyjrzyj się najgorszym niedopasowaniom, bo są absurdalne

Wyciągnij najkosztowniejsze wiersze, które nigdy nie skonwertowały, i przeczytaj zapytanie obok grupy produktów, przeciwko której zostało sprzedane. Liczby zagregowane przekonują twój arkusz. Te trzy wiersze przekonują twojego szefa:

Zapytanie o obrożę treningową dla psa opłacone pod grupą Torebki. Urządzenie antyszczekowe sprzedane przeciwko grupie Artykuły dla dzieci. Grupa produktów nie ma nic wspólnego z zapytaniem. Google dopasował po grubych sygnałach feedu, zebrał kliknięcie i obciążył konto. Z zapytaniem × produktem widzisz to jednym spojrzeniem; ze standardowym raportem Google nigdy. (Kategorie przetłumaczone i zanonimizowane.)

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

Odwróć krok 3. Wyizoluj tylko wiersze, które skonwertowały, i zsumuj ich koszt i przychód. 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ę.

Ćwierć procenta wierszy działa z ROAS 46,8× i faktycznie niesie całe konto. Pozostałe 99,75 % ciągnie mieszaną liczbę w dół do 6,8×. Znalezienie tego wycinka, ochrona jego budżetu i strukturalne odsunięcie od niego całej reszty to cała robota. A 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.

FAQ

CTA: Które z twoich produktów zarabiają na swoje kliknięcia, a które tylko wystawiają ci rachunek? Dodaj parametr dziś, a za tydzień będziesz wiedzieć. Albo podeślij mi swoje konto i przeczytamy ten raport razem.