Shopping-søgetermsrapporten Google ikke giver dig

En kunde stillede mig engang et spørgsmål, der burde have et et-kliks-svar. Nogen søgte på “ledningsfri støvsuger under 200”, klikkede på Shopping-annoncen, og kontoen betalte for det. Hvilket af de 5.000 produkter i feedet landede det klik på? Jeg åbnede søgetermsrapporten, derefter produktrapporten, og der var ingen måde at forbinde dem på. Det er der stadig ikke. Google viser dig forespørgslen, og den viser dig produktet, men aldrig sammen.

For år tilbage gav det gamle AdWords API dig præcis denne parring. Så forsvandt den i stilhed, og ingen indstilling, ingen rapport, intet API-felt bringer den tilbage. For en webshop er det hul ikke kosmetisk. Query til produkt er der, den reelle optimering bor. Om dine titler matcher den ægte efterspørgsel. Hvilke produkter der tiltrækker skraldetrafik. Hvorfor et produkt får klik men aldrig konverterer.

Tolv år med at skrive mod Google Ads API har lært mig, at når Google nedlægger en rapport, kommer den ikke tilbage. Så jeg genopbyggede den selv, og genopbygningen er næsten pinligt enkel. Én URL-parameter. Inden for en uge giver GA4 dig hvert betalt klik parret som query × produkt, med sessioner, konverteringer og omsætning vedhæftet. Opsætningen tager minutter; resten af artiklen handler om, hvad du stiller op med det, der kommer tilbage.

Løsningen: én parameter, to GA4-dimensioner

Auto-tagging og det manuelle UTM modarbejder ikke hinanden. Gclid håndterer fortsat kilde, medie og kampagne; dit UTM bærer kun produkt-id’et.

Vid, hvad du får (og hvad du ikke får)

At trække rapporten ud af GA4

Åbn Udforsk i GA4-interfacet og byg en friform-tabel. Dimensionerne er Manuelt annonceindhold for session og Google Ads-søgeforespørgsel for session. Metrikkerne er sessioner, nøglehændelser (tidligere konverteringer) og købsomsætning. Filtrér på sessionskilde/-medie lig med google / cpc.

Til alt seriøst vil du have Data API’et, for denne rapport hører hjemme i et dashboard eller en BigQuery-samkøring, ikke i en browserfane:

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

Samkør sessionManualAdContent med dit produktfeed (id til titel, pris, kategori), og rapporten er komplet. Query, produkt, titel og økonomi i én tabel.

Verificeret, ikke teoretiseret

Vi rullede det ud på en live konto, en tjekkisk elektronikforhandler med 22 aktiverede Shopping-kampagner, og jeg tjekkede GA4 syv dage senere:

Nu den sjove del: hvad parrene fortæller dig

1 · Titel-hullet

Sæt forespørgslerne ved siden af den titel og beskrivelse, de udløste. Misforholdet springer i øjnene:

Feed-roadmappet skriver sig selv. Jeg har brugt de sidste to år på at bygge et AI-værktøj til feed-berigelse, og hele kategoriens ærlige svaghed er at bevise effekt. Denne rapport løser det. Omskriv titlen omkring den efterspørgsel, du lige har bevist, og se så CTR og konverteringsrate flytte sig per forespørgsel. AI-feed-berigelse holder op med at være et trosspring og bliver en målbar løkke.

2 · Hvem ellers er på “din” forespørgsel, og med hvilket produkt

Én ting kan du ikke gøre. Tilføje negative søgeord per produkt. Google giver dig ikke den løftestang i Shopping eller PMax. Så når et query × produkt-par underpræsterer, fører spørgsmålet om, hvordan du udelukker det, ingen steder hen. Det produktive spørgsmål er hvorfor det underpræsterer.

Tag forespørgslen og scrap den live resultatside for den. Jeg bruger DataForSEO, endpoint serp/google/organic/live/advanced. Én POST med forespørgselsteksten og location_code for dit marked returnerer hele resultatsiden som struktureret JSON, betalte annoncer, shopping-blokke med forhandlernavne og priser, organisk nedenunder. DataForSEO afregner per SERP, og én SERP dækker op til 10 resultater. Med den aktuelle basispris på cirka 0,002 $ per SERP koster det omkring 0,40 $ at tjekke 200 forespørgsler med standarddybde, før betalte avancerede parametre.

