Wat server-side tagging doet¶

Bij klassieke tracking laadt je browser de scripts van de trackers zelf. Google Analytics, een advertentiepixel, een attributietag: elk daarvan opent een eigen verbinding vanaf jouw toestel naar de partij erachter. Die verbindingen zijn zichtbaar in het netwerkverkeer, want ze komen langs jouw apparaat.

Bij server-side tagging verandert dat. Je toestel stuurt nog maar naar één bestemming: een eigen verzamelpunt van de site. Dat is meestal een subdomein van de site zelf, zoiets als sgtm.voorbeeld.nl of metingen.voorbeeld.nl. Achter dat verzamelpunt draait een container, bijvoorbeeld een server-side Google Tag Manager. Die container ontvangt jouw gegevens en verdeelt ze vervolgens door naar de echte trackers. Die doorverdeling gebeurt van server naar server, buiten je toestel om. Wat je browser ziet, is één nette verbinding met de site zelf.

Dat is de kern van het mechanisme. De site verzamelt eerst op een eigen adres en distribueert daarna. De partij die uiteindelijk je gegevens krijgt, spreekt jouw toestel nooit rechtstreeks.

Waarom een browsermeting dit mist¶

Een meting in de browser ziet alleen wat langs jouw toestel komt. Dat is de fundamentele grens van de methode. Zodra het doorsturen op de server gebeurt, valt het buiten beeld. In een HAR-opname zie je één verbinding naar het eigen verzamelpunt en verder niets. De uiteindelijke ontvanger staat niet in de opname, want jouw toestel heeft die ontvanger nooit gesproken.

Dit heeft een scherpe consequentie voor bewijsvoering. De afwezigheid van een tracker-domein op de lijn bewijst niet dat de data er niet komt. Het draait de gebruikelijke logica om. Normaal geldt: zie ik een tracker, dan is er tracking. Bij server-side tagging geldt dat nog steeds, maar het omgekeerde vervalt. Zie ik geen tracker, dan weet ik niets over wat er op de server gebeurde. Een afwezigheid die vroeger geruststelde, zegt nu enkel dat het buiten mijn bereik lag. Een site kan er op een browsermeting volledig schoon uitzien terwijl er achter het verzamelpunt tien partijen worden gevoed. De meting toont wat zichtbaar overging. Wat op de server werd doorgezet, blijft onzichtbaar. Dat is geen tekortkoming die je met een betere browserscan oplost, want het verkeer bestaat simpelweg niet op het toestel.

Hoe je het herkent¶

Server-side tagging is niet volledig te doorgronden vanaf het toestel, maar de aanwezigheid ervan laat wel sporen na. Ik let op een paar signalen.

Een eerste signaal is één verzamelpunt op een eigen subdomein dat een verdachte hoeveelheid gestructureerde gebeurtenissen ontvangt. Een tweede signaal is dat dat subdomein via een CNAME naar de infrastructuur van een tracker of tagleverancier wijst. Dat is verwant aan CNAME-cloaking vermomt een derde partij als eigen subdomein, want het laat een derde eruitzien als eigen domein.

# staat het verzamel-subdomein op eigen infrastructuur of wijst het door?
dig +short sgtm.voorbeeld.nl CNAME
dig +short sgtm.voorbeeld.nl A

# welk endpoint krijgt de gebeurtenissen binnen?
jq -r '.log.entries[]
  | select(.request.postData.text != null)
  | .request.url' capture.har | sort | uniq -c | sort -rn

Bij een server-side Google Tag Manager gaan de gebeurtenissen vaak naar een pad als /g/collect op het eigen subdomein, terwijl een klassieke opzet naar een Google-domein zou gaan. Dat het verzamelpunt op een eigen adres staat is dan gemeten. Waar het daarna heen gaat is vermoed, want dat deel gebeurt op de server. Ik kan de doorverdeling niet zien, ik kan alleen aannemelijk maken dat ze plaatsvindt.

Wat je alsnog kunt vaststellen¶

