Data Privacy-labels voor Analytics-variabelen

De klanten van de Adobe, als gegevensverwerkingsverantwoordelijken, zijn verantwoordelijk voor het naleven van de toepasselijke wetten van de Privacy van Gegevens zoals de Algemene Verordening van de Bescherming van Gegevens (GDPR) en de Wet van de Consumentenprivacy van Californië (CCPA). Klanten dienen hun eigen juridische teams te raadplegen om te bepalen hoe hun gegevens moeten worden verwerkt om te voldoen aan de privacywetten voor gegevens. Adobe begrijpt dat elk van haar klanten unieke behoeften heeft met betrekking tot privacy. Daarom stelt Adobe haar klanten in staat om hun gewenste instellingen aan te passen voor gegevensverwerking in verband met privacy van gegevens. Hierdoor kan elke afzonderlijke klant Data Privacy-aanvragen verwerken op de manier door voor het merk en de unieke dataset van deze klant het meest zinnig is.

Adobe Analytics biedt tools voor het labelen van data op basis van de gevoeligheid en contractuele beperkingen ervan. Labels zijn een belangrijke stap voor: (1) identificatie van betrokkenen, (2) bepaling van welke gegevens als onderdeel van een toegangsverzoek moeten worden geretourneerd, en (3) identificatie van gegevensvelden die als onderdeel van een verwijderingsverzoek moeten worden verwijderd.

Voordat u kunt achterhalen welke labels op welke variabelen/velden moeten worden toegepast, moet u de id's begrijpen die u in de Analytics-data vastlegt, en beslissen welke u gebruikt voor Data Privacy-aanvragen.

De implementatie van Adobe Analytics Data Privacy ondersteunt de volgende labels voor identiteitsdata, gevoelige data en data-governance.

Identiteitsgegevenslabels identity-data-labels

“I”-labels voor identiteitsdata worden gebruikt om data te categoriseren waarmee een specifieke persoon kan worden geïdentificeerd of gecontacteerd.

Gevoelige gegevenslabels sensitive-data-labels

“S”-labels voor gevoelige data worden gebruikt om gevoelige data zoals geografische data te categoriseren. In de toekomst zullen extra labels voor gevoelige data worden geïntroduceerd om andere soorten gevoelige informatie te identificeren.

Labels voor gegevensbeheer (Data Privacy) data-governance-labels

Met labels voor gegevensbeheer kunnen gebruikers gegevens classificeren die privacygerelateerde overwegingen en contractuele voorwaarden weerspiegelen, zodat de klanten van de Adobe aan de voorschriften en het bedrijfsbeleid kunnen blijven voldoen.

Toegangslabels voor gegevenPrivacy access

Weinig variabelen zullen een van de andere labels krijgen, maar de verwachting is dat de toegangslabels op veel van uw variabelen zullen worden toegepast. Het is echter aan u, in overleg met uw Juridische team, om te beslissen welke gegevens u hebt verzameld, met de Onderwerpen van Gegevens moeten worden gedeeld.

Gegevensprivacy labels verwijderen delete

In tegenstelling tot de andere labels sluiten deze verwijderingslabels elkaar niet uit. U kunt een van beide, beide of geen van beide selecteren. Een apart label van het type None is niet nodig, omdat None wordt aangegeven door een van de verwijderopties niet te controleren.

Een label Verwijderen is alleen vereist voor velden die een waarde bevatten waarmee een treffer aan het gegevensonderwerp kan worden gekoppeld (zodat het gegevensonderwerp kan worden geïdentificeerd). Overige persoonlijke gegevens (favorieten, browsergeschiedenis/aankoopgeschiedenis, gezondheidstoestand, enz.) hoeft niet te worden verwijderd omdat de koppeling met de betrokkene wordt verbroken.

Identiteitslabels gegevensprivacy identity

Geef een naamruimte op wanneer u een variabele labelt als ID-DEVICE of ID-PERSON provide-namespace

Wanneer u een variabele als ID-DEVICE of ID-PERSON labelt, wordt u gevraagd om een naamruimte op te geven. U kunt een eerder gedefinieerde naamruimte gebruiken of een nieuwe naamruimte definiëren.

Een eerder gedefinieerde naamruimte gebruiken previously-defined

Als u eerder een id-label hebt toegewezen aan andere variabelen in een van de rapportsuites in uw aanmeldingsbedrijf, kunt u één van deze bestaande naamruimten selecteren. U moet de naamruimte opnieuw gebruiken als deze variabele hetzelfde soort id's bevat als andere variabelen die al zijn gelabeld met deze naamruimte, en als u alle variabelen wilt doorzoeken bij het verzenden van een aanvraag.

Een nieuwe naamruimte definiëren define

U kunt ook een nieuwe naamruimte definiëren. We raden u aan naamruimtetekenreeksen te beperken tot alfanumerieke tekens, plus onderstrepingstekens, streepjes en spaties. Deze worden geconverteerd naar kleine letters.

De tekenreeks die u opgeeft als naamruimte, is dezelfde tekenreeks die u moet gebruiken bij het verzenden van aanvragen via de Data Privacy-API als de waarde van de parameter “namespace”. Het verzoek veroorzaakt dan Adobe Analytics om alle variabelen in al uw rapportreeksen te zoeken die dit namespace voor identiteitskaart delen u met het verzoek specificeerde.