Et typisk fund. Din mellemklasse-sovepose samler klik på en generisk forespørgsel, og samme forespørgsel viser tre budgetmærker i samme kategori til det halve af din pris. Produktet fejler ikke noget. Prisen taber præcis den auktion.

Nu har du reelle muligheder. Sæt prisen om. Skub differentieringen op i titlen (“dunfyld, −15 °C komfort”). Flyt produktet over i en kampagne med budgivning, der matcher dets margenvirkelighed. Eller acceptér forespørgslen som upper funnel og bedøm den på assisterede metrikker i stedet for last click.

3 · Struktur- og budgivningsbeslutninger

Produkter, der tiltrækker forespørgsler med høj købsintention, fortjener deres egne asset groups og budgetter. Produkter, der kun samler generisk trafik, hører hjemme i catch-all-grupper med konservative mål. Denne rapport giver shopping-segmentering et evidensgrundlag, og den erstatter mavefornemmelsen.

4 · Et sundhedstjek for PMax

PMax fortæller dig næsten intet om search. Denne rapport er det tætteste, du kommer på et audit af, hvad PMax faktisk køber for dig på search-fladen, per produkt.

Se mig gå én rigtig eksport igennem, trin for trin

Alt ovenfor er hvorfor. Her er, hvordan det faktisk ser ud, hvert trin, hvad du downloader, hvad du stirrer på, og det rigtige tal, der kommer tilbage.

Dataene er en anden konto, en mellemstor tjekkisk webshop i discountsegmentet. Det er ikke elektronikforhandleren fra GA4-boksen ovenfor; jeg bruger den, fordi dens katalog er bredt nok til, at hvert mønster dukker op i fuld størrelse. Jeg trak dens rå Shopping-søgetermsrapport gennem Google Ads API ind i en lokal SQLite-tabel og kørte aggregeringerne nedenfor. Ét forbehold først. Den rå rapport giver dig annoncegruppen eller produktgruppen, forespørgslen blev serveret under, ikke det enkelte produkt. Det er præcis det hul, UTM-tricket lukker. Men selv på produktgruppe-niveau er mellemresultaterne høje nok til at gøre pointen.

Kilde for hvert tal i dette afsnit: Google Ads Shopping-søgetermsrapport, én mellemstor tjekkisk webshop-konto, ~22,6 mio. linjer, data trukket april 2026. Beløb omregnet fra CZK til kurs ~25 CZK/EUR.

Trin 1 · Træk rå-rapporten og mål bunken

Eksportér Shopping-søgetermsrapporten via Google Ads API (search_term_view) ind i hvad som helst, du kan køre GROUP BY på, SQLite eller BigQuery. Før du samkører eller filtrerer en eneste ting, kør et rent COUNT(*) og et par SUMs. Du skal mærke, hvor stor og hvor støjende den rå bunke er, for den ene kendsgerning nulstiller enhver forventning, der følger:

22,6 millioner linjer, 5,4 millioner unikke forespørgsler. Det læser intet menneske. Tallets eneste opgave er at fortælle dig det næste træk, nemlig at kollapse bunken langs den dimension, der betaler regningerne, og at advare dig om, at manuel linje-for-linje-triage er håbløs.

Trin 2 · Smid 96 % af det væk, før du analyserer noget

Tæl linjerne med nul klik, og filtrér dem fra. Shopping-søgetermsrapporten logger hver forespørgsel, din annonce blev vist på, og på de fleste af de forespørgsler klikkede aldrig nogen. Rene eksponeringslinjer kan hverken koste dig noget eller konvertere. De er støj, der får tabellen til at se skræmmende ud.

WHERE clicks > 0 kollapser tabellen til 738.444 linjer, en størrelse du faktisk kan arbejde med.

96,7 % af det skræmmende tal var aldrig andet end støj. Filtrér til klikkede linjer, før du analyserer noget, så kører hver aggregering nedenfor på den del, der rent faktisk bruger penge.

Trin 3 · Stil det ene spørgsmål, der gentegner kontoen

