Första parts enhets-ID i Web SDK
Adobe Experience Platform Web SDK tilldelar Adobe Experience Cloud ID:n (ECID:n) till webbplatsbesökare genom att använda cookies för att spåra användarbeteenden. Om du vill ta hänsyn till webbläsarbegränsningar för cookie-intervall kan du välja att ställa in och hantera dina egna enhetsidentifierare i stället. Dessa kallas för FPID (First-party device ID).
Du kan antingen använda enhets-ID:n från en annan leverantör eller använda cookies från tredje part, men du kan inte använda båda funktionerna samtidigt.
I det här dokumentet beskrivs hur du konfigurerar enhets-ID:n från första part för implementeringen av Platform Web SDK.
Förhandskrav
I den här handboken förutsätts du känna till hur identitetsdata fungerar för Platform Web SDK, inklusive rollen för ECID:n och identityMap
. Mer information finns i översikten över identitetsdata i Web SDK.
Använda FPID
FPID:n spårar besökare genom att använda cookies från första part. Första parts-cookies är mest effektiva när de ställs in med en server som använder en DNS A-post (för IPv4) eller AAAA-post (för IPv6), i motsats till en DNS CNAME- eller JavaScript-kod.
A
- eller AAAA
-poster stöds bara för att ange och spåra cookies. Den primära metoden för datainsamling är via en DNS CNAME. Med andra ord anges FPID:n med en A-post eller AAAA-post och skickas sedan till Adobe med en CNAME.När en FPID-cookie har angetts kan dess värde hämtas och skickas till Adobe när händelsedata samlas in. Insamlade FPID används som frön för att generera ECID, som även fortsättningsvis är de primära identifierarna i Adobe Experience Cloud-program.
Om du vill skicka ett FPID för en webbplatsbesökare till Platform Edge Network måste du inkludera FPID i identityMap
för den besökaren. Mer information finns i avsnittet senare i det här dokumentet om att använda FPID:n i identityMap
.
Krav för ID-formatering
Platform Edge Network accepterar bara ID:n som är kompatibla med formatet UIDv4. Enhets-ID som inte är i UUIDv4-format kommer att avvisas.
Generering av ett UUID resulterar nästan alltid i ett unikt, slumpmässigt ID, där sannolikheten för en kollision är försumbar. UUIDv4 kan inte dirigeras med IP-adresser eller någon annan personligt identifierbar information (PII). UUID är vanligt förekommande och bibliotek finns för praktiskt taget alla programmeringsspråk för att generera dem.
Ställa in cookie för första parts-ID i användargränssnittet för datastreams setting-cookie-datastreams
Du kan ange ett cookie-namn i användargränssnittet för datastreams, där FPID kan finnas, i stället för att behöva läsa cookie-värdet och inkludera FPID i identitetskartan.
Mer information om hur du konfigurerar ett datastream finns i datastreams-dokumentationen.
Aktivera alternativet First Party ID Cookie när du konfigurerar ditt datastream. Den här inställningen instruerar Edge Network att referera till en angiven cookie när ett enhets-ID från en annan tillverkare identifieras, i stället för att det här värdet slås upp i identitetskartan.
Mer information om hur de fungerar med Adobe Experience Cloud finns i dokumentationen om cookies från första part.
När du aktiverar den här inställningen måste du ange namnet på den cookie där ID:t ska lagras.
När du använder ID:n för första part kan du inte utföra synkroniseringar av ID:n från tredje part. Synkronisering av tredje parts-ID är beroende av tjänsten Visitor ID och den UUID
som genereras av den tjänsten. När du använder funktionen för första parts-ID genereras ECID utan att tjänsten Visitor ID används, vilket gör att synk av tredje parts-ID inte kan användas.
När du använder ID:n för första part stöds inte Audience Manager-funktioner som är avsedda för aktivering på partnerplattformar, eftersom synk för Audience Manager partner-ID oftast baseras på UUIDs
eller DIDs
. Det ECID som härleds från ett första part-ID är inte länkat till ett UUID
, vilket gör det oadresserbart.
Ange en cookie med din egen server
När du ställer in en cookie med en server som du äger kan olika metoder användas för att förhindra att cookien begränsas på grund av webbläsarprinciper:
- Generera cookies med serverskriptspråk
- Ange cookies som svar på en API-begäran som görs till en underdomän eller annan slutpunkt på webbplatsen
- Generera cookies med CMS
- Generera cookies med ett CDN
document.cookie
-metod kommer nästan aldrig att skyddas från webbläsarprinciper som begränsar cookie-varaktighet.När cookien ska ställas in
FPID-cookien bör helst anges innan någon begäran görs till Edge Network. I scenarier där detta inte är möjligt genereras dock ett ECID fortfarande med befintliga metoder och fungerar som primär identifierare så länge som cookien finns.
Om man utgår ifrån att ECID så småningom påverkas av en policy för borttagning av webbläsare, men inte av FPID, kommer FPID att bli den primära identifieraren vid nästa besök och kommer att användas för att förorsaka ECID vid varje påföljande besök.
Ange förfallodatum för cookien
Att ange förfallodatum för en cookie är något som du bör tänka på noga när du implementerar FPID-funktionen. När du beslutar om detta bör du ta hänsyn till de länder eller regioner där organisationen arbetar tillsammans med lagstiftningen och policyn i var och en av dessa regioner.
Som en del av det här beslutet kanske du vill anta en företagsomfattande policy för cookie-inställningar eller en som varierar för användare på de olika språkområden där du arbetar.
Oavsett vilken inställning du väljer för den första förfallodagen för en cookie måste du se till att du inkluderar logik som förlänger förfallotiden för cookien varje gång ett nytt besök på webbplatsen inträffar.
Påverkan av cookie-flaggor
Det finns olika cookie-flaggor som påverkar hur cookies hanteras i olika webbläsare:
HTTPOnly
http-only
Det går inte att komma åt cookies som har angetts med flaggan HTTPOnly
med skript på klientsidan. Det innebär att om du anger en HTTPOnly
-flagga när du anger FPID måste du använda ett skriptspråk på serversidan för att läsa cookie-värdet som ska inkluderas i identityMap
.
Om du väljer att låta Platform Edge Network läsa värdet för FPID-cookien säkerställer en inställning av flaggan HTTPOnly
att värdet inte är tillgängligt för klientskript, men inte har någon negativ inverkan på Platform-Edge Network för att läsa cookien.
HTTPOnly
påverkar inte cookie-principerna som kan begränsa cookie-livstiden. Men det är fortfarande något du bör tänka på när du anger och läser värdet för FPID.Secure
secure
Cookies som angetts med attributet Secure
skickas bara till servern med en krypterad begäran via HTTPS-protokollet. Om du använder den här flaggan kan du se till att angripare i mitten inte lätt kommer åt värdet på cookien. När det är möjligt är det alltid en bra idé att ange flaggan Secure
.
SameSite
same-site
Med attributet SameSite
kan servrar avgöra om cookies skickas med förfrågningar mellan webbplatser. Attributet ger visst skydd mot attacker med förfalskning över flera webbplatser. Det finns tre möjliga värden: Strict
, Lax
och None
. Kontakta ditt interna team för att ta reda på vilken inställning som är rätt för din organisation.
Om inget SameSite
-attribut anges är standardinställningen för vissa webbläsare nu SameSite=Lax
.
Använda FPID i identityMap
identityMap
Nedan visas ett exempel på hur du skulle ange ett FPID i identityMap
:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
Precis som med andra identitetstyper kan du inkludera FPID med andra identiteter i identityMap
. Följande är ett exempel på FPID som ingår i ett autentiserat CRM-ID:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Om FPID finns i en cookie som läses av Edge Network när datainsamling från första part är aktiverad, ska du endast hämta det autentiserade CRM-ID
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Följande identityMap
skulle resultera i ett felsvar från Edge Network eftersom den saknar primary
-indikatorn för FPID. Minst ett av ID:n i identityMap
måste markeras som primary
.
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"authenticatedState": "ambiguous"
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated"
}
]
}
}
Felsvaret som Edge Network returnerade i det här fallet liknar följande:
{
"type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
"status": 400,
"title": "No primary identity set in request (event)",
"detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
"report": {
"requestId": "{REQUEST_ID}",
"configId": "{CONFIG_ID}",
"orgId": "{ORG_ID}"
}
}
ID-hierarki
När både ett ECID och ett FPID finns, prioriteras ECID för att identifiera användaren. Detta garanterar att när ett befintligt ECID finns i webbläsar-cookie-arkivet förblir det den primära identifieraren och befintligt antal besökare riskerar inte att påverkas. För befintliga användare blir FPID inte den primära identiteten förrän ECID:t upphör att gälla eller tas bort som ett resultat av en webbläsarprincip eller manuell process.
Identiteter prioriteras i följande ordning:
- ECID ingår i
identityMap
- ECID lagras i en cookie
- FPID ingår i
identityMap
- FPID som lagras i en cookie
Migrera till enhets-ID:n från första part
Om du migrerar till att använda FPID:n från en tidigare implementering kan det vara svårt att se hur övergången kan se ut på en låg nivå.
För att illustrera denna process bör du överväga ett scenario där en kund som tidigare besökt er webbplats deltar och vilken inverkan en FPID-migrering skulle ha på hur kunden identifieras i Adobe.
ECID
prioriteras alltid framför FPID
.Vanliga frågor och svar
Nedan följer en lista med svar på vanliga frågor om enhets-ID:n från första part.
Hur skickar jag ett ID annorlunda än att bara generera ett ID?
Begreppet dirigering är unikt i och med att det FPID som skickas till Adobe Experience Cloud konverteras till ett ECID med hjälp av en deterministisk algoritm. Varje gång samma FPID skickas till Adobe Experience Platform Edge Network dirigeras samma ECID från FPID.
När ska det första parts enhets-ID genereras?
För att minska den potentiella besökarinflationen bör FPID genereras innan du gör din första begäran med Web SDK. Om du inte kan göra detta kommer dock ett ECID att genereras för den användaren och användas som primär identifierare. Det FPID som genererades kommer inte att bli den primära identifieraren förrän ECID:t inte längre finns.
Vilka datainsamlingsmetoder stöder enhets-ID:n från första part?
För närvarande stöder endast Web SDK FPID.
Lagras FPID:n på någon plattforms- eller Experience Cloud-lösning?
När FPID har använts för att skapa ett ECID tas det bort från identityMap
och ersätts med det ECID som har genererats. FPID lagras inte i någon Adobe Experience Platform- eller Experience Cloud-lösning.