Hoe implementeer je Privacy by Design in server-side tracking
Een uitgebreid stappenplan
- Artikel
- Technical Web Analytics
In ons vorige blogartikel onderzochten we het belang van Privacy by Design (PbD) in server-side tracking om te zorgen voor naleving van databeschermingsregels zoals de GDPR. Nu zullen we een stapsgewijze handleiding delen om je te helpen deze essentiële privacypraktijken te implementeren. Dit zorgt voor dataprivacy en -beveiliging in elke fase van het ETL-proces in tagmanagementsystemen.
Lees onze vorige blog over het belang van PbD hier.
Voorbeeldcase “Organisatie XYZ”
Organisatie XYZ wil gegevens combineren van client-side en server-side tracking voor hun dataverzameling, maar wil ervoor zorgen dat hun aanpak privacygericht is. Ze hebben een gegevensinventaris gemaakt en toepasselijke gebieden gekoppeld. Ze willen nu het ETL-proces uitvoeren op basis van PbD om te laten zien welke stappen er ondernomen moeten worden. In dit voorbeeld kiezen we ervoor om IP-adressen van gebruikers te verwerken.
Stap 1: Data van gebruikers extraheren met Privacy by Design-principes
In de extractiestap worden gegevens uit verschillende bronnen verzameld in de datalaag, zoals ontwikkeling, websites, applicaties of opgeslagen data. Toestemming van de gebruiker (of andere wettelijke gronden) bepaalt wat in de datalaag terechtkomt en wat niet wordt verwerkt.
Voorbeeld: Organisatie XYZ
XYZ gebruikt IP-adressen voor verschillende doeleinden: het voldoen aan wettelijke verplichtingen voor het registreren van toestemming, het verkrijgen van toestemming voor marketing en analyse, en het nastreven van legitieme belangen voor fraude-detectie. Omdat XYZ altijd het IP-adres nodig heeft, ongeacht toestemming, wordt het nooit volledig uit de datalaag verwijderd.
Als je ook een gemakkelijke manier wilt hebben om je gegevenslaag te bekijken, kijk dan eens naar onze Tagbird-chrome-extensie voor je browser. Je kunt meer leren over onze gratis extensie in dit artikel.
Stap 2: Data veilig transformeren om de privacy van gebruikers te beschermen
In de transformatiestap verwerk en organiseer je de geëxtraheerde data in een bruikbaar formaat. Aan het begin van deze fase bevat de datalaag alleen de gegevenspunten die door het eerste filter zijn gekomen. Door je datapunten in je datalaag specifiek voor een doel te maken, maak je transparant welke datapunten kunnen worden geladen voor verschillende doeleinden. Afhankelijk van de behoeften aan granulariteit kun je ook datapunten onleesbaar maken om ze minder gevoelig te maken als de use case dit toelaat.
Voorbeeld: Organisatie XYZ
XYZ wil de doeleinden voor persoonlijke gegevens splitsen en dit duidelijk maken in de gegevenslaag:
- Wettelijke verplichting: Maak het gegevenspunt “client_ip_address_legal_obligation”.
- Analyse en marketing: Vul “client_ip_address_marketing” of “client_ip_address_analytics” alleen in als gebruikers specifieke toestemming hebben gegeven.
- Fraude-detectie: Maak “client_ip_address_fraud” aan met alleen de eerste twee cijferparen om onnodige specifieke IP-informatie te verwijderen.
De PbD-paginaweergave wordt idealiter naar de server-side oplossing gestuurd, waar er meer opties zijn om te beperken welke gegevens server-naar-server worden verzonden.
Stap 3: Data verantwoord laden in server-side tracking
In de laadstap verplaats je de getransformeerde data om het doel waarvoor ze zijn verwerkt uit te voeren. Of je nu data client-side of server-side verzendt, elk laadpunt moet worden geconfigureerd met het juiste doelgerichte datapunt om de juiste dimensie te bieden. Zorg ervoor dat het eindpunt dat de data opslaat, kan voldoen aan de bewaartijdcriteria van de data-inventaris.
Voorbeeld: Organisatie XYZ
XYZ configureert elke eindpuntconnector of tag met het specifieke gegevenspunt, en toestemmingsvoorkeuren bepalen of de gegevens naar het eindpunt worden geladen:
- Wettelijke verplichting: Stuur “client_ip_address_legal_obligation” naar hun toestemmingsregistratieserver met een bewaartijd van 13 maanden.
- Marketing en analyse: Stuur “client_ip_address_marketing” of “client_ip_address_analytics” naar een server-side tagmanagementsysteem als de gebruiker toestemming heeft gegeven.
- Fraude-detectie (niet afgebeeld): Stuur “client_ip_address_fraud_obfuscated” server-side, waar het verder wordt gecodeerd en omgezet naar een landcode, en vervolgens naar een fraude-data lake met een bewaartijd van 3 maanden.
Conclusie
Het implementeren van Privacy by Design (PbD) in tagmanagementsystemen via het ETL-proces zorgt voor robuuste dataprivacy en naleving. Door PbD-principes te integreren in elke stap van de data lifecycle kun je een privacygerichte aanpak creëren die zowel de organisatie als de individuen wiens data worden verwerkt ten goede komt. Voor een algemeen overzicht van het belang van PbD in server-side tracking, lees onze inleidende blog hier.
Dit is een artikel Bram Ooms
Bram begon in 2019 als Technisch Webanalist, waar hij zich richtte op data-implementaties bij klanten als Univé, DPG Media, Boels en Vodafone. Door zijn ervaringen met de impact van wetgeving op het mogelijk maken van datastromen ontwikkelde hij een interesse in dataprivacy, waar hij nu actief mee bezig is binnen Digital Power.
1x per maand data insights, praktijkcases en een kijkje achter de schermen ontvangen?
Meld je aan voor onze maillijst en blijf 'up to data':