Google Enhanced Conversions-update 2026: de meeste bureaus hebben nog steeds niet gecontroleerd of die van hen werkt

In juni 2026 heeft Google Ads de werking van Enhanced Conversions aangepast. De twee afzonderlijke producten, Enhanced Conversions for Web en Enhanced Conversions for Leads, die elk hun eigen instellingenpagina en implementatiemethode hadden, zijn samengevoegd tot één aan/uit-schakelaar.

Google heeft het gepresenteerd als een vereenvoudiging, en dat is het ook. Maar de update doet ook iets wat minder voor de hand ligt. Het verwijdert de zichtbare herinnering dat ‘Enhanced Conversions’ een actief systeem is met bewegende onderdelen, en niet zomaar een schakelaar die je één keer omzet en vervolgens vergeet. Als je het een tijdje geleden hebt ingesteld en er sindsdien niet meer naar hebt gekeken, is de kans groot dat het niets meer doet.

Een groot deel van de Enhanced Conversions-instellingen lijkt actief in Google Ads, terwijl er weinig of geen bruikbare gegevens worden verzonden. De schakelaar staat op ‘aan’. De conversieactie laat activiteit zien. Maar de gehashtte gebruikersgegevens die de hele functie laten werken, komen nooit echt in bruikbare vorm bij Google terecht. Niemand merkt het, want er is niets in de interface dat erop wijst dat er iets mis is.

Hier lees je wat er in juni 2026 daadwerkelijk is veranderd, waarom instellingen voor Google Enhanced Conversions mislukken zonder dat er een zichtbare foutmelding verschijnt, hoe je kunt controleren of jouw instelling hier ook onder valt, en waarom het doorvoeren van de instelling via server-side GTM de meeste storingspunten al bij voorbaat wegneemt.

Wat Google Enhanced Conversions eigenlijk doen

Verbeterde conversies zijn er omdat conversietracking op basis van cookies een tekortkoming heeft. Google Ads schrijft een conversie normaal gesproken toe aan de hand van een GCLID, een klik-ID die in een browsercookie wordt opgeslagen. Als die cookie ontbreekt (geblokkeerd of gewist is, of als de gebruiker op een ander apparaat heeft geconverteerd), vindt de conversie nog steeds plaats, maar kan Google deze niet koppelen aan de advertentie die ervoor gezorgd heeft.

Verbeterde conversies dichten een deel van die kloof met een tweede identificatiecode. Als een gebruiker converteert, legt je site first-party gegevens vast (meestal een e-mailadres) en versleutelt deze met SHA-256 voordat ze naar Google worden gestuurd. Google vergelijkt die hash met hashes die zijn afgeleid van de gegevens van zijn eigen ingelogde accounts. Als ze overeenkomen, wordt de conversie toegewezen, zelfs zonder een werkende GCLID.

Dat is het hele proces: hashen, versturen, vergelijken. Het hashen is eenrichtingsverkeer, dus Google krijgt nooit een leesbaar e-mailadres te zien, alleen een soort vingerafdruk ervan.

Voor een volledig overzicht, inclusief ‘Enhanced Conversions’ voor web versus leads, hoe de matchpercentages werken en instructies voor het instellen van elke implementatiemethode, kun je onze complete gids over Google Enhanced Conversions bekijken.

Google Enhanced Conversions-update van juni 2026: wat is er veranderd?

Vóór juni 2026 waren ‘Enhanced Conversions for Web’ en ‘Enhanced Conversions for Leads’ aparte functies. Ze hadden elk hun eigen instellingenscherm en adverteerders moesten per conversieactie één implementatiemethode kiezen (de Google-tag, GTM of de API).

Vanaf april 2026 begon Google gegevens van gebruikers tegelijkertijd te accepteren via websitetags, Data Manager en API-verbindingen, in plaats van één enkele methode verplicht te stellen. Vanaf juni 2026 werd die flexibiliteit de standaard: de twee producten werden samengevoegd tot één functie met één aan/uit-schakelaar, en het scherm voor het kiezen van de methode verdween helemaal uit de interface.

Voor bureaus die meerdere accounts beheren, zijn er drie dingen die je na de samenvoeging even moet controleren.

