Shopping-sökfrågerapporten Google inte ger dig

En kund ställde mig en gång en fråga som borde ha ett ett-klicks-svar. Någon sökte på “sladdlös dammsugare under 2000”, klickade på Shopping-annonsen, och kontot betalade för det. Vilken av de 5 000 produkterna i feeden landade det klicket på? Jag öppnade sökfrågerapporten, sedan produktrapporten, och det fanns inget sätt att koppla ihop dem. Det finns fortfarande inget. Google visar dig sökfrågan, och det visar dig produkten, men aldrig tillsammans.

För flera år sedan gav det gamla AdWords-API:et dig exakt det här paret. Sedan försvann det i tysthet, och ingen inställning, ingen rapport, inget API-fält tar det tillbaka. För en webbutik är det gapet inte kosmetiskt. Sökfråga till produkt är där den verkliga optimeringen bor. Om dina titlar matchar verklig efterfrågan. Vilka produkter som drar skräptrafik. Varför en produkt får klick men aldrig konverterar.

Tolv år av att skriva mot Google Ads API har lärt mig att när Google lägger ner en rapport kommer den inte tillbaka. Så jag byggde om den själv, och ombygget är nästan pinsamt enkelt. En URL-parameter. Inom en vecka räcker GA4 dig varje betalt klick parat som sökfråga × produkt, med sessioner, konverteringar och intäkt knutna till sig. Bygget tar minuter; resten av den här artikeln handlar om vad du gör med det som kommer tillbaka.

Fixen: en parameter, två GA4-dimensioner

Auto-tagging och den manuella UTM:en slåss inte mot varandra. Gclid fortsätter hantera källa, medium och kampanj; din UTM bär bara produkt-ID:t.

Vet vad du får (och vad du inte får)

Att dra ut rapporten ur GA4

Öppna Explore i GA4-gränssnittet och bygg en fri tabell. Dimensioner är Session manual ad content och Session Google Ads query. Mått är sessioner, nyckelhändelser (tidigare konverteringar) och köpintäkt. Filtrera på session source/medium lika med google / cpc.

För något seriöst vill du ha Data API:t, för den här rapporten hör hemma i en dashboard eller en BigQuery-join, inte i en webbläsarflik:

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

Joina sessionManualAdContent mot din product feed (id till titel, pris, kategori) och rapporten är komplett. Sökfråga, produkt, titel och ekonomi i en och samma tabell.

Verifierat, inte teoretiserat

Vi rullade ut det här på ett live-konto, en tjeckisk elektronikåterförsäljare med 22 aktiverade Shopping-kampanjer, och jag kollade GA4 sju dagar senare:

Nu den roliga delen: vad paren berättar för dig

1 · Titel-gapet

Sätt sökfrågorna bredvid titeln och beskrivningen de utlöste. Missmatchningen hoppar ut:

Feed-roadmappen skriver sig själv. Jag har ägnat de senaste två åren åt att bygga ett AI-verktyg för feed-berikning, och den ärliga svagheten i hela kategorin är att bevisa effekt. Den här rapporten fixar det. Skriv om titeln runt efterfrågan du just bevisat, och titta sedan på hur CTR och konverteringsfrekvens rör sig per sökfråga. AI-feed-berikning slutar vara ett trossprång och blir en mätbar loop.

2 · Vem mer som är på “din” sökfråga, och med vilken produkt

En sak du inte kan göra är att lägga till negativa sökord per produkt. Google ger dig ingen sådan spak i Shopping eller PMax. Så när ett sökfråga × produkt-par underpresterar leder frågan hur du exkluderar det ingenvart. Den produktiva frågan är varför det underpresterar.

Ta sökfrågan och skrapa den skarpa resultatsidan för den. Jag använder DataForSEO, endpoint serp/google/organic/live/advanced. En POST med sökfrågetexten och location_code för din marknad returnerar hela resultatsidan som strukturerad JSON, betalda annonser, shopping-block med handlarnamn och priser, organiskt under. DataForSEO fakturerar per SERP, och en SERP täcker upp till 10 resultat. Med det aktuella baspriset på ungefär 0,002 $ per SERP kostar det runt 0,40 $ att kolla 200 sökfrågor med standarddjup, innan betalda avancerade parametrar.

