Bästa praxis för etikettering
Märkningen måste granskas varje gång en ny rapportserie skapas eller när en ny variabel aktiveras i en befintlig rapportserie. Du kan också behöva granska etiketteringen när nya lösningar är aktiverade, eftersom de kan visa nya variabler som kan kräva etiketter. En återimplementering av dina mobilappar eller webbplatser kan ändra hur befintliga variabler används, vilket också kan göra det nödvändigt att uppdatera etiketter.
Etiketterna I1, I2, S1 och S2 har samma betydelse som motsvarande DULE-etiketter i Adobe Experience Platform. De används dock för mycket olika syften. I Adobe Analytics används dessa etiketter för att identifiera fält som ska anonymiseras som ett resultat av en begäran om Privacy Service. Inom Adobe Experience Platform används de för åtkomstkontroll, samtyckeshantering och för att införa marknadsföringsbegränsningar för märkta fält. Adobe Experience Platform stöder många extra etiketter som inte används av Adobe Analytics. Om du använder Analytics Data Connector för att importera dina Adobe Analytics-data till Adobe Experience Platform, bör du se till att alla I1-, I2-, S1- och S2-etiketter som du har använt i Adobe Analytics också tillämpas på de scheman i Adobe Experience Platform som används av de importerade rapportsviterna.
Direkt eller indirekt identifierbara ID:n direct-vs-indirect
Innan du kan ta reda på vilka etiketter som ska användas på vilka variabler/fält måste du först förstå vilka ID:n som du hämtar i dina Analytics-data, och du måste bestämma vilka som ska användas för begäranden om datasekretess. Datasekretess utökar omfattningen av vad som kan anses vara ett ID. ID:n kan delas in i två huvudklasser: direkt identifierbar (identitetsetikett: I1) och indirekt identifierbar (identitetsetikett: I2).
- Ett direkt identifierbart ID (I1): Namnger personen eller tillhandahåller en direkt metod för att kontakta honom/henne. Exempel kan vara någons namn (t.o.m. ett vanligt namn som Anders Svensson som kan delas av hundratals personer), deras e-postadresser eller telefonnummer, o.s.v. En postadress utan ett namn kan anses vara direkt identifierbart, även om den endast identifierar ett hushåll eller ett företag i stället för en viss person inom det hushållet eller företaget.
- Ett indirekt identifierbart ID (I2): Tillåter inte identifiering av en enskild person, utan kan kombineras med annan information (som du kanske har tillgång till) för att identifiera någon. Exempel på ett indirekt identifierbart ID är ett kundlojalitetsnummer eller ett ID som används av ett företags CRM-system som är unikt för varje kund. Enligt datasekretess kan anonyma ID:n som lagras i de spårningscookies som används av Analytics anses vara indirekt identifierande, även om de bara kan identifiera en enhet snarare än en individ. På en delad enhet kan dessa cookies inte skilja mellan olika användare i systemet. Även om cookiefilen inte kan användas för att hitta en dator som innehåller cookien, och om någon har åtkomst till datorn och hittar cookien, kan de sedan koppla Analytics-cookiedata tillbaka till datorn.
En IP-adress anses också vara indirekt identifierbar, eftersom den vid en given tidpunkt bara kan tilldelas en enskild enhet. Internet-leverantörer kan däremot ändra IP-adresserna för de flesta användare regelbundet, så med tiden kan en IP-adress ha använts av någon av deras användare. Det är inte heller ovanligt att många kunder hos en Internet-leverantör eller flera anställda inom ett företag på samma intranät delar samma externa IP-adress. På grund av detta stöder inte Adobe att en IP-adress används som ID för en datasekretessbegäran. När ett ID som vi godkänner används som en del av en borttagningsbegäran, rensas även IP-adresserna som inträffade med det ID:t. Du måste bestämma om det finns andra insamlade ID:n som kan ingå i denna kategori, i1 eller I2, men som inte är lämpliga att använda som särskiljande ID för förfrågningar om dataintegritet.
Även om ditt företag samlar in många olika ID:n i era analysdata, kan du välja att endast använda en delmängd av dessa ID:n för begäranden om datasekretess. Detta kan bero på följande:
- I dina egna system kan du mappa ett av ID:n (till exempel e-postadress) till ett annat ID (till exempel CRM-ID). För konsekvensens skull väljer du att endast använda CRM-ID:t för begäranden om datasekretess i datasekretessbehandlingen.
- Du har ingen metod för att validera att någon faktiskt är den person som är kopplad till ID:t. Det kan till exempel vara svårt att validera att en IP-adress bara används av en person och att personen som skickar begäran faktiskt är den personen.
- Vissa ID:n kan motsvara flera personer och du vill inte riskera att returnera information om en person till någon annan med samma ID. Även om du till exempel kan verifiera att någon har namnet Anders Svensson kanske du inte vill returnera alla data om alla Anders Svensson i ditt system.
- Ett annat exempel är ett enhets-ID, till exempel cookie-ID för analys. Om ID:t finns i en mobilapp kan du bestämma att alla interaktioner som använder det ID:t ska vara tillgängliga för mobiltelefonens ägare. Om det däremot inträffar på en delad enhet, till exempel en dator i hemmet eller en dator i ett bibliotek eller ett Internetkafé, kan du bestämma att du inte kan skilja mellan användare av den enheten och risken för att returnera data för en annan användare är för stor för att den här typen av ID ska kunna användas.
Bästa praxis för ID:n som stöds av Analytics best-practices-an
Använd den här tabellen för att fastställa vilka typer av ID som du kommer att använda när du skickar begäranden om datasekretess till Analytics. När du känner till den här informationen är det enklare att avgöra vilka andra etiketter du ska använda för variablerna.
Cookie-ID:er
- (Äldre) Analytics-cookie
- Identitetstjänstens cookie(ECID), som tidigare kallades för Marketing Cloud ID (MCID)
Dessa cookies identifierar en enhet eller, mer specifikt, en webbläsare för en användare av en enhet. För en delad enhet där en gemensam inloggning används kan detta ID gälla för alla användare av enheten. Adobe har skapat ett enhetligt JavaScriptsom du kan placera på din webbplats för att samla in dessa cookies om du vill tillåta att de används för begäranden om datasekretess.
Användare av Adobe Analytics Mobile SDK har också ett Experience Cloud ID (ECID). Det finns API-anrop i SDK som används för att läsa detta ID, så du kan förbättra din app och samla in den för att få en begäran om datasekretess.
Många företag anser att webbläsarcookie-ID:n är delade enhets-ID:n. Därför kan de i samråd med sina juridiska team välja att inte ge stöd för att använda dem som godkända ID:n för förfrågningar om dataintegritet. Alternativt kan de välja att endast returnera en mycket begränsad mängd data när dessa ID:n används eller bara godkänna dem för borttagningsbegäranden.
Dessa cookies har en ID-DEVICE-etikett som inte kan ändras (samt etiketterna I2 och DEL-DEVICE). Adobe Analytics-standardkonfigurationen returnerar bara allmän information om enheten, till exempel enhetstyp, operativsystem, webbläsare. samt den tid/de datum som webbplatsen besöktes när dessa ID:n användes. Om du väljer att stöda dessa ID:n för begäranden om datasekretess, vilket beskrivs nedan, kan du lägga till eller ta bort ACC-ALL-etiketter för att konfigurera den exakta uppsättning fält som du vill ska returneras för en begäran om datasekretess.
Om rapportsviten motsvarar en mobilapp som kräver inloggning kan du bestämma att enhetens Experience Cloud-ID motsvarar en viss användare. I så fall kanske du vill märka fler fält med etiketten ACC-ALL, inklusive namnen på besökta sidor, visade produkter osv.
Obs! Om du anger alternativet ”expandIds” i din begäran om datasekretess kommer dina begäranden alltid att innehålla cookie-ID:n, förutom eventuella andra ID:n du anger. Mer information finns iID-expansion. I dessa fall returnerar träffar som bara har ett cookie-ID, men inte ett annat ID, endast data som är etiketterade ACC-ALL som en del av åtkomstbegäran.
Vissa kunder placerar ID:er i anpassade trafikvariabler (props) eller anpassade konverteringsvariabler (eVars). Det vanligaste är ett CRM-ID, medan andra är e-postadresser, användarinloggningsnamn, kundlojalitetsnummer eller haschar av dessa värden.
- Om du vill använda något av dessa ID:n för begäranden om datasekretess ska du förse fältet som innehåller det med en ID-PERSON-etikett.
- (Mycket mindre vanligt) Om ett ID i en av dessa anpassade variabler bara identifierar en enhet som kan delas av flera personer, kan du i stället använda en ID-DEVICE-etikett.
- Dessa fält kräver också I1- eller I2-etiketter och ska innehålla etiketterna DEL-PERSON eller DEL-DEVICE. Alternativet PERSON/DEVICE för etiketten DEL matchar vanligtvis alternativet PERSON/DEVICE för ID-etiketten.
Det är ovanligt att en rapportserie har fler än en eller två anpassade variabler som innehåller ID:n som du vill använda för att identifiera registrerade personer för datasekretessförfrågningar. Du kan ha flera variabler som tilldelas I1- eller I2-etiketter, men vanligtvis har bara en eller två av dessa ID-PERSON- eller ID-DEVICE-etiketter.
Även om detta inte används i någon större utsträckning stöder Analytics även implementering där ett anpassat besökar-ID kan anges, som då används i stället för den gamla Analytics-spårningscookien. Det här fältet har etiketterna I2, ID-PERSON och DEL-PERSON.
Många implementeringar härleder detta ID från ett CRM-ID så att det bara finns när någon är inloggad på sin plats. Detta gör att samma anpassade besökar-ID kan användas på olika enheter. En teknisk nackdel är att spårning som sker innan användaren loggar in inte kan knytas till spårning som samlas in efter att användaren har loggat in. Om du i stället använder det anpassade besökar-ID:t för att identifiera en enhet, ska du ändra etiketterna ID-PERSON och DEL-PERSON till ID-DEVICE respektive DEL-DEVICE.
Metodtips för att ange borttagningsetiketter best-practices-delete
Borttagningsetiketterna DEL-DEVICE och DEL-PERSON ska användas sparsamt. När det tillämpas på en variabel som inte innehåller ett ID som användes som en del av begäran om datasekretess ändras antalet (metrik) i historiska Analytics-rapporter nästan alltid.
-
Vi rekommenderar att en av dessa etiketter används på alla variabler som är märkta I1, I2 eller S1. De kan inte tillämpas på variabler som inte har etiketten I1, I2 eller S1.
-
DEL-etiketterna resulterar i att dessa variabler anonymiseras (ID:t ersätts med en slumpmässig sträng med prefixet ”Datasekretess-”). Samma anonymiserade värde ersätter alla instanser av det ursprungliga värdet i alla träffar som har identifierats av ett ID som används i begäran. Om det ursprungliga värdet i det här fältet var ett av dessa ID:n, ändras inte rapportens metrik.
-
Om ett fält har etiketten ID-DEVICE ska du i allmänhet även tilldela etiketten DEL-DEVICE.
-
Om ett fält har etiketten ID-PERSON ska du också tilldela etiketten DEL-PERSON.
-
Om ett fält inte har någon ID-etikett, men innehåller identifieringsinformation som du vill anonymisera, beror den lämpliga etiketten (DEVICE eller PERSON) på implementeringen. Om du bara använder cookie-ID:n för begäranden om datasekretess ska du använda DEL-DEVICE.
-
Om du använder anpassade ID:n i ett annat fält med en ID-PERSON-etikett, och du bara vill att detta ska rensas på rader där ID:t finns, använder du DEL-PERSON.
-
Om du använder ID-expansion och vill att alla värden ska rensas för alla träffar på alla identifierade enheter använder du DEL-DEVICE. Du kan använda både etiketterna DEL-DEVICE och DEL-PERSON i det här fallet om du vill, men etiketten DEL-PERSON är inte nödvändig eftersom ID-expansionen innebär att alla rader som matchar ett person-ID också matchar ett enhets-ID.
-
Om du inte anger användning av ID-expansion, men använder en blandning av enhets- och person-ID för olika begäranden, kanske du vill ange både DELL-DEVICE- och DEL-PERSON-etiketter för variabler som ska tas bort när någon typ av ID används.
-
Observera att om en DEL-DEVICE- eller DEL-PERSON-etikett anges för en variabel som inte också används som ett ID för den begäran (inklusive ett utökat ID), kommer unika värden i den variabeln endast att anonymiseras vid träffar där ett angivet (eller utökat) ID inträffar. Om andra träffar innehåller samma värde kommer det inte att uppdateras på de andra platserna. Detta kan leda till att antalet (metrik) ändras.
Om du till exempel har tre träffar som innehåller värdet ”foo” i eVar7, men bara ett av dem innehåller ett ID i en annan variabel som matchas för en borttagning, ändras ”foo” i den träffen till ett värde som ”Datasekretess-123456789”, medan det förblir oförändrat i de andra två träffarna. En rapport som visar antalet unika värden för eVar7 visar nu ett mer unikt värde än det gjorde tidigare. En rapport som visar de högsta värdena för eVars kan innehålla ”foo” med endast två instanser (i stället för 3 tidigare), och det nya värdet visas också med en enda instans.
Metodtips för att ange åtkomstetiketter best-practices-access
Även om väldigt få fält kommer att ha någon av de andra etiketterna, så är det vanligt att ett stort antal fält har ACC-etiketter. Vilka åtkomstetiketter som är lämpliga beror på vilka ID:n du använder för begäranden om datasekretess.
Om de enda ID:n du använder är cookie ID:n eller de med ID-DEVICE-etikett, ska du bara använda ACC-ALL-etiketten.
Du får ett par filer för varje åtkomstbegäran: en fil som innehåller en rad för varje matchande träff med alla angivna ACC-ALL-fält och en sammanfattningsfil som innehåller en sammanfattning av dessa data.
Om du bara använder anpassade ID:n som har ID-PERSON-etiketten och inte gör ID-expansion ska du använda ACC-PERSON-etiketter. Men du behöver inte ändra standardetiketterna för ACC-ALL. Dessa fält inkluderas automatiskt i åtkomstbegäran.
Du får ett par filer för varje åtkomstbegäran: en fil som innehåller en rad för varje matchande träff med alla angivna fält för ACC-DEVICE och ACC-PERSON samt en sammanfattningsfil som innehåller en sammanfattning av dessa data.
Om du inkluderar både enhets- och person-ID:n i begäranden om datasekretess, eller om du använder anpassade ID:n (anpassade besökar-ID:n eller ID:n i en prop eller eVar), måste du vara uppmärksam på de ACC-etiketter som du använder. Varje åtkomstbegäran returnerar två par datafiler.
Ett par filer som innehåller en fil med data från träffar som innehöll ett matchande person-ID och en annan fil som innehåller data från träffar som inte matchade ett person-ID, men som matchade ett enhets-ID.
De andra två filerna ("person-ID") innehåller data om alla träffar som matchade person-ID:n med alla fält som har antingen en ACC-PERSON- eller ACC-ALL-etikett. En fil med alla matchade träffar och en annan sammanfattningsfil med en sammanfattning av dessa data.
Filparet ”enhets-ID” innehåller bara fält som har en ACC-ALL-etikett och bara träffar som inte innehöll något matchande person-ID. Dessa filer kan innehålla data som har genererats av andra användare av en delad enhet, så du bör noga tänka på den uppsättning fält som innehåller etiketten ACC-ALL. Standardetiketten i Analytics använder bara den här etiketten för generiska informationsfält som hör till enheten (enhetstyp, operativsystem, webbläsare, o.s.v.) plus datum/tid för varje träff.
Du kan välja att ta emot både uppsättningar av enhets- och personfiler från Adobe och sedan bara dela personfilerna, så att du inte delar data som kan ha genererats av andra användare av en delad enhet. Eller så kanske du vill kombinera data från en eller båda uppsättningar med annan information som du känner till om den registrerade och returnera den i ditt eget format.