HubSpot-tracking aan de server-side: complete installatiehandleiding

Als je je marketing of verkoop via HubSpot regelt, zijn je leadgegevens maar zo goed als de tracking die ervoor zorgt dat ze binnenkomen. En die tracking heeft een probleem: de browser werkt er tegen.

Het begint met één cookie. De standaard trackingcode van HubSpot plaatst een cookie met de naam hubspotutk om terugkerende bezoekers te herkennen en het traject van een contactpersoon in kaart te brengen nog voordat ze een formulier invullen. De Intelligent Tracking Prevention van Safari beperkt de geldigheidsduur van die cookie tot zeven dagen als deze via JavaScript wordt geplaatst, en dat is precies hoe HubSpot het standaard instelt. Adblockers en de strenge privacy-instellingen in Firefox, Edge en Safari gaan nog een stap verder. Ze blokkeren het HubSpot-script en de daarin ingebedde formulieren volledig, waardoor er soms niets anders overblijft dan een lege plek waar je leadformulier vroeger stond.

Dit is geen toekomstig risico. Het gebeurt nu al op je site, en het is een belangrijke reden waarom de rapporten van HubSpot over ‘Original Source’ en multi-touch-attributie verder van de werkelijkheid afwijken dan de meeste teams beseffen.

HubSpot server-side Tracking pakt de oorzaak aan. In plaats van dat de browser rechtstreeks de eindpunten js.hs-scripts.com en hsforms.net van HubSpot aanroept, doet je eigen server dat namens de contactpersoon. In deze handleiding leggen we je uit hoe je server-side tracking voor HubSpot instelt met behulp van Google Tag Manager en TAGGRS.

Voordelen van server-side tracking met HubSpot

Bij tracking aan de clientzijde draait het HubSpot-script in de browser van de bezoeker. Het haalt de benodigde gegevens uit de pagina, plaatst de cookies ‘hubspotutk’ en ‘__hstc’, en neemt rechtstreeks contact op met de servers van HubSpot om paginaweergaven te registreren, bezoekers te identificeren en formulieren in te dienen.

Bij server-side tracking wordt die verbinding naar je eigen server verplaatst. De browser stuurt één verzoek naar je domein (via een Google Tag Manager-servercontainer), en jouw server stuurt de relevante gegevens door naar de API van HubSpot via een beveiligde, geauthenticeerde verbinding. De browser van de bezoeker heeft helemaal geen contact met de domeinen van HubSpot.

De server-side tegenhangers van het client-side script van HubSpot zijn de CRM Objects API voor contacten en de Custom Behavioral Events API voor al het andere: pagina-interacties, productweergaven, het versturen van aangepaste formulieren, alles wat je maar aan een contactrecord wilt koppelen.

Simpel gezegd: alles wat het HubSpot-script nu in de browser doet, heeft een tegenhanger aan de server-side. Je verliest dus geen functionaliteit door het te verplaatsen; je verandert alleen maar waar het werk plaatsvindt. Voor een marketingteam betekent dit in de praktijk dat de gegevens voor je lijsten, workflows en rapporten vollediger binnenkomen en niet meer afhankelijk zijn van de vraag of de browser van elke bezoeker meewerkt.

Tracking aan de server-side is vooral de moeite waard als je je beslissingen in HubSpot neemt: leads scoren, workflows activeren, attributie rapporteren aan het management of je advertentie-uitgaven optimaliseren op basis van contact- en dealgegevens. Hoe meer waarde je aan die gegevens hecht, hoe duurder die hiaten je komen te staan.

Ben je nog niet gewend aan het werken met Google Tag Manager? TAGGRS heeft handleidingen waarin de basisbeginselen worden behandeld, voordat je specifiek met HubSpot aan de slag gaat:

Waarom tracking aan de clientzijde op dit moment onbetrouwbaar is voor HubSpot-gebruikers

