Het Shopping-zoekopdrachtenrapport dat Google je niet geeft

Voeg één URL-parameter toe aan je Shopping- en Performance Max-campagnes en binnen een week levert GA4 je het rapport dat Google stilletjes heeft afgeschaft: elke betaalde klik gekoppeld als zoekopdracht × product — met sessies, conversies en omzet eraan vast. Juist in die koppeling zit het geld verstopt — welke producten rommeltraffic trekken, welke titels echte vraag missen, welke zoekopdrachten budget verbranden en nooit verkopen. De bouw is die ene parameter; de rest van dit artikel gaat over wat je doet met wat terugkomt.

Als je Shopping- of Performance Max-campagnes draait, ken je het zoekopdrachtenrapport. Wat je misschien niet hebt opgemerkt — omdat Google er nooit op wijst — is wat erin ontbreekt: het product.

Je ziet dat iemand zocht op “steelstofzuiger onder 200”. Je ziet klikken en kosten. Je ziet niet welk van je 5.000 producten die zoekopdracht triggerde, waar die op landde of wat verkocht werd.

Jaren geleden gaf de AdWords API je deze koppeling wel. Vandaag niet meer. En voor een e-commerce-account is dat geen cosmetisch gat — zoekopdracht-naar-product is waar de echte optimalisatie zit: of je titels echte vraag dekken, welke producten rommeltraffic aantrekken, waarom een product klikken krijgt maar nooit converteert.

Voordat je het vraagt: nee, hier is geen instelling voor. Geen rapport, geen API-veld, geen script dat het terugbrengt vanaf Google’s kant. Je moet het zelf herbouwen — en die herbouw is bijna gênant eenvoudig.

De oplossing: één parameter, twee GA4-dimensies

Auto-tagging en de handmatige UTM vechten niet met elkaar: gclid blijft bron, medium en campagne afhandelen; jouw UTM draagt alleen de product-ID.

Weet wat je krijgt (en wat niet)

Het rapport uit GA4 trekken

In de UI: Verkennen → vrije vorm. Dimensies: Session manual ad content + Session Google Ads query. Statistieken: sessies, conversies, aankoopomzet. Filter: sessiebron/-medium = google / cpc.

Via de Data API — voor iets serieus voedt dit een dashboard of een 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"),
    )),
)

Koppel sessionManualAdContent aan je product feed (id → titel, prijs, categorie) en het rapport is compleet: zoekopdracht × product × titel × economie.

Geverifieerd, niet getheoretiseerd

We rolden dit uit op een live account — een Tsjechische elektronica­retailer met 22 ingeschakelde Shopping-campagnes — en checkten GA4 zeven dagen later:

Nu het leuke deel: wat de paren je vertellen

1 · Het titelgat

Zet de zoekopdrachten naast de titel en beschrijving die ze triggerden. De mismatch springt eruit:

De feed-roadmap schrijft zichzelf. En dit is waar AI feed-verrijking ophoudt een sprong in het diepe te zijn en een meetbare loop wordt: herschrijf de titel rond de vraag die je net hebt bewezen, en kijk dan hoe CTR en conversiepercentage per zoekopdracht bewegen.

2 · Wie er nog meer op “jouw” zoekopdracht zit — en met welk product

Eén ding dat je niet kunt: uitgesloten zoekwoorden per product toevoegen. Google geeft je zo’n hendel niet in Shopping of PMax. Dus als een zoekopdracht × product-paar onderpresteert, is de vraag niet “hoe sluit ik het uit” — maar “waarom presteert het onder”.

Neem de zoekopdracht en scrape de live resultatenpagina ervoor. Concreet: DataForSEO, endpoint serp/google/organic/live/advanced — één POST met de zoekopdracht-tekst en de location_code van je markt, en je krijgt de hele resultatenpagina terug als gestructureerde JSON: betaalde advertenties, shoppingblokken met merchantnamen en prijzen, organisch eronder. Tegen ~$0,0035 per zoekopdracht kost het checken van 200 zoekopdrachten ongeveer $0,70.

Een typische bevinding: je middenklasse slaapzak verzamelt klikken op een generieke zoekopdracht — en dezelfde zoekopdracht toont drie budgetmerken in dezelfde categorie tegen de helft van jouw prijs. Je product is niet slecht; het is op prijs overklast in die specifieke veiling.