Bestaande instellingen zijn automatisch gemigreerd, maar alleen voor accounts die de voorwaarden van Google voor klantgegevens al hadden geaccepteerd. Als een klantaccount die voorwaarden nooit expliciet heeft geaccepteerd (wat vaak voorkomt als Enhanced Conversions is ingeschakeld door een vorig bureau of een intern team dat de volledige configuratie niet heeft afgerond), verloopt de migratie niet soepel en kan het zijn dat Enhanced Conversions in het account wel als beschikbaar wordt weergegeven, maar inactief is.

Door de verandering in de interface zijn sommige diagnostische aanwijzingen verdwenen die er vroeger wel waren. Toen de methodeselectie nog zichtbaar was, kon je tenminste nog zien welk implementatiepad een conversieactie zou moeten gebruiken. Nu dat scherm weg is, hangt het controleren van de instellingen meer af van de diagnostische informatie en minder van het feit of de instellingenpagina overeenkomt met wat je verwacht.

De opt-out bestaat nog steeds op het niveau van de conversieactie, en de samenvoeging verandert niets aan de onderliggende vereiste van de Voorwaarden voor gegevensverwerking. Google verwacht nog steeds dat adverteerders akkoord zijn gegaan met die voorwaarden en dat ze met door gebruikers verstrekte gegevens omgaan op een manier die aan het beleid voldoet. De schakelaar is eenvoudiger geworden, maar de verplichting om aan de regels te voldoen is niet veranderd.

Werkende opstellingen blijven gewoon werken. Maar dit is een goed moment om accounts te controleren die al een tijdje geleden zijn aangemaakt en daarna nooit meer zijn bekeken, want het samenvoegen is precies het soort verandering dat problemen aan het licht brengt waar niemand op zat te letten.

Waarom Enhanced Conversions stilletjes mislukt en hoe je dat kunt opmerken

Google Enhanced Conversions heeft een specifieke foutmodus die je makkelijk over het hoofd kunt zien. De conversietag kan correct worden geactiveerd, de conversie wordt nog steeds geregistreerd en Google Ads kan de conversieactie als actief weergeven, terwijl de uitgebreide gegevens zelf nooit daadwerkelijk in bruikbare vorm bij Google terechtkomen.

Het diagnostische rapport van Google zelf definieert om precies deze reden verschillende statussen. „Verbeterde conversies registreren” betekent dat het echt werkt. „Wachten op verbeterde conversiegegevens” kan betekenen dat het nog te vroeg is, aangezien de status tot wel 48 uur achter kan lopen. Maar ‘Configuratieproblemen gedetecteerd’ en, voor leads, de status ‘Dringend’ wijzen er allebei op dat de configuratie er wel live uitziet, maar niets bruikbaars oplevert. In de kloof tussen die statussen zitten de meeste defecte configuraties maandenlang ongemoeid, terwijl niemand eraan denkt om ernaar te kijken.

De meest voorkomende oorzaken zijn niet zo ingrijpend. Het zijn kleine configuratiedetails die nergens een foutmelding geven:

• Het veld `user_data` is aanwezig, maar leeg. De tag wordt geactiveerd, de wrapper komt bij Google aan, maar het veld met de gehasht e-mail of telefoonnummer daarin is leeg. Google registreert de ping als ontvangen en gaat verder. Het geeft geen melding dat er „niets bruikbaars in zat”. Meestal gaat het hier om een GTM-variabele die nooit aan de juiste dataLayer-sleutel is gekoppeld, en dat is de allermeest voorkomende oorzaak van een op het eerste gezicht goed werkende opzet die toch geen signaal afgeeft.
• Dubbele hashing. Sommige teams hashen het e-mailadres zelf voordat ze het naar de dataLayer sturen, waarna GTM of de Google-tag het nogmaals hasht voordat het wordt verzonden. Google vergelijkt uiteindelijk een hash van een hash met zijn eigen database van afzonderlijke hashes. Er is nooit een overeenkomst en er is geen foutmelding die de oorzaak aangeeft. De oplossing is om altijd de ruwe waarde te versturen en GTM of gtag.js de hashing te laten doen.
• De schakelaar omzetten zonder de tag aan te raken. Als je ‘Verbeterde conversies’ inschakelt in de Google Ads-interface, wordt je GTM-tag niet automatisch opnieuw geconfigureerd. Als de user_data-velden in de conversietag nooit zijn ingesteld, heeft het inschakelen van de schakelaar op accountniveau geen effect, behalve dat de instelling er actief uitziet.
• CSS-selectoren werken niet meer na een herontwerp van de site. Als de oorspronkelijke opzet het e-mailveld vastlegde door een CSS-selector op de bevestigingspagina te gebruiken, zorgt een herontwerp waarbij element-ID’s of klassennamen veranderen ervoor dat de selector niet meer werkt zonder dat iemand het merkt. De tag wordt nog steeds geactiveerd. Hij vindt alleen niets meer om te hashen. Variabelen in de datalaag hebben dit probleem niet, en dat is een van de redenen waarom ze de duurzamere optie zijn.
• Toestemmingsverzoeken die eruitzien als gewone variatie. Als de toestemming voor ad_user_data wordt geweigerd, stuurt Enhanced Conversions de gehasht gegevens voor die gebruiker gewoon niet door. Dat is de bedoeling, geen bug, maar het betekent wel dat het matchpercentage vanzelf daalt in regio’s waar veel toestemming wordt gevraagd. De kunst is om het verschil te zien tussen de verwachte variatie door toestemmingsverschillen en een echte technische storing, wat lastig is zonder de cijfers rechtstreeks te controleren.