Ett typiskt fynd. Din mellanklass-sovsäck samlar klick på en generisk sökfråga, och samma sökfråga visar tre lågprismärken i samma kategori till halva ditt pris. Produkten är helt okej. Priset förlorar just den auktionen.

Nu har du verkliga alternativ. Prissätt om. Tryck in det som särskiljer produkten i titeln (“dunfyllning, −15 °C komfort”). Flytta produkten till en kampanj med budgivning som matchar dess marginalverklighet. Eller acceptera sökfrågan som toppen av tratten och bedöm den på assisterade mått i stället för sista klick.

3 · Struktur- och budgivningsbeslut

Produkter som drar sökfrågor med hög köpintention förtjänar egna tillgångsgrupper och budgetar. Produkter som bara samlar generisk trafik hör hemma i uppsamlingsgrupper med konservativa mål. Den här rapporten ger shopping-segmenteringen ett bevisunderlag, och den ersätter magkänslan.

4 · En hälsokontroll för PMax

PMax berättar nästan inget om search. Den här rapporten är det närmaste du kommer en granskning av vad PMax faktiskt köper åt dig på search-ytan, per produkt.

Följ med genom en verklig export, steg för steg

Allt ovan är varför. Här är hur det faktiskt ser ut, varje steg, vad du laddar ner, vad du stirrar på och den verkliga siffran som kommer tillbaka.

Datan är ett andra konto, en medelstor tjeckisk webbutik i lågprissegmentet. Det är inte elektronikåterförsäljaren från GA4-rutan ovan; jag använder det för att katalogen är bred nog att varje mönster syns i full skala. Jag drog dess råa Shopping-sökfrågerapport genom Google Ads API in i en lokal SQLite-tabell och körde aggregeringarna nedan. Ett förbehåll först. Den råa rapporten ger dig annonsgruppen eller produktgruppen sökfrågan serverades under, inte den enskilda produkten. Det är precis gapet UTM-tricket sluter. Men även på produktgruppsnivå är mellanresultaten tydliga nog för att göra poängen.

Källa för varje siffra i den här sektionen: Google Ads Shopping-sökfrågerapport, ett medelstort tjeckiskt webbutikskonto, ~22,6M rader, data dragen april 2026. Belopp omräknade från CZK med kursen ~25 CZK/EUR.

Steg 1 · Dra den råa rapporten och mät högen

Exportera Shopping-sökfrågerapporten via Google Ads API (search_term_view) in i vad som helst du kan köra GROUP BY på, SQLite eller BigQuery. Innan du joinar eller filtrerar en enda sak, kör ett rent COUNT(*) och ett par SUM:ar. Du behöver känna hur stor och hur brusig den råa högen är, för det enda faktumet återställer varje förväntning som följer:

22,6 miljoner rader, 5,4 miljoner unika sökfrågor. Ingen människa läser det. Siffrans enda jobb är att peka ut nästa drag, att kollapsa högen efter dimensionen som betalar räkningarna, och att varna dig för att manuell triage rad för rad är hopplös.

Steg 2 · Släng 96 % innan du analyserar något

Räkna raderna med noll klick och filtrera sedan bort dem. Shopping-sökfrågerapporten loggar varje sökfråga din annons visades för, och de flesta av de sökfrågorna klickade ingen någonsin på. Rader med bara visningar kan inte kosta dig något och kan inte konvertera. De är brus som får tabellen att se skrämmande ut.

WHERE clicks > 0 kollapsar tabellen till 738 444 rader, en storlek du faktiskt kan jobba med.

96,7 % av den skrämmande siffran var aldrig något annat än brus. Filtrera till klickade rader innan du analyserar något, så kör varje aggregering nedan på den del som faktiskt spenderar pengar.

Steg 3 · Ställ den enda frågan som omformulerar kontot