Dit is geen algemene opmerking in de trant van „browsers zijn tegenwoordig streng”. Een paar specifieke, recente wijzigingen hebben direct invloed op de tracking van HubSpot, en elke wijziging heeft betrekking op een rapport of een workflow waar je al op vertrouwt. Hieronder lees je wat de tracking van HubSpot aan de clientzijde verstoort, en wat elke storing je kost.

De trackingcookie heeft een limiet, en het is degene waar HubSpot het meest op vertrouwt. hubspotutk wordt via document.cookie geplaatst, en de eigen regels van WebKit om tracking te voorkomen verwijderen elke cookie die op die manier is geplaatst na zeven dagen zonder bezoek.

De limiet wordt specifiek teruggebracht naar 24 uur wanneer een bezoeker op je site terechtkomt via een domein dat Safari heeft aangemerkt als een cross-site tracker, via een link met queryparameters – precies het patroon dat ten grondslag ligt aan de meeste klikken op betaalde advertenties. Een potentiële klant die twee weken voordat hij een formulier invult eerst wat onderzoek doet, wordt bij zijn uiteindelijke conversie geregistreerd als een nieuwe, eerste bezoeker, omdat de cookie die zijn eerdere sessies aan elkaar koppelde al dagen eerder was verlopen.

Bij een weloverwogen aankoop met een onderzoekscyclus van meerdere weken is dit de norm. Het kanaal dat die potentiële klant als eerste binnenhaalde (vaak een duur kanaal zoals betaalde zoekresultaten of een webinar) krijgt geen erkenning, terwijl wat ze op de dag van de conversie in de adresbalk typten (meestal ‘direct’) met alle eer gaat strijken. Vermenigvuldig dat eens met een heel kwartaal en je ‘Original Source’-rapport geeft te veel gewicht aan ‘direct’ en ‘organisch’, terwijl de campagnes die het werk hebben gedaan, te kort komen.

Adblockers en functies die tracking door browsers tegengaan, blokkeren het script, niet alleen de cookie. Op het communityforum van HubSpot staan meerdere discussies hierover: de Enhanced Tracking Protection van Firefox en de strikte Tracking Prevention van Edge blokkeren verzoeken aan hsforms.net, waardoor hbspt.forms.create() nooit wordt uitgevoerd en bezoekers een leeg vakje zien waar het formulier zou moeten staan. Geen foutmelding, geen alternatief. De bezoeker vertrekt meestal gewoon, en je weet nooit dat die lead er was.

De blokkering op browserniveau van Apple wordt uitgebreid. Safari 27 voegt blokkering van IP-reeksen toe op netwerkniveau en zet CDP’s zoals Segment en Tealium op de lijst met fingerprinting-scripts. Als je tracking naar HubSpot via een CDP laat lopen, of via een scripttag die Safari als fingerprinting-tool classificeert, kan de toegang tot verwijzingsgegevens en queryparameters verloren gaan nog voordat de data HubSpot bereikt.

Met andere woorden: de gegevens over „waar deze lead vandaan kwam” worden al in de browser verwijderd voordat HubSpot ze te zien krijgt. Aangezien ongeveer een op de vier bezoekers op Safari surft, is dat een groot, groeiend en specifiek zeer geïnteresseerd deel van je publiek dat onzichtbaar wordt – precies de kopers van Apple-apparaten die veel B2B- en premiummerken het liefst willen toewijzen.

Het gebruik van adblockers is geen nicheprobleem meer. Ongeveer een derde van de internetgebruikers gebruikt een of andere vorm van adblocker, en dat aantal blijft maar stijgen. Kortom: een flink deel van je bezoekers laat het HubSpot-script helemaal niet laden.

Hoe tracking aan de klantzijde de attributie- en leadgegevens van HubSpot verstoort

De gevolgen merk je terug in de functies die je daadwerkelijk gebruikt om campagnes te voeren.