Om dit te diagnosticeren, begin je met dezelfde twee controles: open de GTM-previewmodus en controleer of het `user_data`-object in de conversietag daadwerkelijk gehasht waarden bevat, en geen leeg object is. Controleer vervolgens het netwerkverzoek zelf op de `em`-parameter. Als die ontbreekt, is de tag niet geconfigureerd om deze te verzenden. Als hij wel aanwezig is, maar er staat bijvoorbeeld tv.1~em. zonder iets erachter, dan wordt het veld leeg geactiveerd. Hoe dan ook, de oplossing zit in GTM, niet in het instellingenscherm van Google Ads.

Hoe GTM server-side Google Enhanced Conversions betrouwbaarder maakt

De meeste van de bovenstaande storingspunten hebben iets gemeen: ze doen zich voor in de browser, waar de tag afhankelijk is van de DOM van de pagina, van het feit dat de dataLayer correct wordt gevuld, en van het feit dat er niets het verzoek onderschept voordat het de browser verlaat. Door de opzet te verplaatsen naar GTM server-side worden niet alle storingsmogelijkheden weggenomen, maar worden er wel een aantal geëlimineerd doordat de plek waar het werk gebeurt, verandert.

Als er een servercontainer is, wordt de taak van de browser een stuk eenvoudiger. Die stuurt het event (met de ruwe gebruikersgegevens) naar je eigen first-party-eindpunt. De servercontainer, en niet een tag aan de browserkant, bouwt het user_data-object op, past de hashing toe en stuurt het verzoek door naar Google. Die ene wijziging lost het probleem van dubbele hashing volledig op, omdat de hashing-logica nu op één plek zit in plaats van verdeeld te zijn over de pagina en de tag.

Het neemt ook het risico van adblockers weg. Een Enhanced Conversions-tag aan de browserzijde verstuurt zijn verzoek vanuit de browser van de gebruiker, wat betekent dat een adblocker of trackingbeveiliging het kan onderscheppen of negeren voordat Google het überhaupt te zien krijgt. De tag kan perfect zijn geconfigureerd en toch gegevens kwijtraken door iets waar je totaal geen controle over hebt. Een server-naar-server-verzoek van je container naar de API van Google loopt dat risico niet, omdat er in de browser niets is dat een adblocker kan onderscheppen.

Let op: de server-side hop helpt alleen als het traject van de browser naar de server zelf al veerkrachtig is. Zorg ervoor dat je het Enhanced Tracking Script van TAGGRS gebruikt, zodat dat eerste verzoek volledig onzichtbaar blijft voor adblockers. Anders verschuift hetzelfde risico op onderschepping gewoon een stapje eerder in de keten.

Dit alles neemt niet weg dat je de instellingen wel goed moet configureren. Een server-side instelling met een leeg user_data-veld blijft gewoon een leeg user_data-veld. Maar het zorgt er wel voor dat er minder plekken zijn waar een werkende configuratie plotseling niet meer werkt zonder dat er een foutmelding verschijnt – en dat is precies het soort fout dat je moeilijk opmerkt als je er niet actief naar op zoek bent. Voor bureaus die meerdere klantaccounts beheren, stapelt dat verschil in betrouwbaarheid zich snel op – minder stille storingen betekent minder audits, minder hiaten in de attributiegegevens en minder gesprekken waarin je klanten moet uitleggen waarom hun conversiecijfers niet kloppen met de werkelijkheid.

