familiewapen Mick Beermickbeer.com

manuscript ·

beginselTracking en cookiesbronnenverwant

Trackers hebben rollen, en die verwar je niet

In een app of site zitten families die elk iets anders doen. Analytics meet gedrag. Crash-SDK's meten stabiliteit. Attributie koppelt een installatie aan de campagne die hem opleverde. Identity-resolution knoopt losse identifiers aan een persoon. Advertentie-SDK's bieden je toestel aan adverteerders aan. Ze allemaal 'tracker' noemen verhult dat de risico's per rol verschillen; een crash-SDK is iets anders dan een identity-resolver.

Lang niet elk script is een tracker

Op een gemiddelde pagina of in een gemiddelde app draaien tientallen stukjes code van derde partijen. Ze op één hoop gooien onder het woord "tracker" is verleidelijk, want het levert een groot en alarmerend getal op. Het is ook onnauwkeurig. De scripts hebben verschillende rollen, en die rollen dragen verschillende risico's. Een lettertypedienst die een font levert, doet iets heel anders dan een databroker die een profiel opbouwt. Wie beide "tracker" noemt, overdrijft de eerste en verzwakt de aandacht voor de tweede.

Ik onderscheid in de praktijk een handvol families. Elk heeft een eigen taak, een eigen dataprofiel en een eigen juridische lading.

  • Analytics. Meet gedrag op de pagina: welke schermen, hoe lang, welke knoppen. Voorbeelden zijn de bekende statistiekpakketten. Het risico zit in de reikwijdte van wat ze meten en of ze dat delen.
  • Crash- en performance-SDK's. Meten stabiliteit: crashes, laadtijden, foutmeldingen. Ze sturen stacktraces en toestelgegevens op. De datastroom is technisch, de koppeling aan een persoon meestal zwak.
  • Attributie. Koppelt een installatie of aankoop aan de campagne die hem opleverde. In de mobiele wereld heten deze partijen mobile measurement partners. Ze leunen op identifiers en op mechanismen als de install referrer.
  • Identity-resolution. Knoopt losse identifiers, cookies, e-mailhashes en toestelnummers, aan één persoon. Dit is de zwaarste familie, want het bouwt het profiel dat de rest verhandelt.
  • Advertentie-SDK's. Bieden je toestel aan adverteerders aan via real-time bidding. Ze zenden je kenmerken de veiling in, iets wat ik apart uitwerk in Real-time bidding biedt jouw toestel in een veiling aan, in milliseconden.
  • Consent-platforms. Regelen de toestemmingsvraag en coderen je keuze, meestal via het IAB TCF. Ze bouwen zelf geen profiel. Ze bepalen wel of de rest mag vuren, en dat maakt ze een sleutelrol.
  • Neutrale infrastructuur. Een CDN dat bestanden serveert, een lettertype, een A/B-testframework. Deze halen soms wel je IP-adres binnen, maar bouwen geen profiel.

Waarom het onderscheid de meting draagt

De rol bepaalt de ernst, en de ernst bepaalt of een bevinding hout snijdt. Als ik een rapport aflever waarin een CDN en een identity-resolver naast elkaar staan als "tracker nummer 14 en tracker nummer 15", dan heb ik mijn eigen conclusie ondergraven. Een tegenpartij hoeft alleen het zwakste item aan te wijzen, het lettertype, om het hele rapport verdacht te maken. Precisie in de rol is dus zelfbescherming.

Er is één familie die aparte aandacht verdient: de tag-manager. Een tag-manager vuurt zelf vaak niets zichtbaars af. Zijn taak is andere scripts binnenhalen, op basis van regels die op afstand worden beheerd. Dat maakt hem lastig. Wat hij vandaag inlaadt, kan morgen anders zijn, zonder dat de app of de pagina verandert. Een momentopname onderschat hem daarom structureel. Ik behandel de tag-manager als een deur, en ik let op wie er doorheen komt, niet alleen op de deur zelf.