De ‘Oorspronkelijke’ en ‘Laatste’ verkeersbron worden bepaald op basis van de sessiegeschiedenis van de trackingcookie. HubSpot probeert een nieuw contactrecord te koppelen aan anonieme activiteiten die onder de cookie van die bezoeker zijn bijgehouden. Als de cookie vroegtijdig wordt gereset, is die eerdere activiteit verdwenen, waardoor HubSpot niets heeft om mee te vergelijken. Daarom stelt HubSpot de ‘Oorspronkelijke bron’ in op basis van de sessie die toevallig actief is op het moment dat het contactrecord wordt aangemaakt, en niet op basis van het daadwerkelijke eerste bezoek van de bezoeker.

Attributierapporten waarin een kanaal wordt gecrediteerd voor het genereren van een contact of een deal, zijn gebaseerd op dezelfde interactiegeschiedenis. Als er minder paginaweergaven en touchpoints worden bijgehouden, leidt dat tot een vlakker, minder bruikbaar attributiebeeld. Je marketing is niet gestopt met werken. HubSpot ziet het gewoon niet meer.

Aangepaste gedragsevents en e-commerce-events die via client-side JavaScript worden geactiveerd, hebben allemaal met deze problemen te maken. Als het script wordt geblokkeerd, wordt het event nooit geactiveerd. Elke workflow of leadscore die op dat event is gebaseerd, blijft gewoon stilhangen, zonder dat er iets gebeurt, en zonder dat er een foutmelding verschijnt die je vertelt waarom.

Eén ding werkt nog steeds, zelfs als de cookie geblokkeerd is: de formulieren van HubSpot kunnen op het moment van verzending de UTM-parameters rechtstreeks uit de URL van de huidige pagina halen, dus de attributie op campagneniveau voor die specifieke verzending blijft meestal wel behouden. Wat niet behouden blijft, is alles wat afhankelijk is van het koppelen van die verzending aan eerdere sessies van de bezoeker die via cookies werden bijgehouden.

Wat HubSpot-gebruikers aan server-side tracking hebben

Server-side tracking verandert wat je in HubSpot kunt vertrouwen. Dit zijn de verbeteringen zodra de verbinding naar je eigen server wordt verplaatst:

- Formulieren die daadwerkelijk laden; dat heeft de meest directe invloed op je inkomsten van alles op deze lijst. Een geblokkeerd formulier is een lead die je nooit te zien krijgt en waarvoor je nooit twee keer betaald hebt om hem binnen te halen. Een formulierverzoek dat vanaf je eigen domein wordt aangeboden, via je servercontainer, staat niet op dezelfde blokkeerlijsten als hsforms.net, dus bezoekers met strenge privacy-instellingen of adblockers zien het nog steeds en kunnen het invullen.

- Een trackingcookie die langer dan een week blijft staan. Cookies die via een HTTP-responsheader worden geplaatst, vallen niet onder de JavaScript-limiet van zeven dagen die Safari hanteert voor hubspotutk, maar alleen als je server de aparte CNAME- en IP-adresmaskering van WebKit weet te omzeilen. Die zorgt er namelijk voor dat ook via HTTP geplaatste cookies na zeven dagen worden gewist als het systeem in werking treedt.

Of je hier optimaal van kunt profiteren, hangt ervan af of je server op een echt first-party subdomein staat met een IP-bereik dat overeenkomt met dat van je hoofdsite. Dit wordt behandeld in het gedeelte over de installatie hieronder. De meest betrouwbare manier om die overeenkomst te garanderen, is door je servercontainer via een Cloudflare Worker te routeren die dezelfde oorsprong heeft als je hoofdsite, bijvoorbeeld via een pad als yourdomain.com/metrics in plaats van een apart subdomein. De IP-overeenkomstcontrole van Safari is namelijk helemaal niet van toepassing als alles daadwerkelijk dezelfde oorsprong heeft.

