Shopping-søgetermsrapporten Google ikke giver dig

Tilføj én URL-parameter til dine Shopping- og Performance Max-kampagner, og inden for en uge giver GA4 dig den rapport, Google stille og roligt har lagt på hylden: hvert betalt klik parret som query × produkt — med sessioner, konverteringer og omsætning vedhæftet. Det er i netop det par, pengene gemmer sig — hvilke produkter der trækker skraldetrafik, hvilke titler der rammer ved siden af den reelle efterspørgsel, hvilke forespørgsler der brænder budget af og aldrig sælger. Hele opsætningen er den ene parameter; resten af artiklen handler om, hvad du stiller op med det, der kommer tilbage.

Hvis du kører Shopping- eller Performance Max-kampagner, kender du søgetermsrapporten. Hvad du måske ikke har lagt mærke til — fordi Google aldrig gør opmærksom på det — er, hvad der mangler i den: produktet.

Du ser, at nogen søgte på “ledningsfri støvsuger under 200”. Du ser klik og omkostning. Du ser ikke, hvilket af dine 5.000 produkter den forespørgsel udløste, landede på eller solgte.

For år tilbage gav AdWords API dig denne parring. I dag gør den det ikke. Og for en e-commerce-konto er det ikke et kosmetisk hul — 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.

Inden du spørger: nej, der er ingen indstilling for det. Ingen rapport, intet API-felt, intet script, der henter det tilbage fra Googles side. Du må genopbygge det selv — og genopbygningen er næsten pinligt enkel.

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

I UI’et: Udforsk → fri form. Dimensioner: Manuelt annonceindhold for session + Google Ads-søgeforespørgsel for session. Metrikker: sessioner, konverteringer, købsomsætning. Filter: sessionskilde/-medie = google / cpc.

Via Data API’et — til alt seriøst fodrer det et dashboard eller en BigQuery-samkøring:

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

Samkør sessionManualAdContent mod dit produktfeed (id → titel, pris, kategori), og rapporten er komplet: query × produkt × titel × økonomi.

Verificeret, ikke teoretiseret

Vi rullede det ud på en live konto — en tjekkisk elektronikforhandler med 22 aktiverede Shopping-kampagner — og 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. Og det er her, AI-feed-berigelse holder op med at være et trosspring og bliver en målbar løkke: omskriv titlen omkring den efterspørgsel, du lige har bevist, og se så CTR og konverteringsrate per forespørgsel flytte sig.

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

Én ting du ikke kan: 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, er spørgsmålet ikke “hvordan udelukker jeg det” — det er “hvorfor underpræsterer det”.

Tag forespørgslen og scrap den live resultatside for den. Konkret: DataForSEO, endpoint serp/google/organic/live/advanced — én POST med forespørgselsteksten og location_code for dit marked, og du får hele resultatsiden tilbage som struktureret JSON: betalte annoncer, shopping-blokke med forhandlernavne og priser, organisk nedenunder. Til ~0,0035 $ per forespørgsel koster det at tjekke 200 forespørgsler omkring 0,70 $.

Et typisk fund: din mellemklasse-sovepose samler klik på en generisk forespørgsel — og samme forespørgsel viser tre budget-mærker i samme kategori til halv pris. Dit produkt er ikke dårligt; det er udspillet på pris i præcis den auktion.

