Google Tag Manager uitgelegd: de basis voor KMO's

Google Tag Manager is de gratis plek waar je de meet- en advertentiecodes van je website beheert, zoals de Google-tag en de Meta-pixel ^{[1], [2]}. Je plaatst één keer twee codefragmenten, daarna werk je in de webinterface. Maak het account op naam van je bedrijf, laad je cookiebanner als eerste en test elke wijziging voor je publiceert.

Ook als een Google Analytics bureau of je webbouwer het opzet, loont het om de basis te kennen. Tag Manager beslist welke gegevens je website verlaten, naar wie, en of dat pas na toestemming gebeurt. Zelf meet of rapporteert het niets: dat doet GA4.

Heb je Tag Manager nodig?

Niet altijd. Voor de standaardmeting van paginaweergaven, klikken en scrolls volstaat de Google-tag, maar wie meer controle wil, raadt Google Tag Manager aan ^[3]. De Google-tag stuurt bovendien alleen naar Google, Tag Manager ook naar andere partijen ^[3].

Wie moet eigenaar zijn?

Je eigen bedrijf. Google raadt aan dat je bedrijf het account aanmaakt en een bureau als gebruiker toevoegt, dat iemand van je eigen organisatie het beheert, en dat er minstens één extra beheerder is ^[5]. Valt je enige beheerder weg, dan kun je de toegang tot je tags verliezen ^{[5], [6]}.

Een werkbare verdeling voor een KMO: twee mensen van je bedrijf zijn beheerder van het account, je bureau krijgt publicatierechten op de container. Tussen lezen en publiceren liggen nog twee niveaus: bewerken (wijzigen, maar geen versies maken of publiceren) en goedkeuren (ook versies maken, maar niet publiceren) ^[6].

Elke publicatie bewaart een versie, die je bij een fout opnieuw als laatste versie zet ^[7]. Exporteer je container als JSON-bestand bij elke wissel van bureau of webbouwer ^[8]. Tag Manager hoort dan op de overdrachtslijst, naast je advertentieaccounts: zie Google Ads-account overdragen of van beheerder wisselen.

Een vaste naamgeving maakt je container leesbaar voor wie na jou komt, bijvoorbeeld bestemming, type en actie: GA4 - event - generate_lead voor de tag en CE - generate_lead voor de trigger.

Tags, triggers, variabelen en de datalaag

Een tag is code die gegevens naar een systeem zoals GA4 stuurt. Een trigger luistert naar gebeurtenissen, zoals een klik of het laden van een pagina, en laat tags vuren. Een variabele is een benoemde plaatshouder voor een waarde die verandert, zoals een prijs ^[9].

Samen vormen ze een container: alle tags, triggers en variabelen voor één website ^[1]. Google raadt één container per domein aan ^[5]. Een tweetalige site met /nl/ en /fr/ op één domein heeft dus genoeg aan één container.

De datalaag is het object waarmee je website informatie aan Tag Manager doorgeeft ^[10]. Google verkiest ze boven waarden uit de opmaak van de pagina, omdat een codewijziging dan minder snel gegevens kost ^[9]. Een voorbeeld: je site voert deze code uit zodra een offerteformulier echt verzonden is.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'generate_lead',
  form_name: 'offerte'
});

Een trigger van het type Custom Event op generate_lead laat dan de GA4-tag en de conversietag van Google Ads vuren, en een mislukte verzending telt niet mee. Waarom dat moment het verschil maakt, lees je in GA4 key events en conversies: het verschil uitgelegd.

Zet in de briefing voor je webbouwer:

• welke events de site doorgeeft, met exacte namen en parameters, op alle pagina's dezelfde ^[10];
• dat de datalaag vóór de containercode staat en daarna alleen aangevuld wordt met dataLayer.push(), nooit overschreven ^[10];
• wanneer elk event vuurt: na een geslaagde verzending of betaling, niet bij de klik op een knop.

Toestemming regel je per tag

In België heb je voor analytische en advertentietracking voorafgaande toestemming nodig, ook bij pixels, device fingerprinting en local storage ^[11]. Een pixel via Tag Manager valt daar net zo goed onder als een pixel in de code. Tag Manager heeft er vier hulpmiddelen voor ^[4]:

• De trigger Consent Initialization voor je cookiebanner. Die vuurt altijd vóór alle andere tags, ook vóór Initialization-triggers.
• Ingebouwde toestemmingscontroles in de tags van Google, zoals die van GA4 en Google Ads.
• Require additional consent for tag to fire voor tags van andere partijen, zoals de Meta-pixel. De tag vuurt alleen als alle opgegeven toestemmingstypes op granted staan.
• Het Toestemmingsoverzicht (Consent Overview), dat je aanzet in de containerinstellingen. Het toont welke tags nog geen toestemmingsinstelling hebben.

Stel toestemming niet in met een Custom HTML-tag, maar met de toestemmings-API's van Tag Manager, bijvoorbeeld via het sjabloon van je bannerleverancier in de Community Template Gallery ^{[4], [10]}. Of je basic of advanced Consent Mode kiest, lees je in Consent Mode v2 in de praktijk: basic of advanced?.

Zo start je in zes stappen

1. Maak het account aan op naam van je bedrijf, op tagmanager.google.com: één account per organisatie, één container per website ^{[1], [12]}.
2. Plaats de twee codefragmenten: het eerste zo hoog mogelijk in de <head>, het tweede direct na de openingstag <body> ^[13].
3. Laad je cookiebanner als eerste, op de trigger Consent Initialization - All Pages ^[4].
4. Voeg de Google-tag toe op de trigger Initialization - All Pages. Op een andere trigger kan GA4 sessies zonder bron en medium tonen, als (not set) of Unassigned ^[14].
5. Test in de voorbeeldmodus. Tag Assistant toont welke tags vuurden en in welke volgorde; je bezoekers zien daar niets van ^[15].
6. Publiceer met een versienaam die zegt wat er veranderde ^[7].

Gebruik voor Google Ads en GA4 de ingebouwde tagsjablonen, geen Custom HTML met gtag.js-code ^[10]. Sjablonen uit de Community Template Gallery komen van externe ontwikkelaars: lees de rechten na die ze vragen ^[16]. En laad GA4 nooit dubbel, via je thema of een plugin én via Tag Manager, want dan telt elke paginaweergave twee keer.

Twijfel je of je container klopt? De gratis tracking-audit kijkt na welke tags er vuren, of ze de toestemming van je bezoekers volgen en of je conversies één keer tellen. Leestoegang tot je container volstaat.