- Attributie die laat zien wat er echt gebeurt. Er vallen onderweg minder sessies weg, waardoor de rapporten over ‘Original Source’, ‘Latest Source’ en multi-touch dichter bij de werkelijkheid komen. Dat is vooral belangrijk als je je budget moet bepalen: als je attributie de betaalde of organische leads te laag inschat, leidt dat ertoe dat je juist de kanalen schrapt die wel werken.

- Betrouwbare aangepaste gedragsgebeurtenissen. Door events aan de server-side via de API van HubSpot te versturen, heeft een adblocker bij de bezoeker geen invloed op of het event HubSpot bereikt.

- Meer controle over wat je verstuurt. Je bepaalt zelf precies welke velden naar HubSpot worden doorgestuurd en wanneer, waardoor het minimaliseren van gegevens en het naleven van toestemmingsregels een kwestie van instellingen wordt in plaats van giswerk.

- Een lichtere pagina. Als er minder scripts aan de clientzijde zijn die om de hoofdthread strijden, heeft dat minder invloed op de laadtijd, en dat is belangrijk voor zowel de conversieratio als de Core Web Vitals.

Alles bij elkaar zorgen deze ervoor dat er meer van de leads die je nu al binnenhaalt, in HubSpot terechtkomen: correct toegewezen en klaar om te worden verwerkt in je workflows en rapporten.

Wat je nodig hebt voordat je begint

Voor het instellen van server-side tracking voor HubSpot hoef je niets opnieuw op te zetten. Het meeste hoef je maar één keer te doen, en een aantal dingen heb je misschien al als je GA4 server-side gebruikt.

Hier is de volledige checklist voordat je HubSpot-tags gaat aanmaken:

• Een Google Tag Manager-account met een webcontainer en een servercontainer. Als je nog niet bekend bent met GTM, begin dan met de beginnershandleiding.
  
• Een werkende gegevenslaag op je site, of op zijn minst een GA4-configuratietag die basisgegevens over pagina’s en events doorstuurt naar je servercontainer. In de handleiding voor server-side installatie van TAGGRS wordt stap voor stap uitgelegd hoe je die verbinding aan de praat krijgt, aangezien de meeste HubSpot-tags in de servercontainer afhankelijk zijn van gegevens die al via deze route binnenkomen.
  
• Een TAGGRS-servercontainer, geïmplementeerd met een eigen subdomein op je eigen domein. Maak een gratis account aan om aan de slag te gaan; het gratis pakket dekt tot 10.000 verzoeken per maand, wat genoeg is voor de meeste eerste installaties.
  
• Een toegangstoken voor een HubSpot Private App. HubSpot heeft zijn oude API-sleutels op 30 november 2022 buiten gebruik gesteld. Maak een privé-app aan via Instellingen > Integraties > Privé-apps, en geef deze alleen de scopes die je echt nodig hebt: crm.objects.contacts.write en crm.objects.contacts.read voor contactrecords, plus analytics.behavioral_events.send als je aangepaste gedragsgebeurtenissen verstuurt. Als je ook gebeurtenisdefinities via de API wilt aanmaken of bewerken in plaats van via de gebruikersinterface, dan is dat een aparte scope: behavioral_events.event_definitions.read_write. In de handleiding voor privé-apps van HubSpot staan de exacte stappen beschreven. Kopieer het token zodra het is gegenereerd. HubSpot laat je de volledige waarde daarna niet meer zien.
  
• Als je aangepaste gedragsgebeurtenissen verstuurt, moet je de gebeurtenisdefinities eerst in HubSpot aanmaken. HubSpot moet de gebeurtenis en de bijbehorende eigenschappen eerst gedefinieerd hebben voordat het een via de API verzonden gebeurtenis accepteert. Je kunt dit doen via Gegevensbeheer > t Gebeurtenisbeheer in de gebruikersinterface, of via de API voor gebeurtenisdefinities als je het liever via een script wilt doen.
  