Ook al blijft de doorverdeling onzichtbaar, ik ben niet blind. Er zijn dingen die ik wel hard kan maken vanaf het toestel. Ik kan meten dat er een verzamelpunt is en hoeveel gebeurtenissen het ontvangt. Ik kan meten of dat verzamelpunt een eigen subdomein is en of het via een CNAME naar een externe partij wijst. Ik kan de payload lezen die eruit gaat en zien welke identifiers en velden erin zitten voordat ze de server bereiken.

Wat ik niet kan meten, benoem ik als zodanig. Ik claim niet te weten wie er achter het verzamelpunt gevoed wordt, want dat verkeer bestaat niet op het toestel. Dit onderscheid is de kern van eerlijk meten. Een verzamelpunt met een CNAME naar een tagleverancier is een sterke aanwijzing voor doorverdeling, maar het is een aanwijzing en geen bewijs van de uiteindelijke ontvangers. Ik houd die twee lagen streng uit elkaar: het gemeten bestaan van het verzamelpunt, en de vermoede verdeling erachter. Zo blijft mijn conclusie navolgbaar tot aan de plek waar mijn zicht ophoudt.

Waarom dit meer is dan een technisch detail¶

Server-side tagging verschuift de plek waar de verdeling gebeurt, en daarmee verschuift ook wie het kan waarnemen. Voor de gebruiker en voor een toezichthouder die op afstand meet, wordt het moeilijker om vast te stellen welke partijen gegevens ontvangen. De grondslag onder de AVG verandert daar niet door. Voor het plaatsen en uitlezen van gegevens op een apparaat geldt artikel 11.7a van de Telecommunicatiewet, en voor de verdere verwerking gelden de gewone AVG-verplichtingen. Toestemming, transparantie en een grondslag blijven vereist, ook als het doorsturen op de server gebeurt.

Wat verdwijnt is de zichtbaarheid, niet de plicht. Een site die server-side tagging inzet, moet in haar eigen documentatie nog steeds verantwoorden welke ontvangers er zijn. De verplaatsing naar de server raakt ook de doorgifte naar derde landen. Als de container gegevens doorzet naar een partij buiten de Europese Economische Ruimte, dan gelden de artikelen 44 tot en met 49 AVG onverkort. Dat het doorsturen serverzijdig gebeurt, verandert daar niets aan. De enige die het verschil merkt is de buitenstaander die probeert te meten, en juist die verliest zijn zicht. De techniek maakt het mogelijk om die verantwoording te ontlopen zonder dat een buitenstaander het merkt. Dat is de reden dat ik de techniek serieus neem in mijn oordeel.

Wat dit voor mijn werk betekent¶

Server-side tagging is precies de reden dat ik nooit claim het hele plaatje te zien. Alles wat ik met een browsermeting vaststel is een ondergrens. Wat ik meet, is wat er zichtbaar overheen ging. De rest schuift bewust uit het zicht, en ik benoem dat als zodanig.

Concreet betekent het dat ik een schone meting anders label dan een schone werkelijkheid. Als ik één verzamelpunt zie dat veel gebeurtenissen slikt, noteer ik dat als een aanwijzing voor doorverdeling op de server, met bewijsniveau vermoed. En als een site er schoon uitziet, schrijf ik erbij dat de meting server-side doorverdeling niet uitsluit. Dat voorbehoud hoort in elke conclusie, want zonder dat voorbehoud zou een lezer de ondergrens voor het volledige beeld aanzien. Ik meet zoals een bezoeker, zie Meet zoals een bezoeker, niet zoals een scanner, en ik houd vast aan de regel dat afwezigheid op de lijn geen afwezigheid van verwerking is. Zie Een naam in de code is nog geen tracker voor de spiegelbeeldige valkuil aan de andere kant.

Zie ook CNAME-cloaking vermomt een derde partij als eigen subdomein, Meet zoals een bezoeker, niet zoals een scanner en Een naam in de code is nog geen tracker.