Een tweede reden waarom de rol telt, is de rechtsgrond. Een crash-SDK die stabiliteit meet, kan vaak leunen op een gerechtvaardigd belang, want de gegevens dienen de werking van de app en zijn zwak aan een persoon te koppelen. Een advertentie-SDK die je toestel de veiling in stuurt, heeft toestemming nodig, want daar worden persoonsgegevens voor advertentiedoeleinden verspreid. Twee scripts die op het eerste gezicht allebei "data versturen", vallen dus onder een verschillend regime. Wie ze samen op één hoop legt, kan een crash-SDK ten onrechte beschuldigen en een advertentie-SDK ten onrechte ontzien. De rol bepaalt welke grond nodig is, en de grond bepaalt of er een overtreding op tafel ligt.

Hoe ik een rol vaststel

Ik kijk naar wat een partij feitelijk doet in de opname. De categorie waarin een blokkeerlijst een domein toevallig plaatst, is een startpunt, geen bewijs. Een naam in de code bewijst weinig, zoals ik uitwerk in Een naam in de code is nog geen tracker. De handeling in het verkeer bewijst iets.

Concreet lees ik het vastgelegde netwerkverkeer en let ik op de vorm van de verzoeken:

  • Een verzoek met een OpenRTB-body (imp, device, tmax) is een advertentie-SDK die de veiling in gaat.
  • Een POST met een stacktrace, een threadlijst en een crashreason is een crash-SDK.
  • Een verzoek dat een install referrer of een campagne-id draagt, wijst op attributie.
  • Een verzoek dat e-mailhashes of meerdere identifiers samen verstuurt, wijst op identity-resolution.
  • Een verzoek dat alleen een statisch bestand ophaalt zonder identifier, is infrastructuur.

Een klein voorbeeld van hoe ik in opgeslagen verkeer een eerste sortering maak:

def rol(verzoek):
    body = verzoek.get("body", "")
    if all(k in body for k in ('"imp"', '"device"')):
        return "advertentie / RTB"
    if "stacktrace" in body or "crashreason" in body:
        return "crash-SDK"
    if "install_referrer" in body or "campaign_id" in body:
        return "attributie"
    if body.count('"em"') or "email_sha256" in body:
        return "identity-resolution"
    return "onbekend / nader bekijken"

Dit is een grove eerste zeef. De uitkomst "onbekend" is een opdracht om beter te kijken, niet een vrijbrief om iets af te schrijven. Pas als ik de rol ken, weeg ik de partij.

Wat het bewijsniveau hier is

Dat de families technisch verschillen, is gemeten: de verschillen zitten in de vorm van de verzoeken, en die kun je zien. Welke rol een concrete partij speelt, is afgeleid uit het verkeer, met de kanttekening dat één opname een momentopname is. Dat een tag-manager morgen iets anders inlaadt, is vermoed zolang ik het niet over de tijd heb gemeten. Ik label die niveaus expliciet, in lijn met Label elke bevinding op bewijsniveau, want de kracht van dit werk zit in het uit elkaar houden van wat ik zag en wat ik denk.

Wat het voor mijn werk betekent

Het onderscheid is de reden dat mijn rapporten korter zijn dan die van sommige geautomatiseerde scanners, en tegelijk zwaarder wegen. Een scanner telt domeinen. Ik weeg rollen. Dat kost meer werk per bevinding en het levert een bevinding op die je aan een toezichthouder of een journalist kunt voorleggen zonder dat de eerste tegenvraag hem omvertrekt. Ik meet bovendien zoals een echte bezoeker, want een scanner lokt ander gedrag uit dan een mens, iets wat ik uitwerk in Meet zoals een bezoeker, niet zoals een scanner. Een lange lijst maakt indruk. Een gewogen lijst maakt een zaak.

Zie ook Een naam in de code is nog geen tracker, Label elke bevinding op bewijsniveau en Meet zoals een bezoeker, niet zoals een scanner.

bronnen
  1. IAB Europe, Transparency and Consent Framework, vendorlijst met doelenper partij staat vastgelegd welke rol en welke doelen worden geclaimd
citeer alsBeer, M. (2026, 9 juli). Trackers hebben rollen, en die verwar je niet. mickbeer.com. https://mickbeer.com/#trackers-hebben-rollen-en-die-verwar-je-niet

lees dit stuk in het manuscript, met alles waar het aan hangt