• Een instelling voor toestemming die je servercontainer omvat, niet alleen de eigen banner van HubSpot. De ingebouwde toestemmingsbanner van HubSpot blokkeert alleen HubSpot-cookies en HubSpot-eigen integraties. Deze heeft geen zicht op een aangepaste GTM-servercontainer, dus je hebt je platform voor toestemmingsbeheer nodig om het signaal rechtstreeks naar GTM door te sturen. Zowel de instellingen voor de Consent Mode van TAGGRS als de integratiehandleiding voor CookieConfirm laten zien hoe die koppeling in de praktijk werkt.

Stap voor stap: HubSpot-tracking aan de server-side instellen met Google Tag Manager

Hier is de volledige opzet, van begin tot eind:

1. Zet je TAGGRS-servercontainer in en koppel deze aan een subdomein van je eigen domein (bijvoorbeeld measure.jouwdomein.com). Hierdoor worden cookies die door je server worden geplaatst beschouwd als first-party cookies in plaats van third-party cookies.

2. Controleer of je gegevenslaag de gegevens doorstuurt naar de servercontainer. Bij de meeste opstellingen gebeurt dit door een GA4-configuratieevent vanuit de webcontainer te versturen; de servercontainer heeft dan toegang tot dezelfde eventgegevens voor elke tag die je daarop bouwt, inclusief HubSpot.

3. Maak je HubSpot Private App aan en kopieer het toegangstoken. Sla het op als een server-side GTM-variabele, en niet als een vast ingestelde waarde in een tag, zodat je het later kunt aanpassen zonder elke tag te hoeven bewerken die er gebruik van maakt.

4. Voeg een tag toe aan je servercontainer die de API van HubSpot aanroept. Zoek eerst in de Community Template Gallery van Google Tag Manager naar een bestaande HubSpot-servertag.

5. Stel de tag ‘Contact aanmaken of bijwerken’ in. Dit is de functie die ervoor zorgt dat een ingevuld formulier wordt omgezet in een contactrecord. Zorg er in ieder geval voor dat je een variabele voor het e-mailadres van het contact uit je gegevenslaag koppelt aan het verzoek, want HubSpot gebruikt het e-mailadres om te bepalen of er een nieuw contact moet worden aangemaakt of dat een bestaand contact moet worden bijgewerkt.

Voeg vervolgens alle aangepaste eigenschappen toe die je wilt bijhouden (details over de leadbron, paginapad, formuliernaam) als extra velden in dezelfde verzoektekst. Wat je hier toewijst, is wat je verkoopteam en je rapporten te zien krijgen, dus het loont de moeite om wat meer dan het absolute minimum toe te wijzen nu je er toch mee bezig bent.

6. Stel het bijhouden van aangepaste gedragsevents in, als je dat nodig hebt. Koppel de naam van het event en de bijbehorende eigenschappen zo dat ze precies overeenkomen met wat je in HubSpot hebt gedefinieerd in de bovenstaande instellingsstap. De namen moeten overeenkomen met de interne naam die HubSpot heeft gegenereerd, niet met het weergavelabel, anders wordt het event afgewezen.

7. Voeg triggers toe voor elke tag. Een ‘contact-create’-tag wordt meestal geactiveerd bij het verzenden van een formulier, wat al in je datalaag is vastgelegd. Een gedragsgebeurtenistag wordt geactiveerd bij elke aangepaste gebeurtenis die je bijhoudt (zoals het bekijken van een prijspagina, het volledig afkijken van een video of het toevoegen van een artikel aan het winkelmandje via een met HubSpot gekoppelde e-commerce-integratie).

8. Test alles in de GTM-previewmodus, waarbij de preview tegelijkertijd actief is in zowel de web- als de servercontainer. In de testgids van TAGGRS wordt uitgelegd hoe je de verzoekstroom tussen beide kunt volgen. Vul een echt testformulier in en controleer of het contact in HubSpot verschijnt (of wordt bijgewerkt). Activeer vervolgens een testgedragsevenement en kijk of dit op de tijdlijn van het contact verschijnt.