Nu heb je echte opties: herprijzen; het onderscheidende kenmerk in de titel zetten (“donsvulling, −15 °C comfort”); het product verplaatsen naar een campagne met een biedstrategie die past bij de marge-realiteit; of de zoekopdracht accepteren als upper-funnel en hem beoordelen op assisterende statistieken in plaats van last click.

3 · Structuur- en biedbeslissingen

Producten die zoekopdrachten met hoge intentie aantrekken, verdienen hun eigen componentengroepen en budgetten. Producten die alleen generieke traffic verzamelen, horen in restgroepen met conservatieve targets. Dit rapport is de bewijsbasis voor shopping-segmentatie — geen onderbuikgevoel.

4 · Een gezondheidscheck voor PMax

PMax vertelt je vrijwel niets over zoeken. Dit rapport is het dichtste wat je krijgt bij een audit van wat PMax daadwerkelijk voor je inkoopt op het zoekoppervlak — per product.

Kijk hoe ik één echte export doorloop, stap voor stap

Alles hierboven is het waarom. Hier is het hoe het er echt uitziet — elke stap, wat je downloadt, waar je naar staart en het echte getal dat terugkomt.

De data is een tweede account: een andere middelgrote Tsjechische webshop (niet de elektronica­retailer uit het GA4-blok hierboven — ik gebruik die omdat het assortiment breed genoeg is dat elk patroon op volle schaal zichtbaar wordt). Ik trok het ruwe Shopping-zoekopdrachtenrapport via de Google Ads API in een lokale SQLite-tabel en draaide de aggregaties hieronder. Eerst één kanttekening: dit ruwe rapport geeft je de advertentiegroep / productgroep waaronder de zoekopdracht werd geserveerd, niet het individuele product. Dat is precies het gat dat de UTM-truc dicht — maar zelfs op productgroepniveau zijn de tussentijdse uitkomsten luid genoeg om het punt te maken.

Bron voor elk getal in deze sectie: Google Ads Shopping-zoekopdrachtenrapport, één middelgroot Tsjechisch webshopaccount, ~22,6M regels, data getrokken april 2026.

Stap 1 · Trek het ruwe rapport en meet de berg

Wat je doet: exporteer het Shopping-zoekopdrachtenrapport via de Google Ads API (search_term_view) naar een lokale tabel — SQLite of BigQuery, alles waarop je een GROUP BY kunt draaien. Waarom dit eerst: voordat je iets koppelt, moet je voelen hoe groot en hoe luidruchtig de ruwe berg is. Dat ene feit reset elke verwachting die volgt.

Draai een simpele COUNT(*) en een paar SUM’s en dit is wat landt:

Wat je hebt: 22,6 miljoen regels, 5,4 miljoen unieke zoekopdrachten. Geen mens leest dat. De enige taak van dat getal is je de volgende zet aanwijzen — klap deze berg in langs de dimensie die de rekeningen betaalt — en je waarschuwen dat handmatige triage per regel hopeloos is.

Stap 2 · Gooi 96 % weg vóór je iets analyseert

Wat je doet: tel de regels met nul klikken en filter ze eruit. Waarom: het Shopping-zoekopdrachtenrapport logt elke zoekopdracht waarvoor je advertentie verscheen, waarvan op de meeste niemand klikte. Die regels met alleen vertoningen kunnen je niets kosten en niets converteren — het is ruis die de tabel angstaanjagend laat lijken.

Situatie: 22,6M rijen, je weet niet waar te beginnen. Actie: WHERE clicks > 0. Resultaat: de tabel klapt in tot 738.444 regels — een werkbaar formaat.

Wat je hebt: 96,7 % van het angstaanjagende getal was nooit iets anders dan ruis. Je werkt nu met een tabel van 738K regels, niet 22,6M — en elke aggregatie hieronder draait op het deel dat echt geld uitgeeft.

Stap 3 · Stel de ene vraag die het account herkadert

Wat je doet: splits op de geklikte regels de uitgaven in “minstens één keer geconverteerd” versus “nooit geconverteerd”, en tel de kosten van elk op. Waarom: dit is het getal dat “het account is prima, ROAS is 6,8” omzet in “het meeste budget doet niets”. Het is de belangrijkste tussentijdse uitkomst — bereken het vóór elk optimalisatie-idee.

