Hoe maak ik mijn eigen Custom Listener Script aan?

Niet elke actie op een website levert een bruikbare trigger op. Denk aan formulieren die geen eigen dataLayer event pushen, formulieren zonder page redirect of thank you page, of een CMS waarbij de gebruikersgegevens (e-mailadres, telefoonnummer, order-ID) niet in de standaard e-commerce dataLayer terechtkomen.

In vrijwel al die gevallen gebeurt er op de achtergrond wél iets: de website stuurt een network request naar de eigen server of naar een externe API. Die request kun je gebruiken als trigger. In dit artikel lees je hoe je met DevTools de juiste request opspoort en hoe je in je GTM web container een listener script toevoegt dat op dat moment een dataLayer event pusht.

Let op: gebruik deze methode alleen als er geen native oplossing bestaat. Een listener op een network request is afhankelijk van de interne werking van de website of plugin. Wijzigt de leverancier het endpoint, dan stopt de meting zonder foutmelding. Documenteer de implementatie daarom altijd.

1. Open de pagina met het formulier of de actie die je wilt meten.

2. Open DevTools (F12 of Ctrl + Shift + I / Cmd + Option + I) en ga naar het tabblad Network.

3. Zet Preserve log aan. Zonder deze optie ben je je requests kwijt zodra de pagina herlaadt of doorstuurt.

4. Filter op Fetch/XHR. Dit filtert afbeeldingen, stylesheets en scripts weg.

5. Leeg de lijst met het clear-icoon (⊘) en voer de actie uit: vul het formulier in en verstuur het.

6. Bekijk de requests die verschijnen. De juiste request herken je meestal aan:

   • Method POST in plaats van GET

   • Een endpoint dat inhoudelijk klopt, bijvoorbeeld /wp-json/contact-form-7/v1/contact-forms/123/feedback, /api/lead, /graphql of /checkout/complete

   • Een Status van 200 of 201

7. Klik de request aan en controleer de tabbladen:

   • Headers → de volledige Request URL en de method

   • Payload → de data die de browser verstuurt (vaak de ingevulde formuliervelden)

   • Preview / Response → wat de server terugstuurt. Hier vind je regelmatig een bevestigingsstatus, een lead-ID of de ingevulde gegevens.

Bepaal tot slot een uniek en stabiel deel van de URL dat je gaat gebruiken om te matchen. Kies iets specifieks: /feedback matcht op een WordPress-site mogelijk ook andere requests, /wp-json/contact-form-7/ is een stuk veiliger. Een te brede match zorgt voor dubbele of onterechte events.

Tip: met een rechtermuisklik op de request kies je Copy → Copy as fetch. Zo heb je de volledige URL, method en payload in één keer op je klembord om te delen met een collega of te bewaren in je documentatie.

Al deze informatie die je verzameld kan je gebruiken om een Custom HTML Listener script te (laten) schrijven. Voor meer informatie verwijzen we je naar dit blog-artikel van Simo Ahava.

Kijk goed naar de response voordat je verder gaat. Drie scenario's:

• De response bevat alleen een statusbevestiging. Prima om een conversie-event te triggeren, maar er is geen user data beschikbaar.

• De response bevat user data (e-mail, telefoonnummer, order-ID). Ideaal voor Enhanced Conversions, Meta CAPI en server-side tagging.

• Alleen de payload bevat de user data. Dan kun je die uitlezen uit de verstuurde request in plaats van uit de response.

Maak in je web container een nieuwe tag aan van het type Custom HTML en plak je custom html script.

• Trigger: Initialization – All Pages. Het script moet de originele functies vervangen vóórdat de applicatiecode zijn eerste request verstuurt.

• Ondersteuning voor document.write: uit laten staan.

• Vuur de tag maar één keer per pagina af. Wordt het script twee keer geladen, dan is de kans aanwezig op dubbele events.

1. Maak een Custom Event trigger aan met de eventnaam die je in EVENT_NAME hebt gezet, bijvoorbeeld form_submitted.

2. Maak Data Layer Variables aan voor de velden die je nodig hebt. Voor geneste waarden gebruik je puntnotatie, bijvoorbeeld response_data.email of response_data.data.order_id.

3. Koppel deze aan je GA4 event tag, je Google Ads conversietag of stuur ze door naar je server-side container.

1. Open Preview in GTM en doorloop de flow op de website.

2. Controleer in het tabblad Data Layer of het event verschijnt op het juiste moment en of response_data is gevuld.

3. Test ook de foutsituatie: verstuur een formulier met een validatiefout. Het event mag dan niet afvuren, omdat de statuscheck in het script dit tegenhoudt.

4. Controleer of het event exact één keer voorkomt.

Timing. Laadt de applicatiecode van de website eerder dan de GTM-container, dan is het script te laat en mist het de eerste requests. Dit speelt vooral bij single page applications. Controleer in dat geval of het GTM-snippet zo hoog mogelijk in de <head> staat.

Privacy en AVG. Zet geen ruwe persoonsgegevens in de dataLayer als je ze niet nodig hebt, en respecteer de consentstatus van de bezoeker. Wil je e-mailadressen gebruiken voor Enhanced Conversions of CAPI, hash deze dan bij voorkeur server-side.

Onderhoud. De listener is gekoppeld aan een endpoint dat buiten jouw beheer valt. Neem de gebruikte MATCH_URL op in je documentatie en controleer de meting na een update van het CMS, thema of de plugin.

Alternatieven. Levert het formulier een bevestigingspagina, een zichtbare succesmelding of een eigen JavaScript-event op, gebruik die dan. Dat is stabieler dan het onderscheppen van network requests.