9. Laat de nieuwe configuratie een tijdje naast je bestaande HubSpot-trackingcode draaien, in plaats van deze meteen te verwijderen. Zo kun je het aantal aangemaakte contacten en het aantal events vergelijken voordat je volledig overschakelt, en ben je ingedekt als er iets in de nieuwe configuratie verkeerd is ingesteld.

10. Zet je server en webcontainers live zodra de tests goed lijken te verlopen.

Zodra de wijziging is gepubliceerd, is deze meteen zichtbaar voor alle bezoekers en worden de gegevens vanaf de volgende formulierinzending via je eigen domein doorgestuurd. Vanaf dat moment hoef je alleen nog maar de tags en toestemmingsregels bij te houden. Je hoeft niet meer telkens een script aan de clientzijde te repareren als een browser zijn privacyregels aanpast.

Veelgemaakte fouten die je moet vermijden

Als er iets misgaat met de server-side HubSpot-configuratie, krijg je meestal geen foutmelding. De tags lijken wel te werken, maar de gegevens komen niet bij HubSpot aan of worden verkeerd doorgegeven, waardoor het probleem vaak onopgemerkt blijft totdat je merkt dat er iets niet klopt in een rapport. Dit zijn de fouten die dit het vaakst veroorzaken:

• Aangepaste gedragsevents versturen voordat je ze in HubSpot hebt gedefinieerd. HubSpot wijst elke gebeurtenis af die het nog niet herkent, dus de tag wordt wel geactiveerd, maar er wordt niets geregistreerd en er is geen duidelijke foutmelding die je naar de oorzaak leidt. Definieer de gebeurtenis en de bijbehorende eigenschappen altijd eerst in HubSpot.
• Ontbrekende of verkeerde scopes op het Private App-token. Een token zonder de juiste scope geeft geen duidelijke foutmelding. De tag wordt weergegeven als "fired", terwijl HubSpot het verzoek stilletjes afwijst, waardoor contacten of events nooit verschijnen. Controleer de daadwerkelijke responscode in de previewmodus van de servercontainer in plaats van af te gaan op de status "fired".
• Er is geen e-mailadres van de bezoeker beschikbaar op het moment dat de tag wordt geactiveerd. Aan de hand van het e-mailadres bepaalt HubSpot of een bestaand contact wordt bijgewerkt of dat er een nieuw contact wordt aangemaakt. Zonder dat e-mailadres mislukt de bewerking of ontstaat er een dubbel contact zonder dat er iets is om het mee te vergelijken, waardoor je database na verloop van tijd stilletjes vol raakt met rommel. Zorg ervoor dat de e-mailvariabele is ingevuld voordat de tag wordt uitgevoerd.
• Oude en nieuwe tracking naast elkaar draaien zonder plan om op te ruimen. Het is slim om beide een paar weken naast elkaar te laten draaien om te vergelijken, maar als beide programma’s eindeloos contacten en events blijven aanmaken, ga je dubbel tellen en worden alle rapporten die op die gegevens zijn gebaseerd, opgeblazen. Bepaal van tevoren welke opzet je als ‘bron van de waarheid’ beschouwt, en schakel de andere uit zodra je de cijfers vertrouwt.
• Ervan uitgaande dat de server-side cookie automatisch de limiet van zeven dagen overschrijdt. Dat werkt alleen als je subdomein niet (via DNS CNAME) naar een domein van een derde partij verwijst en het IP-bereik van je server overeenkomt met dat van je hoofdsite. Voldoe je aan één van deze voorwaarden niet, dan past Safari weer dezelfde limiet van zeven dagen toe die je server-side had omzeild, waardoor je wel al het installatiewerk hebt, maar geen enkel voordeel op het gebied van attributie. Routeren via een Cloudflare Workers-configuratie met dezelfde oorsprong is de meest betrouwbare manier om de overeenkomst te garanderen.
• Het doorgeven van persoonsgegevens voordat er toestemming is gevraagd. Met server-side heb je meer controle over wat je verstuurt, maar alleen als je de toestemmingscontrole ook daadwerkelijk in de triggervoorwaarden van elke tag inbouwt. De architectuur dwingt de toestemming niet voor je af, en als je ervan uitgaat dat dit wel zo is, verandert een privacyveilige opzet stilletjes in een opzet die niet aan de regels voldoet.
• Geen gegevenslaag, of een inconsistente. Elke tag hier is afhankelijk van gegevens die in een voorspelbare vorm bij de servercontainer binnenkomen. Als de namen van events of parametersleutels per pagina verschillen, stoppen tags zomaar met werken zonder duidelijke reden, en zit je vervolgens de tag te debuggen terwijl het echte probleem verderop in het proces zit. Zorg eerst voor een consistente naamgeving voordat je erop voortbouwt.