U hoeft de labels ID-DEVICE of ID-PERSON niet te specificeren op alle variabelen die id's bevatten (daar zijn de I1/I2-labels voor). Gebruik dit label als u Data Privacy-aanvragen gaat verzenden met id's die in deze variabele zijn opgeslagen, en u deze variabele wilt doorzoeken naar de opgegeven id. Bijvoorbeeld: als eVar1 een e-mailadres kan bevatten, en eVar2 een gebruikersaanmeldingsnaam kan bevatten, maar u altijd alleen aanvragen gaat verzenden met gebruikmaking van de gebruikersnaam, dan kunt u eVar1 labelen als I1, ACC-PERSON, DEL-PERSON, maar eVar2 als I2, ACC-PERSON, DEL-PERSON, ID-PERSON met de naamruimte “user name”. Vervolgens kunt u een aanvraag verzenden met een JSON-blok als gebruikerssectie, zoals:

{
     "namespace": "user name",
     "type": "analytics",
     "value": "rocketman123"
}

Het is aanvaardbaar om dezelfde naamruimte te gebruiken voor verschillende variabelen binnen dezelfde rapportsuite. Zo slaan sommige aangepaste implementaties een CRM-ID op in zowel een prop als een eVar. Als CRM-ID altijd in één van hen (zoals de eVar) voorkomt, en slechts af en toe in andere (de herinnering) voorkomt, en nooit in prop wanneer niet ook in de eVar, dan vereist slechts de eVar een etiket van identiteitskaart en een namespace omdat de Adobe slechts in die eVar voor identiteitskaart kan zoeken. Als de CRM-ID echter soms voorkomt in de ene variabele en soms in de andere, moeten beide dezelfde naamruimte hebben en zal Adobe beide variabelen doorzoeken op instanties van de id die is opgegeven als onderdeel van een Data Privacy-aanvraag met deze naamruimte. U hebt nog steeds een DEL-label nodig op al deze variabelen, zodat de waarde anoniem blijft, ongeacht waar deze voorkomt.

Een ander voorbeeld: u hebt misschien een CRM-id die soms wordt ingezonden via eVar1 en soms via prop7. Vervolgens hebt u een verwerkingsregel die de waarde van eVar1, indien aanwezig, naar eVar3 kopieert. Anders, kopieert het de waarde van prop7 in eVar3. In dit scenario bevat eVar3 altijd de CRM-id als deze bekend is, zodat alleen eVar3 een ID-PERSON-label nodig heeft.

Typen variabelen en de labels voor gegevensprivacy die ze ondersteunen variable-types

De etiketten van de Privacy van gegevens beïnvloeden vier brede klassen van variabelen van de Analyse. Niet alle variabelen ondersteunen alle labels. In deze tabel wordt aangegeven met welke variabelen de labels worden ondersteund of niet.

Variabelen waaraan andere labels dan ACC-ALL/ACC-PERSON kunnen worden toegewezen/gewijzigd variables

Verwijderverwerking deletion

De ondersteuning van Adobe Analytics voor Data Privacy-verwijderingsaanvragen is ontworpen om de gevolgen voor rapportage zo klein mogelijk te houden. In de meeste gevallen zouden de cijfers die in rapporten worden weergegeven, niet moeten veranderen. Een historisch rapport dat is uitgevoerd vóór de Data Privacy-verwijdering, zou overeen moeten komen met dezelfde rapportrun van na de verwijdering. Dit wordt bereikt door de verwijderde gegevens volledig los te koppelen van de betrokkene, terwijl niet-identificeerbare gegevens op hun plaats blijven zodat de gerapporteerde waarden consistent blijven.

In de volgende tabel wordt beschreven hoe verschillende variabelen worden “verwijderd”. Dit is geen volledige lijst.

Variabelen die de verwachte labels voor verwijderen mogelijk niet ondersteunen no-delete-support

Deze sectie is bedoeld om informatie te verduidelijken over variabelen van de Analyse die schrapping niet kunnen steunen. Soms worden deze variabelen verwijderd door niet-analytische gebruikers (zoals het juridische team) die het type gegevens in de variabele niet begrijpen en veronderstellingen maken op basis van de naam van de variabele.

Het is belangrijk te begrijpen welk type gegevens in elke variabele is opgenomen voordat een beslissing wordt genomen over etikettering of verwijdering, en niet alleen te vertrouwen op de naam van een variabele. Hier volgt een lijst met enkele van deze variabelen en waarom deze mogelijk niet hoeven te worden verwijderd, of waarom hiervoor geen specifiek verwijderingslabel nodig is:

Datumvelden voor verzoeken om toegang access-requests

Er zijn vijf standaardvariabelen die tijdstempels bevatten:

Voor de code voor het genereren van de bestanden die voor Data Privacy-toegangsaanvragen worden geretourneerd, moet minstens één van de eerste drie tijdstempelvariabelen in de toegangsaanvraag zijn opgenomen (een ACC-label hebben dat van toepassing is op het type aanvraag). Als geen van deze zijn opgenomen, wordt Aangepaste tijdstip treffer in UTC worden behandeld alsof het een ACC-ALL-label heeft.

Het CSV-bestand op raakniveau dat wordt geretourneerd voor verzoeken om toegang tot gegevensprivacy converteert de waarden in deze velden van unieke tijdstempels naar datum-/tijdvelden in de indeling YYYY-MM-DD HH:MM:SS (bijvoorbeeld 2018-05-01 13:49:22 ). In het samenvattingsbestand HTML worden deze tijdstempelwaarden ingekort, zodat alleen de datum YYYY-MM-DD wordt opgenomen om het aantal unieke waarden voor deze velden te verminderen.