Wat je hebt: 85 % van het budget liep door zoekopdracht × productgroep-combinaties die nooit één keer converteerden. Dat is geen afrondingsfout die je later optimaliseert — het is de hoofdact. En je kon het alleen zien omdat je de zoekopdracht hebt ingeklapt langs waartegen die werd verkocht.

Stap 4 · Check of de verspilling een paar schurken is of de hele meute

Wat je doet: sorteer de geklikte regels op kosten, neem de top 1 % en top 10 %, en kijk hoeveel van de totale uitgaven ze vasthouden. Waarom: dit bepaalt je tactiek. Als een handjevol termen het budget verbrandt, pauzeer je die en ben je klaar. Als de verspilling dun verspreid is, is termen pauzeren zinloos — dan heb je structurele fixes nodig.

Wat je hebt: de rem is long-tail, niet een paar overtreders — de top 1 % van dure regels houdt amper een tiende van de uitgaven vast. Dus 20 slechte termen pauzeren verandert niets. Dit is de data-onderbouwde reden om de structuur te fixen (welke producten in welke campagne op welk target) in plaats van individuele zoekopdrachten te jagen — en een herinnering dat Google je sowieso geen uitsluiting per product laat toevoegen.

Stap 5 · Ontdek waarom de long tail lekt: één zoekopdracht, veel producten

Wat je doet: tel voor elke zoekopdracht hoeveel verschillende productgroepen die werd geserveerd. Waarom: het verklaart de verspilling mechanisch. Shopping matcht een zoekopdracht tegen de signalen van je hele feed, niet tegen de relevantie van één product — dus één zoekopdracht lekt over ongerelateerde hoeken van je assortiment, en je betaalt voor elke misser.

Situatie: “anti-blafapparaat” blijft budget verbranden. Actie: COUNT(DISTINCT ad_group) voor die term. Resultaat: het werd geserveerd onder 139 verschillende advertentie- / productgroepen voor 976 CZK en ~0 conversies. “lego technic” raakte er 300.

Wat je hebt: bijna de helft van je zoekopdrachten is uitgesmeerd over meerdere productgroepen, en de ergste overtreders bereiken er duizenden. Dat is de motor van de nul-conversie-rem uit Stap 3 — en precies het ding dat je eindelijk kunt zien zodra elke klik zijn product-ID draagt.

Stap 6 · Bekijk de ergste mismatches — ze zijn absurd

Wat je doet: trek de duurste regels die nooit converteerden en lees de zoekopdracht naast de productgroep waartegen die werd verkocht. Waarom: de aggregaatgetallen overtuigen je spreadsheet; deze drie rijen overtuigen je baas. Ze zijn het menselijk leesbare gezicht van Stap 5.

Een zoekopdracht voor een hondentrainingsband betaald onder je groep Handtassen. Een anti-blafapparaat verkocht tegen Babyproducten. De productgroep heeft niets met de zoekopdracht te maken — Google matchte op brede feedsignalen, incasseerde de klik en rekende je af. Met zoekopdracht × product zie je dit in één oogopslag; met Google’s standaardrapport nooit. (Illustratief voorbeeld — categorieën vertaald en geanonimiseerd.)

Stap 7 · Nu de beloning: de 0,25 % die het hele account betaalt

Wat je doet: keer Stap 3 om — isoleer alleen de regels die wel converteerden en tel hun kosten en omzet op. Waarom: dit is de reden waarom de hele exercitie ertoe doet. Zodra je de winnaars kunt scheiden van de rem, bescherm je de winnaars en verhonger je de rest.

Wat je hebt: een kwart procent van de regels draait op 46,8× ROAS en draagt feitelijk het account; de andere 99,75 % trekt het blended cijfer omlaag naar 6,8×. Dat schijfje vinden, zijn budget beschermen en al het andere ervandaan structureren is het hele werk — en niets daarvan is mogelijk totdat elke regel het product draagt waartegen die werd verkocht. Dat is wat de één-parameter-UTM bovenaan dit artikel je oplevert.

{lpurl}?utm_content={product_id}

FAQ