Extra tools die de moeite waard zijn om te combineren met je HubSpot-opstelling

Als je leads via Google Ads binnenkomen, beschermt deze functie direct je advertentierapportage. De GCLID is de tag die Google gebruikt om een klik aan een conversie te koppelen, en als Safari die uit de URL verwijdert, kan Google Ads niet zien welke klikken tot klanten hebben geleid. Daardoor ziet je ROAS er slechter uit dan hij in werkelijkheid is, en optimaliseert het algoritme op basis van verkeerde gegevens. Click ID Recovery herstelt de GCLID-waarden die Safari uit URL’s verwijdert, nog voordat ze je formulier bereiken.

HubSpot registreert GCLID standaard niet. Je hebt een aangepaste contact-eigenschap nodig met dezelfde naam als de URL-parameter, die je als verborgen veld aan je formulier toevoegt. De ingebouwde functie van HubSpot voor het matchen van verborgen velden vult deze dan automatisch in wanneer een bezoeker met die parameter in de URL op je site terechtkomt. Zodra dat geregeld is, legt onze handleiding voor het verhelpen van onnauwkeurigheden in GA4 ROAS uit hoe de opgeslagen GCLID wordt omgezet in een offline conversie zodra een deal wordt gesloten, en onze handleiding over Enhanced Conversions gaat dieper in op het uploaden ervan.

Het Enhanced Tracking Script maskeert en versleutelt het verzoek tussen de browser en de server, waardoor meer events de patroonherkenning van adblockers kunnen omzeilen nog voordat ze je servercontainer bereiken.

Als je bezoekers uit de EU bedient, combineer deze opzet dan met Consent Mode V2, zodat de toestemmingssignalen samen met de gegevens helemaal naar HubSpot worden gestuurd, en niet alleen naar de tags van Google. In ons AVG-overzicht voor tracking server-side vind je meer informatie over wat daarvoor in de praktijk nodig is.

Conclusie

De client-side tracking van HubSpot is ontwikkeld voor een browserwereld die eigenlijk niet meer bestaat. Tussen de cookie-limiet van zeven dagen in Safari, adblockers die het script helemaal verwijderen en browsers die steeds meer onderdelen van de marketingstack als een risico op fingerprinting classificeren, betekent vertrouwen op de browser alleen dat je contacten kwijtraakt, de contacten die je wel behoudt verkeerd toewijst en events mist die je leadscores zouden moeten voeden.

Door die verbinding server-side te verplaatsen, via Google Tag Manager en TAGGRS, wordt het verzoek op je eigen domein geplaatst in plaats van dat van HubSpot, waar adblockers en instellingen voor het blokkeren van tracking niets hebben om op te reageren. Je hebt zo ook zelf de controle over wat er naar HubSpot wordt gestuurd en wanneer, wat het privacyaspect juist makkelijker maakt, niet moeilijker.

