Welke trackingrecords over een persoon gaan
Meer dan de meeste teams denken:
- Events — elke paginaweergave, klik en conversie, gekoppeld aan een anonieme ID, sessie-ID en, na inloggen, gebruikers-ID; met gehashte identifiers (
em,ph) wanneer de toestemming die toeliet. - Click-ID's —
gclid,fbcen verwanten, first-party opgeslagen voor attributie. - Toestemmingsregistraties — de verleende doeleinden, de hash van de TC-string, tijdstempels; dit zijn persoonsgegevens én je bewijs van rechtmatige verwerking.
- Afleverpogingen — wat naar welk platform is gestuurd, met de geredigeerde payload-preview.
- Conversierecords en geïmporteerde CRM-uitkomsten.
- Kopieën bij platformen — wat Meta, Google en de anderen hebben ontvangen; verwijdering daar is een apart verzoek aan elk platform.
De betrokkene identificeren
Een verzoek komt meestal binnen met een e-mailadres. Track hasht het (kleine letters, getrimd, SHA-256) en doorzoekt events op de em-hash; het accepteert ook een gebruikers-ID uit jouw systeem of een anonieme ID die de persoon op de privacypagina kan aflezen. Het zoekt nooit op het e-mailadres in platte tekst, omdat e-mailadressen in platte tekst niet worden opgeslagen.
Is er geen match, dan zegt het rapport dat — ‘geen records gevonden voor de opgegeven identifiers’ is een legitieme en veelvoorkomende uitkomst bij bezoekers die nooit toestemming hebben gegeven voor identifiers.
Soorten verzoeken
| Soort | Wat Track doet |
|---|---|
| export / overdraagbaarheid | bouwt per site een JSON-rapport: events (naam, tijd, URL, toestemming, commercedata, click-ID's, bron), conversierecords; te downloaden vanuit het Privacy Center |
| verwijderen | verwijdert de events, conversierecords en click-ID's van de betrokkene op elke site van de organisatie; schrijft per store een verwijderjob-vermelding met aantallen |
| beperken / bezwaar | wordt vastgelegd; afgedwongen door het toestemmingsbeleid (toekomstige events voor de identifiers worden verworpen) en door de bewaartermijnen |
| rectificeren | wordt vastgelegd; trackingdata worden niet veld voor veld gerectificeerd — de juiste waarde komt bij het volgende event uit het bronsysteem |
Elke soort levert een auditvermelding op (wie heeft het verwerkt, wanneer, welke sites) en een afsluitrapport dat bij het verzoek wordt opgeslagen. Het rapport bevat aantallen, niet de verwijderde inhoud.
De termijn
Verzoeken krijgen een vervaldatum van 30 dagen na ontvangst; het Privacy Center toont openstaande verzoeken met hun vervaldatum. Verlenging is een beslissing van de beheerder, geen standaard.
Wat verwijdering bewust laat staan
- De auditlog-vermelding dat er een verwijdering heeft plaatsgevonden, met aantallen en het verzoek-ID — niet de identifiers.
- Al berekende geaggregeerde statistieken (dagelijkse eventaantallen, health scores), die geen persoonsgegevens zijn.
- Toestemmingsregistraties voor de bewaartermijn die nodig is om rechtmatige verwerking aan te tonen, met de identifiers verwijderd zodra de registratie daarvoor niet meer nodig is.
- Data bij platformen. Het rapport somt elke destination op waaraan events van de betrokkene zijn afgeleverd, zodat de beheerder de bijbehorende verwijderverzoeken bij de platformen kan indienen; Track doet niet alsof het data verwijdert die het niet beheert.
Bewaartermijnen maken de meeste verzoeken kleiner
Korte bewaartermijnen voor click-ID's, afleverpogingen en ruwe-data-archieven betekenen dat een groot deel van de data van een betrokkene al is verlopen wanneer een verzoek binnenkomt. De pagina met het bewaarbeleid toont de ingestelde termijnen per datasoort, en het exportrapport vermeldt welke termijnen van toepassing waren.
Hoe bezoekers je bereiken
De openbare privacypagina noemt het kanaal voor verzoeken — het contactformulier of het adres in het colofon. De beheerder voert het verzoek in het Privacy Center in met de identifiers die de bezoeker heeft opgegeven; vanaf daar volgt het de wachtrij en de audittrail die hierboven zijn beschreven.