Nu har du reelle muligheder: ny prissætning; skub differentieringen op i titlen (“dunfyld, −15 °C komfort”); flyt produktet over i en kampagne med budgivning, der matcher dets margenvirkelighed; eller accepter 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 intention, 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 er evidensgrundlaget for shopping-segmentering — ikke mavefornemmelse.

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 fra en anden konto: en anden mellemstor tjekkisk webshop (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 på den. Ét forbehold med det samme: denne rå rapport giver dig annoncegruppen / produktgruppen, forespørgslen blev serveret under — ikke det enkelte produkt. Det er præcis det hul, UTM-trickset 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.

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

Hvad du gør: eksportér Shopping-søgetermsrapporten via Google Ads API (search_term_view) ind i en lokal tabel — SQLite eller BigQuery, hvad som helst du kan køre GROUP BY på. Hvorfor netop det først: før du samkører noget, skal du mærke, hvor stor og hvor støjende den rå bunke er. Den ene kendsgerning nulstiller enhver forventning, der følger.

Kør et nøgternt COUNT(*) og et par SUMs, og dette lander:

Hvad du har: 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 — kollaps denne bunke langs den dimension, der betaler regningerne — og at advare dig om, at enhver manuel linje-for-linje-triage er håbløs.

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

Hvad du gør: tæl linjerne med nul klik, og filtrér dem fra. Hvorfor: Shopping-søgetermsrapporten logger hver forespørgsel, din annonce blev vist på, og på de fleste klikkede ingen. De rene eksponeringslinjer kan hverken koste dig noget eller konvertere — de er støj, der får tabellen til at se skræmmende ud.

Situation: 22,6 mio. rækker, du ved ikke, hvor du skal starte. Handling: WHERE clicks > 0. Resultat: tabellen kollapser til 738.444 linjer — en håndterbar størrelse.

Hvad du har: 96,7 % af det skræmmende tal var aldrig andet end støj. Du arbejder nu med en tabel på 738.000 linjer, ikke 22,6 millioner — og hver aggregering nedenfor kører på den del, der rent faktisk bruger penge.

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

Hvad du gør: på de klikkede linjer, opdel forbruget i “konverterede mindst én gang” vs. “konverterede aldrig”, og lægg omkostningen sammen for hver. Hvorfor: dette er tallet, der laver “kontoen er fin, ROAS er 6,8” om til “det meste af budgettet laver ingenting”. Det er det centrale mellemresultat — beregn det før enhver optimeringsidé.

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

Hvad du gør: sortér de klikkede linjer efter omkostning, tag de øverste 1 % og øverste 10 %, og se, hvor meget af det samlede forbrug de holder. Hvorfor: dette 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 sætte termer på pause — du har brug for strukturelle løsninger.

Hvad du har: bremsen er long tail, ikke nogle få syndere — de øverste 1 % af de dyre linjer holder knap en tiendedel af forbruget. Så at sætte 20 dårlige termer på pause ændrer ingenting. Det er den data-underbyggede grund til at rette strukturen (hvilke produkter sidder i hvilken kampagne ved hvilket mål) i stedet for at jagte enkelte forespørgsler — og en påmindelse om, at Google alligevel ikke engang lader dig tilføje et negativt søgeord per produkt.

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

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

Situation: “anti-gø-enhed” bliver ved med at brænde budget af. Handling: COUNT(DISTINCT ad_group) for den term. Resultat: den blev serveret under 139 forskellige annonce- / produktgrupper for 976 CZK og ~0 konverteringer. “lego technic” rørte ved 300.

Hvad du har: næsten halvdelen af dine forespørgsler 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 — de er absurde

Hvad du gør: træk de dyreste linjer, der aldrig konverterede, og læs forespørgslen ved siden af den produktgruppe, den blev solgt mod. Hvorfor: aggregat-tallene overbeviser dit regneark; disse tre rækker overbeviser din chef. De er det menneskelæsbare ansigt på Trin 5.

En hundetræningshalsbånd-forespørgsel betalt for under din gruppe 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 dig. Med query × produkt ser du det med ét blik; med Googles standardrapport vil du aldrig gøre det. (Illustrativt eksempel — kategorier oversat og anonymiseret.)

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

Hvad du gør: vend Trin 3 om — isolér kun de linjer, der faktisk konverterede, og lægg deres omkostning og omsætning sammen. Hvorfor: 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.

Hvad du har: 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.

{lpurl}?utm_content={product_id}

FAQ