• Voor het volledige installatiepad, inclusief de configuratie op veldniveau voor Google Ads via server-side GTM, kun je de documentatie over het instellen van Enhanced Conversions en het overzicht van server-side tracking voor Google Ads raadplegen.
• Als je naast ‘Enhanced Conversions for Leads’ ook offline conversies uit een CRM verwerkt, vind je in de documentatie over de offline conversietag informatie over die specifieke instelling. En in dit artikel over het aantonen van de werkelijke ROAS van offline conversies lees je waarom die gegevens belangrijk zijn voor rapportages die verder gaan dan alleen Smart Bidding.

Google Enhanced Conversions en de AVG: wat EU-instanties moeten weten

Enhanced Conversions verstuurt persoonsgegevens, en hashing verandert niets aan die classificatie volgens de AVG. Een SHA-256-hash van een e-mailadres is gepseudonimiseerde data, geen geanonimiseerde data, omdat Google (de ontvanger) deze kan vergelijken met gegevens die het al in bezit heeft en zo de persoon erachter weer kan identificeren. Dat onderscheid is belangrijk: gepseudonimiseerde gegevens vallen nog steeds volledig onder de AVG, met alle bijbehorende verplichtingen op het gebied van rechtsgrondslag, toestemming en rechten van de betrokkene.

In de praktijk betekent dit dat Google Enhanced Conversions het toestemmingssignaal `ad_user_data` uit Consent Mode V2 nodig heeft voordat het wordt geactiveerd. Als een gebruiker die toestemming weigert, neemt de Google-tag de gehasht gegevens helemaal niet op in de conversie-hit. Dit is zo bedoeld, geen bug, en het is het juiste, aan de regels conforme gedrag. Het modelleren van geaggregeerde conversies geldt nog steeds voor gebruikers die geen toestemming geven.

Voor EU-bedrijven is het praktische risico meestal niet Enhanced Conversions zelf. Het gaat om situaties waarin ad_storage is toegestaan, maar ad_user_data nooit expliciet is ingesteld. Daardoor werkt de toestemmingsbanner technisch gezien wel, maar is het onderliggende signaal dat Google daadwerkelijk controleert voor Enhanced Conversions nooit aangesloten. De tag wordt geactiveerd, de gegevens worden verzonden, maar er is geen toestemmingsrecord dat dit ondersteunt. Dat is een nalevingslek dat niet naar voren komt in een match rate-rapport, omdat het er vanuit Google’s perspectief uitziet alsof alles werkt. Dit soort dingen ontdek je alleen als je ernaar op zoek gaat, en het is lastig en duur om achteraf uit te leggen.

GTM aan de server-side maakt de toestemmingsvereiste niet overbodig, en dat zou ook niet moeten. Wat het wel doet, is de plek waar de toestemming wordt gecontroleerd centraliseren. In plaats van te vertrouwen op meerdere tags aan de server-side die elk de toestemmingsstatus correct moeten respecteren, kan de servercontainer de volledige gebruikersgegevens op één plek controleren voordat er iets naar Google, Meta of een ander platform wordt gestuurd.

Voor een volledig overzicht van toestemmingssignalen en tracking aan de server-side kun je de gids over de AVG en tracking aan de server-side raadplegen.

Waar TAGGRS past

Het controleren van ‘Enhanced Conversions’ voor alle klantaccounts na een Google-update is voor de meeste bureaus geen haalbare werkwijze. Niemand heeft de tijd om de GTM-previewmodus voor vijftig accounts te openen telkens als Google iets verandert.

TAGGRS voert Enhanced Conversions uit via dezelfde server-side GTM-container die ook de rest van de tracking voor een account regelt. Omdat het hashen en het samenstellen van de `user_data` server-side gebeurt in plaats van via een wirwar van browsertags, zijn er minder plekken waar een stille fout – zoals een lege payload of een veld dat dubbel is gehasht – ongemerkt kan binnensluipen.

Ook de toestemmingscontrole gebeurt op één plek. In plaats van te controleren of elke tag aan de server-side op de site van een klant de `ad_user_data`-instelling correct respecteert, zorgt de servercontainer er centraal voor dat dit gebeurt, voordat er gebruikersgegevens naar Google, Meta of een ander platform worden verzonden.

