Google Shopping lijkt een paidmediakanaal, totdat een marketplacebureau moet uitleggen waarom dezelfde SKU winstgevend is op het ene kanaal, bijna uitverkocht raakt op het andere kanaal en ondertussen nog steeds Performance Max-budget krijgt. Dan is het geen campagneprobleem meer. Dan is het een routingprobleem.
Dat verschil is belangrijk voor bureaus met vijf of meer mensen die klanten beheren op Amazon, Walmart, bol, Kaufland, TikTok Shop, Shopify en Google Merchant Center. De Google Ads-specialist ziet ROAS. De marketplace-operator ziet Buy Box-druk. De feedspecialist ziet Merchant Center-waarschuwingen. De inventory owner ziet nog 19 dagen voorraad. De accountmanager hoort de klant vragen waarom Google een product opschaalt dat Amazon ook nodig heeft voor Prime Week. Iedereen kijkt naar hetzelfde bedrijf, maar vanuit een ander dashboard.
De fout die ik vaak zie, noem ik Google Shopping behandelen als los performancekanaal terwijl marketplace operations de trade-offs moet oplossen. Een team optimaliseert titels, fixt afkeuringen, lanceert Performance Max, maakt custom labels en viert 4,2 ROAS. Twee weken later zakt Amazon-rank omdat voorraad ergens anders heen ging, Walmart Ads verliest momentum, de klant vraagt waarom een variant met lage marge zoveel spend kreeg en het bureau moet het verhaal alsnog in een spreadsheet reconstrueren. De Google-campagne was niet per se slecht. Ze kreeg alleen toestemming om vraag te verplaatsen zonder product-routingbesluit.
Mijn standpunt: marketplacebureaus hebben een Google Shopping product routing ledger nodig. Geen extra feed audit. Geen mooier PMax-rapport. Wel een SKU-level beslislaag die vastlegt welke producten Google Shopping-vraag mogen krijgen, welke producten beschermd moeten worden voor marketplaces, welke eerst feedreparatie nodig hebben en welke helemaal geen advertentiebudget verdienen zolang marge, voorraad of productdata niet klopt.
Wat publieke adviezen goed doen
De bestaande uitleg over Google Shopping is nuttig. Productsup legt de basis helder uit: Shopping ads worden gebouwd op productfeeddata, niet op keywords; producttitels, categorieën, GTINs, beschikbaarheid en consistentie tussen feed en landingspagina beïnvloeden eligibility en performance; verouderde data kan producten laten verlopen; verschillen tussen feed en landingspagina kunnen afkeuringen of zelfs accountrisico veroorzaken. Hun agency cases zijn ook praktisch. Webrepublic had een centrale omgeving nodig voor feed exports, planning en diagnostics over meerdere klanten heen. Peak Ace werkte met een dataset van 18.000 producten en acht prijsvergelijkers, en gebruikte feedregels, templates en tracking om zichtbaarheid te verbeteren.
Ook Channable positioneert het duidelijk voor bureaus: agencies hebben automatisering nodig voor shopping feeds, Google Ads, product listings en marketplacekoppelingen. ChannelEngine plaatst marketplace management in de context van content, voorraad, pricing, orders, compliance en analytics. Rithum benadrukt dat sellers productinformatie fris moeten houden, concurrerend moeten prijzen, performance moeten monitoren, moeten adverteren en zorgvuldig moeten uitbreiden. MerchantSpring spreekt juist bureaus aan die rapportage over veel kanalen en merken nodig hebben.
Allemaal waar. Maar veel advies behandelt Google Shopping, marketplaces, feeds en reporting nog steeds als aangrenzende werkstromen. Het agency-probleem is scherper: als Google vraag kan creëren voor hetzelfde product dat Amazon, Walmart of bol ook nodig heeft, wie beslist dan waar de volgende voorraadunit en de volgende euro budget naartoe gaan?
De ontbrekende laag: product routing vóór campagneoptimalisatie
Een product routing ledger is de brug tussen feedkwaliteit en commerciële toestemming. Het vervangt Merchant Center, Google Ads, marketplaceconnectors of klantrapportages niet. Het bepaalt wat die systemen mogen doen.
Minimaal bevat de ledger acht velden per geadverteerde SKU:
- SKU-contributiemarge na marketplace fees, fulfilment, retouren en advertentieruimte.
- Voorraadrunway per kanaal, niet alleen totale voorraad.
- Kanaalrol: acquisitie, winst oogsten, rank verdedigen, clearance, retail readiness of test.
- Feedstatus: goedgekeurd, beperkt, afgekeurd, ontbrekende attributen of mismatch met landingspagina.
- Advertentietoestemming: schalen, behouden, leren, pauzeren of blokkeren.
- Besliseigenaar bij de klant: wie budget-, assortiment- en marge-uitzonderingen mag goedkeuren.
- Actueel vraagconflict: waar dezelfde SKU al gepusht wordt.
- Vervaldatum van het besluit, want voorraad en marge van vorige week kunnen snel fictie worden.
Dat klinkt operationeel, en dat is het ook. Maar precies daar bescherm je bureaumarge. Zonder ledger blijven senior mensen dezelfde vragen opnieuw oplossen: waarom schaalde Google deze SKU, waarom raakte Amazon uit voorraad, waarom keurde Merchant Center producten goed die de klant niet wilde pushen, waarom liet het rapport ROAS zien terwijl finance zwakke winst zag?
Scenario 1: RhineTech Electronics en de gevaarlijke 4,2 ROAS
Neem RhineTech Electronics, een Duits consumentenelektronicamerk dat wordt beheerd door een marketplacebureau van twaalf mensen. De klant verkoopt 2.400 SKU’s via Amazon.de, Kaufland, Otto, bol en Shopify. Google Shopping en Performance Max hebben samen €18.000 maandbudget. Op papier oogt het account gezond: 4,2 ROAS, 62% impression share op prioriteitsproducten en slechts 3% afgekeurde items in Merchant Center.
De routing ledger verandert het gesprek. Van de 2.400 SKU’s hebben 320 producten minder dan 12% contributiemarge na marketplace fees, garantiereserve en gemiddelde retourkosten. Nog eens 190 producten hebben minder dan 14 dagen voorraad in het Duitse magazijn. Achtenveertig hero-accessoires zijn winstgevend op Shopify, maar zwak op Amazon omdat de Buy Box instabiel is en de combinatie van referral fee en FBA zwaarder uitvalt. Google weet dat niet, tenzij het bureau dit vertaalt naar labels, uitsluitingen en budgetstructuur.
De fout zou zijn om het PMax-budget te verhogen omdat de blended ROAS goed lijkt. De ledger zegt iets preciezers: houd €9.500 op de 740 SKU’s met meer dan 21 dagen voorraad en 18%+ contributiemarge, cap €4.000 op learninggroepen, sluit de 320 margerisico-SKU’s uit en houd €4.500 vast totdat Amazon-voorraad voor de top 25 producten weer veilig is. Dat is niet anti-Google. Dat is pro-winst.
FiveX past hier logisch in, omdat het bureau producten kan groeperen op marge, voorraadrunway en kanaalrol, en vervolgens ad spend en omzet kan terugkoppelen naar SKU-level winstgevendheid. De Google Ads-specialist hoeft finance niet elke vrijdag om een margebestand te vragen. De marketplace lead ziet op tijd of een Google Shopping-win een marketplacebeperking creëert voordat de klant het in de volgende QBR ontdekt.
Scenario 2: Maple Home Co. en de budgetruil tussen kanalen
Neem nu Maple Home Co., een Amerikaans woonmerk met Amazon, Walmart, Shopify en Google Shopping. Het bureau beheert $42.000 maandelijkse media: $18.000 Amazon Ads, $9.000 Walmart Connect, $12.000 Google Shopping en $3.000 Meta-retargeting. Eén lijn opbergmanden wordt de hero. Google Shopping rapporteert 4,6 ROAS bij een gemiddelde orderwaarde van $28. Amazon toont 23% ACOS. Walmart lijkt trager met 3,1 ROAS.
Als het bureau alleen platformrapporten leest, wint Google de discussie. Maar de product routing ledger voegt de saaie cijfers toe die winst bepalen. De Google-route heeft 14% retouren omdat shoppers de afmetingen verkeerd inschatten. Amazon converteert bundels met iets lagere marge, maar heeft slechts 6% retouren. Walmart draait minder volume, maar betere verzendeconomie via WFS. Na retouren en fulfilment komt de Google hero-SKU uit op 7% contributiemarge, Amazon op 13% en Walmart op 16%.
Het bureau hoeft Google Shopping niet uit te zetten. Het moet Google beter routeren. Verplaats $10.500 Google-budget weg van de mand met hoog retourrisico, houd $3.500 over voor query learning en free-listing zichtbaarheid, zet $5.000 op Walmart-producten met betere contributiemarge en gebruik de resterende $5.500 om aangepaste titels en beelden te testen die verwarring over afmetingen verminderen. De klant ziet een commerciële beslissing, geen kanaalpolitiek.
Daarom is FiveX-rapportage belangrijk. Een normaal dashboard kan ROAS per kanaal tonen. Een agency operating layer moet de next-dollar decision tonen: welke SKU verdient spend zodra fees, retouren, voorraad en kanaalrol zichtbaar zijn. Dat is een ander gesprek met de klant, en eerlijk gezegd een veel beter gesprek.
Scenario 3: NordPeak Outdoor en de afkeuringsqueue
Feedproblemen zijn niet allemaal even belangrijk. NordPeak Outdoor heeft 680 SKU’s en 76 Merchant Center-afkeuringen. Een generieke feed audit zegt: “Fix de 76 issues.” Het bureau hoort 76 tickets, allemaal schijnbaar urgent.
De routing ledger rangschikt ze anders. Twaalf afgekeurde SKU’s zijn topmargeproducten met 45+ dagen voorraad en actieve Amazon-campagnes die vraag al bewijzen. Die gaan eerst. Drieëntwintig producten zijn low-margin clearance-items die de klant niet wil promoten zodra Google ze goedkeurt. Die krijgen een blocked label totdat pricing verandert. Vijftien missen GTINs, maar hebben geen voorraadrunway. Wachten dus. De resterende 26 hebben landingspagina-mismatches die ook Meta Catalog beïnvloeden, dus dat wordt een feedsysteemfix in plaats van een Google-only taak.
In deze versie verkoopt het bureau geen “Merchant Center cleanup”. Het verkoopt winstveilige prioritering. Dat is een sterker retainerverhaal.
Zo bouw je de ledger binnen een marketplacebureau
Begin bij het besluit dat je wilt beschermen: geen enkel product mag schaalbare Google Shopping-vraag krijgen zonder acceptabele marge, voldoende voorraad, schone feedstatus en duidelijke kanaalrol. Bouw daarna de workflow terug.
Eerst definieer je productgroepen. Groepeer niet alleen op categorie. Maak commerciële groepen: profit builders, rank defenders, clearance, stock-risk, feed-repair, test en blocked. In FiveX kunnen bureaus productgroepen en productwinstgevendheid gebruiken om die structuur zichtbaar te maken in reporting en advertentiebeslissingen.
Daarna stel je budgettoestemming in. Een product met 25% contributiemarge en 40 dagen voorraad mag anders schalen dan een product met 9% marge en 11 dagen voorraad. Maak simpele toestemmingen: scale, maintain, learn, repair, protect of block. Het doel is geen bureaucratie. Het doel is voorkomen dat elk platform zelfstandig besluit dat het dezelfde SKU verdient.
Verbind vervolgens feedwerk aan commerciële impact. Merchant Center-afkeuringen, ontbrekende attributen en landingspagina-mismatches horen gesorteerd te worden op winstblootstelling, niet op de volgorde waarin ze verschijnen. Als een fix €6.200 winstgevende vraag kan vrijspelen, verdient die prioriteit. Als een fix een SKU vrijspeelt die de klant beter niet kan pushen, kan die wachten.
Maak tot slot een approval path voor uitzonderingen. Soms moet een lage-marge-SKU toch Google Shopping-vraag krijgen omdat hij klanten introduceert in een categorie met herhaalaankopen. Soms mag een stock-risk product gepromoot worden omdat inbound voorraad bevestigd is. Prima. Maar uitzonderingen hebben een eigenaar, reden en vervaldatum nodig.
Rapporteer de ledger, niet alleen het platform. Klanten hebben geen extra screenshot van Merchant Center diagnostics nodig. Ze willen weten welke producten vraag mogen krijgen, welke geblokkeerd zijn, welke winst op het spel staat en wat het bureau nu doet. FiveX kan marketplace performance, ad spend, SKU-marge, productgroepen en voorraadsignalen in één rapportagelaag samenbrengen, zodat de klant de operationele beslissing achter de campagne ziet.
De trade-off die bureaus moeten accepteren
De product routing ledger zal sommige campagnes vertragen. Goed zo. Sommige campagnes moeten vertraagd worden.
Snelheid is waardevol wanneer het product klaar is. Snelheid is duur wanneer marge zwak is, voorraad fragiel is, feeddata rommelig is of kanaalconflict nog niet is opgelost. De operator-les is simpel: laat een nette Google Shopping-setup niet sneller lopen dan de marketplace-businesscase.
Beheer je marketplaceklanten, dan hoort Google Shopping niet buiten de marketplace operating room. Het gebruikt dezelfde catalogus, concurreert om dezelfde voorraad, beïnvloedt dezelfde prijsverwachtingen en verandert dezelfde klantwinst. Behandel het als onderdeel van het product routing systeem en het bureau neemt betere beslissingen: minder budgetdiscussies, schonere klantrapportage, minder spoedwerk in feeds en meer spend naar SKU’s die vraag echt in winst kunnen omzetten.
Dat is uiteindelijk het werk. Niet “meer Google Shopping performance”. Wel meer winstgevende vraag, naar het juiste product, op het juiste moment, met bewijs dat de klant kan vertrouwen.