Dela utgiften på de klickade raderna i “konverterade minst en gång” mot “konverterade aldrig”, och summera kostnaden för varje. Det här är siffran som förvandlar “kontot är okej, ROAS är 6,8” till “större delen av budgeten gör ingenting”. Beräkna den före varje optimeringsidé:

85 % av budgeten flöt genom sökfråga × produktgrupp-kombinationer som aldrig en enda gång konverterade.

Det är inget avrundningsfel du optimerar senare. Det är huvudnumret. Och du kunde bara se det för att du kollapsade sökfrågan ner till vad den såldes mot.

Steg 4 · Kolla om slöseriet är några få skurkar eller hela hopen

Sortera de klickade raderna efter kostnad, ta topp 1 % och topp 10 %, och se hur mycket av den totala utgiften de håller. Det här avgör din taktik. Om en handfull termer bränner budgeten pausar du dem och du är klar. Om slöseriet är tunt utspritt är det meningslöst att pausa termer, då behöver du strukturella fixar:

Släpet är långsvansat. Topp 1 % av de kostsamma raderna håller knappt en tiondel av utgiften, så att pausa 20 dåliga termer ändrar ingenting. Fixa strukturen, vilka produkter som sitter i vilken kampanj på vilket mål, i stället för att jaga enskilda sökfrågor. Och kom ihåg att Google ändå inte ens låter dig lägga till en negativ per produkt.

Steg 5 · Ta reda på varför långsvansen läcker: en sökfråga, många produkter

Räkna för varje sökfråga hur många distinkta produktgrupper den serverades under. Det förklarar slöseriet mekaniskt. Shopping matchar en sökfråga mot hela din feeds signaler, inte mot en enda produkts relevans. En enda sökfråga läcker över orelaterade hörn av din katalog, och du betalar för varje miss.

Ett konkret fall från kontot. Sökfrågan “antiskall-apparat” fortsatte bränna budget, så jag körde COUNT(DISTINCT ad_group) på den. Den hade serverats under 139 olika annons- och produktgrupper, för 39 € och ungefär noll konverteringar. “lego technic” rörde 300.

Nästan hälften av sökfrågorna är utsmetade över flera produktgrupper, och de värsta bovarna når tusentals. Det är motorn bakom noll-konvertering-släpet från steg 3, och exakt det du äntligen kan se när varje klick bär sitt produkt-ID.

Steg 6 · Ögna de värsta missmatchningarna, för de är absurda

Dra de kostsammaste raderna som aldrig konverterade och läs sökfrågan bredvid produktgruppen den såldes mot. De aggregerade siffrorna övertygar ditt kalkylark. De här tre raderna övertygar din chef:

En hundträningshalsband-sökfråga betald under gruppen Handväskor. En antiskall-apparat såld mot Babyprodukter. Produktgruppen har inget med sökfrågan att göra. Google matchade på breda feed-signaler, tog klicket och debiterade kontot. Med sökfråga × produkt ser du det här med en enda blick; med Googles standardrapport gör du det aldrig. (Kategorier översatta och anonymiserade.)

Steg 7 · Nu utdelningen: de 0,25 % som betalar för hela kontot

Invertera steg 3. Isolera bara raderna som faktiskt konverterade och summera deras kostnad och intäkt. Det här är skälet till att hela övningen spelar roll. När du väl kan skilja vinnarna från släpet skyddar du vinnarna och svälter resten.

En kvarts procent av raderna kör på 46,8× ROAS och bär i praktiken kontot. De andra 99,75 % drar den blandade siffran ner till 6,8×. Att hitta den skivan, skydda dess budget och strukturera bort allt annat från den är hela jobbet. Och inget av det är möjligt förrän varje rad bär produkten den såldes mot. Det är vad UTM:en med en enda parameter högst upp i artikeln köper dig.

FAQ

CTA: Vilka av dina produkter förtjänar sina klick, och vilka bara fakturerar dig? Lägg till parametern idag, så vet du om en vecka. Eller skicka mig ditt konto så läser vi rapporten tillsammans.