Opdel forbruget på de klikkede linjer i “konverterede mindst én gang” mod “konverterede aldrig”, og læg omkostningen sammen for hver. Det er tallet, der laver “kontoen er fin, ROAS er 6,8” om til “det meste af budgettet laver ingenting”. Beregn det før enhver optimeringsidé:

85 % af budgettet løb gennem query × produktgruppe-kombinationer, der ikke konverterede en eneste gang.

Det er ikke en afrundingsfejl, du optimerer senere. Det er hovedbegivenheden. Og du kunne kun se det, fordi du kollapsede forespørgslen ned til det, den blev solgt mod.

Trin 4 · Tjek, om spildet er nogle få skurke eller hele flokken

Sortér de klikkede linjer efter omkostning, tag top 1 % og top 10 %, og se, hvor meget af det samlede forbrug de holder. Det afgør din taktik. Hvis en håndfuld termer brænder budgettet af, sætter du dem på pause, og du er færdig. Hvis spildet er spredt tyndt, er det nytteløst at pause termer, og du har brug for strukturelle løsninger:

Bremsen er long tail. Top 1 % af de dyre linjer holder knap en tiendedel af forbruget, så at sætte 20 dårlige termer på pause ændrer ingenting. Ret strukturen, hvilke produkter der sidder i hvilken kampagne ved hvilket mål, i stedet for at jagte enkelte forespørgsler. Og husk, at Google alligevel ikke engang lader dig tilføje et negativt søgeord per produkt.

Trin 5 · Find ud af hvorfor long tail lækker: én forespørgsel, mange produkter

Tæl for hver søgeterm, hvor mange forskellige produktgrupper den blev serveret under. Det forklarer spildet mekanisk. Shopping matcher en forespørgsel mod hele dit feeds signaler, ikke mod ét produkts relevans. En enkelt forespørgsel lækker ud i urelaterede hjørner af dit katalog, og du betaler for hver forbier.

Et konkret tilfælde fra kontoen. Forespørgslen “anti-gø-enhed” blev ved med at brænde budget af, så jeg kørte COUNT(DISTINCT ad_group) på den. Den var blevet serveret under 139 forskellige annonce- og produktgrupper, for 39 € og cirka nul konverteringer. “lego technic” rørte ved 300.

Næsten halvdelen af forespørgslerne er smurt ud over flere produktgrupper, og de værste syndere når tusinder. Det er motoren bag nul-konverterings-bremsen fra trin 3, og præcis det, du endelig kan se, så snart hvert klik bærer sit produkt-id.

Trin 6 · Tag de værste fejlpar i øjesyn, for de er absurde

Træk de dyreste linjer, der aldrig konverterede, og læs forespørgslen ved siden af den produktgruppe, den blev solgt mod. Aggregat-tallene overbeviser dit regneark. Disse tre rækker overbeviser din chef:

En hundetræningshalsbånd-forespørgsel betalt under gruppen Håndtasker. En anti-gø-enhed solgt mod Babyprodukter. Produktgruppen har intet med forespørgslen at gøre. Google matchede på brede feed-signaler, indkasserede kliket og opkrævede kontoen. Med query × produkt ser du det med ét blik; med Googles standardrapport gør du det aldrig. (Kategorier oversat og anonymiseret.)

Trin 7 · Nu udbyttet: de 0,25 %, der betaler for hele kontoen

Vend trin 3 om. Isolér kun de linjer, der faktisk konverterede, og læg deres omkostning og omsætning sammen. Det er grunden til, at hele øvelsen betyder noget. Når du først kan skille vinderne fra bremsen, beskytter du vinderne og sulter resten.

En kvart procent af linjerne kører ved 46,8× ROAS og bærer reelt kontoen. De øvrige 99,75 % trækker det blandede tal ned til 6,8×. At finde den skive, beskytte dens budget og strukturere alt andet væk fra den er hele arbejdet. Og intet af det er muligt, før hver linje bærer det produkt, den blev solgt mod. Det er, hvad én-parameter-UTM’et øverst i denne artikel køber dig.

FAQ

CTA: Hvilke af dine produkter gør sig fortjent til deres klik, og hvilke sender dig bare en regning? Tilføj parameteren i dag, så ved du det om en uge. Eller send mig din konto, så læser vi rapporten sammen.