Shopping-sökfrågerapporten Google inte ger dig

Lägg till en URL-parameter på dina Shopping- och Performance Max-kampanjer och, inom en vecka, räcker GA4 dig rapporten Google i tysthet avskaffade: varje betalt klick parat som sökfråga × produkt — med sessioner, konverteringar och intäkt knutna till sig. Just det paret är där pengarna gömmer sig — vilka produkter som drar skräptrafik, vilka titlar som missar verklig efterfrågan, vilka sökfrågor som bränner budget och aldrig säljer. Bygget är den ena parametern; resten av den här artikeln är vad du gör med det som kommer tillbaka.

Om du kör Shopping- eller Performance Max-kampanjer känner du sökfrågerapporten. Vad du kanske inte lagt märke till — eftersom Google aldrig påpekar det — är vad som saknas i den: produkten.

Du ser att någon sökte på “sladdlös dammsugare under 2000”. Du ser klick och kostnad. Du ser inte vilken av dina 5 000 produkter den sökfrågan utlöste, landade på eller sålde.

För flera år sedan gav AdWords-API:et dig det här paret. Idag gör det inte det. Och för ett e-handelskonto är det inte ett kosmetiskt gap — sökfråga-till-produkt är där den verkliga optimeringen sitter: om dina titlar matchar verklig efterfrågan, vilka produkter som drar skräptrafik, varför en produkt får klick men aldrig konverterar.

Innan du frågar: nej, det finns ingen inställning för det här. Ingen rapport, inget API-fält, inget skript som hämtar tillbaka det från Googles sida. Du måste bygga om det själv — och ombygget är nästan pinsamt enkelt.

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

I gränssnittet: Explore → free form. Dimensioner: Session manual ad content + Session Google Ads query. Mått: sessioner, konverteringar, köpintäkt. Filter: session source/medium = google / cpc.

Via Data API:t — för något seriöst matar det här en dashboard eller en BigQuery-join:

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

Joina sessionManualAdContent mot din product feed (id → titel, pris, kategori) och rapporten är komplett: sökfråga × produkt × titel × ekonomi.

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 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. Och det är här AI-feed-berikning slutar vara ett trossprång och blir en mätbar loop: skriv om titeln runt efterfrågan du just bevisade, och titta sedan på hur CTR och konverteringsfrekvens per sökfråga rör sig.

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

En sak du inte kan göra: 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 är frågan inte “hur exkluderar jag det” — det är “varför underpresterar det”.

Ta sökfrågan och skrapa resultatsidan live för den. Konkret: DataForSEO, endpoint serp/google/organic/live/advanced — en POST med sökfrågetexten och location_code för din marknad, och du får tillbaka hela resultatsidan som strukturerad JSON: betalda annonser, shopping-block med handlarnamn och priser, organiskt under. Vid ~0,0035 $ per fråga kostar att kolla 200 sökfrågor ungefär 0,70 $.

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. Din produkt är inte dålig; den är utklassad på pris i 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 in i 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 högintents-sökfrågor förtjänar sina egna tillgångsgrupper och budgetar. Produkter som bara samlar generisk trafik hör hemma i uppsamlingsgrupper med konservativa mål. Den här rapporten är bevisunderlaget för shopping-segmentering — inte magkänsla.

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 annan medelstor tjeckisk e-butik (inte elektronikåterförsäljaren från GA4-rutan ovan — jag använder den för att dess katalog ä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 här råa rapporten ger dig annonsgruppen / 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 e-butikskonto, ~22,6M rader, data dragen april 2026.

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

Vad du gör: exportera Shopping-sökfrågerapporten via Google Ads API (search_term_view) in i en lokal tabell — SQLite eller BigQuery, vad du än kan köra GROUP BY på. Varför det här först: innan du joinar något behöver du känna hur stor och hur brusig den råa högen är. Det enda faktumet återställer varje förväntning som följer.

Kör ett enkelt COUNT(*) och ett par SUM:ar och det här landar:

Vad du har: 22,6 miljoner rader, 5,4 miljoner unika sökfrågor. Ingen människa läser det. Siffrans enda jobb är att berätta nästa drag — kollapsa den här högen efter dimensionen som betalar räkningarna — och att varna dig att all manuell triage rad-för-rad är hopplös.

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

Vad du gör: räkna raderna med noll klick, filtrera sedan bort dem. Varför: Shopping-sökfrågerapporten loggar varje sökfråga din annons visades för, varav de flesta ingen klickade på. Raderna med bara visningar kan inte kosta dig och kan inte konvertera — de är brus som får tabellen att se skrämmande ut.

Situation: 22,6M rader, du vet inte var du ska börja. Handling: WHERE clicks > 0. Resultat: tabellen kollapsar till 738 444 rader — en hanterbar storlek.

Vad du har: 96,7 % av den skrämmande siffran var aldrig något annat än brus. Du jobbar nu en tabell på 738K rader, inte en på 22,6M — och varje aggregering nedan kör på den del som faktiskt spenderar pengar.

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

Vad du gör: på de klickade raderna, dela utgiften i “konverterade minst en gång” vs “konverterade aldrig”, och summera kostnaden för var och en. Varför: det här är siffran som förvandlar “kontot är okej, ROAS är 6,8” till “större delen av budgeten gör inget”. Det är det viktigaste mellanresultatet — beräkna det före varje optimeringsidé.

Vad du har: 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

Vad du gör: sortera de klickade raderna efter kostnad, ta topp 1 % och topp 10 %, och se hur mycket av total utgift de håller. Varför: 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 att pausa termer meningslöst — du behöver strukturella fixar.

Vad du har: släpet är långsvansat, inte några få bovar — topp 1 % av kostsamma rader håller knappt en tiondel av utgiften. Så att pausa 20 dåliga termer ändrar inget. Det här är det data-uppbackade skälet att fixa struktur (vilka produkter sitter i vilken kampanj på vilket mål) i stället för att jaga enskilda sökfrågor — och en påminnelse om 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

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

Situation: “antiskall-apparat” fortsätter bränna budget. Handling: COUNT(DISTINCT ad_group) för den termen. Resultat: den serverades under 139 olika annons- / produktgrupper för 976 CZK och ~0 konverteringar. “lego technic” rörde 300.

Vad du har: nästan hälften av dina sökfrågor ä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 — de är absurda

Vad du gör: dra de kostsammaste raderna som aldrig konverterade och läs sökfrågan bredvid produktgruppen den såldes mot. Varför: de aggregerade siffrorna övertygar ditt kalkylark; de här tre raderna övertygar din chef. De är det mänskligt läsbara ansiktet av steg 5.

En hundträningshalsband-sökfråga betalad för under din Handväskor-grupp. En antiskall-apparat såld mot Babyprodukter. Produktgruppen har inget med sökfrågan att göra — Google matchade på breda feed-signaler, samlade klicket, och debiterade dig. Med sökfråga × produkt ser du det här med en enda blick; med Googles standardrapport gör du det aldrig. (Illustrativt exempel — kategorier översatta och anonymiserade.)

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

Vad du gör: invertera steg 3 — isolera bara raderna som faktiskt konverterade och summera deras kostnad och intäkt. Varför: det här är skälet hela övningen spelar roll. När du väl kan skilja vinnarna från släpet skyddar du vinnarna och svälter resten.

Vad du har: 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 allt annat bort 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.

{lpurl}?utm_content={product_id}

FAQ