Klaar om aan de slag te gaan? Maak een gratis TAGGRS-account aan of boek een demo om je specifieke HubSpot-configuratie door te nemen.

FAQ

Wat is server-side tracking voor HubSpot?

Server-side tracking voor HubSpot houdt in dat de gegevens die normaal gesproken rechtstreeks vanuit de browser van een bezoeker naar de servers van HubSpot zouden gaan, eerst via je eigen server worden geleid. In plaats van dat het HubSpot-script rechtstreeks js.hs-scripts.com of hsforms.net aanroept, ontvangt jouw server de gebeurtenis en stuurt deze via een geauthenticeerde verbinding door naar de CRM- en Events-API’s van HubSpot. Het resultaat is dat de gegevens HubSpot bereiken, zelfs als adblockers of privacy-instellingen van de browser het standaard client-side script zouden hebben geblokkeerd.

Ondersteunt HubSpot server-side tracking standaard?

Niet zoals de meeste mensen het bedoelen. De eigen trackingcode, formulieren en toestemmingsbanner van HubSpot zijn allemaal standaard client-side, en de ingebouwde integraties synchroniseren via de CRM-API in plaats van via een server-side tagmanager. Om echt server-side tracking te krijgen, combineren de meeste teams een Google Tag Manager-servercontainer met de Private App-toegangstokens van HubSpot en de CRM Objects- en Custom Behavioral Events-API’s, waarbij ze een hostingprovider zoals TAGGRS gebruiken om de servercontainer te draaien.

Wat voor invloed heeft dit op de toewijzing van leads en contacten in HubSpot?

Over het algemeen wordt het er beter van. De rapporten ‘Original Source’, ‘Latest Source’ en de attributierapporten van HubSpot zijn afhankelijk van een trackingcookie die tijdens alle sessies van een bezoeker bewaard blijft. Als die cookie door Safari’s ITP wordt beperkt tot zeven dagen, of helemaal wordt geblokkeerd door een adblocker, raakt HubSpot de draad kwijt tussen het eerste onderzoek van een bezoeker en het moment waarop hij uiteindelijk een formulier invult. Tracking aan de server-side, in combinatie met een goed geconfigureerd first-party subdomein, zorgt ervoor dat die identiteit langer behouden blijft. Daardoor worden meer contacten toegeschreven aan het kanaal dat ze daadwerkelijk heeft binnengehaald.

Voldoet server-side tracking voor HubSpot aan de AVG?

Ja, als het zo is ingesteld dat er rekening wordt gehouden met toestemming. Omdat de gegevens via je eigen server lopen voordat ze bij HubSpot terechtkomen, bepaal je zelf precies wat er wordt doorgestuurd. Daardoor is het makkelijker om gegevensminimalisatie toe te passen en de toestemmingsstatus van een bezoeker te controleren voordat er persoonlijke gegevens je server verlaten. De eigen toestemmingsbanner van HubSpot werkt niet in een aangepaste servercontainer, dus je hebt nog steeds je platform voor toestemmingsbeheer nodig om het signaal rechtstreeks door te sturen naar je Google Tag Manager-configuratie, zoals beschreven in het gedeelte over de installatie hierboven.

Moet je de standaard trackingcode van HubSpot verwijderen?

Niet meteen. Het is veiliger om beide een paar weken naast elkaar te laten draaien. Zo kun je het aanmaken van contacten, het aantal events en de attributie tussen de twee opstellingen vergelijken voordat je een definitieve keuze maakt. Zodra je de cijfers aan de server-side vertrouwt, kun je beslissen of je de code aan de clientkant helemaal verwijdert of een ingekorte versie ervan behoudt voor zaken als de HubSpot-chatwidget, die nog steeds afhankelijk is van het bezoekersidentificatietoken dat in de browser draait.