Voor teams die al Google Ads-tracking via TAGGRS gebruiken, maken Enhanced Conversions deel uit van dezelfde pijplijn als alle andere conversieevents. Je kunt ze volgen via de centrale analysedashboards in je TAGGRS-account.

Conclusie

Door de update van juni 2026 is het makkelijker geworden om Enhanced Conversions in te schakelen, maar ook om het te vergeten. Dat is het risico dat schuilgaat achter een vereenvoudiging: minder instellingen om bij te houden betekent ook minder zichtbare herinneringen om te controleren of wat je maanden geleden hebt ingesteld nog steeds goed werkt.

Een configuratie die er in Google Ads actief uitziet, kan toch geen bruikbare gegevens versturen. De enige manier om daar achter te komen, is door het diagnostische rapport en het daadwerkelijke netwerkverzoek te controleren, en niet alleen de schakelaar. En als het doel is om het aantal plekken waar die fout überhaupt kan optreden te verminderen, dan zorgt het verplaatsen van de configuratie naar de server-side ervoor dat de meeste browser-afhankelijke punten waar het vaak misgaat, worden weggenomen.

Het controleren van verbeterde conversies voor al je klantaccounts is precies het soort werk waarvoor een server-side opzet bedoeld is om je tijd te besparen. Je kunt een gratis TAGGRS-account aanmaken om aan de slag te gaan, of de installatiehandleidingen doornemen als je liever eerst wilt zien hoe het werkt.

FAQ

Wat is er veranderd met de update ‘Enhanced Conversions’ van juni 2026?

Google heeft ‘Enhanced Conversions for Web’ en ‘Enhanced Conversions for Leads’ samengevoegd tot één aan/uit-schakelaar en het scherm verwijderd waarin adverteerders een implementatiemethode konden kiezen. Bestaande accounts die de voorwaarden van Google voor klantgegevens al hadden geaccepteerd, zijn automatisch gemigreerd. Het onderliggende hashing- en matchingmechanisme is niet veranderd.

Waarom lijkt ‘Enhanced Conversions’ actief, maar werkt het eigenlijk niet?

Omdat de conversietag en de aanvullende gegevens twee aparte dingen zijn. De tag kan worden geactiveerd en de conversie kan normaal worden geregistreerd, terwijl het veld ‘user_data’ daarin leeg is, dubbel gehasht is of helemaal ontbreekt. Google Ads geeft de conversieactie in beide gevallen als actief weer, omdat de basisconversie nog steeds correct wordt bijgehouden.

Hoe kan ik controleren of mijn instellingen voor ‘Enhanced Conversions’ daadwerkelijk bruikbare gegevens doorgeven?

Open de GTM Preview-modus, voer een testconversie uit en controleer of het `user_data`-object gehashtte waarden bevat en niet leeg is. Kijk daarna in het netwerkverzoek of de `em`-parameter aanwezig is. Als die ontbreekt of leeg is, komen de uitgebreide gegevens niet bij Google terecht, zelfs als de basisconversie wel wordt bijgehouden.

Lost GTM aan de server-side alle problemen met Enhanced Conversions op?

Nee. Een verkeerd geconfigureerd veld blijft verkeerd geconfigureerd, ongeacht waar het hashen plaatsvindt. Wat GTM server-side wegneemt, zijn de browser-afhankelijke storingspunten: adblockers die het verzoek onderscheppen, CSS-selectors die niet meer werken na een herontwerp, en dubbel hashen als gevolg van logica die verdeeld is over de pagina en de tag.

Voldoet Enhanced Conversions na de update nog steeds aan de AVG?

Ja, en de vereiste is niet veranderd. Enhanced Conversions heeft nog steeds toestemming voor `ad_user_data` nodig, verleend via Consent Mode V2, voordat het gehashtte gegevens kan versturen. Hashing maakt de gegevens niet anoniem volgens de AVG, omdat Google ze nog steeds kan koppelen aan accountgegevens die het in bezit heeft.

Moet ik mijn instellingen voor ‘Enhanced Conversions’ opnieuw instellen vanwege de samenvoeging?

Niet per se. Als je account de voorwaarden voor klantgegevens al had geaccepteerd, is de migratie automatisch gebeurd. Het is toch de moeite waard om het diagnostische rapport te bekijken, want de samenvoeging is een goede aanleiding om een configuratie op te sporen die al vóór de update niet goed werkte, maar waar niemand iets van had gemerkt.