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 enhets-ID:n från första part (FPIDs).

I det här dokumentet beskrivs hur du konfigurerar enhets-ID:n från första part för Web SDK-implementeringen.

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 (First-party device ID) using-fpid

Första parts enhets-ID (FPIDs) spårar besökare med hjälp av 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.

När en FPID-cookie har angetts kan dess värde hämtas och skickas till Adobe när händelsedata samlas in. Insamlade FPIDs används som startvärde för att generera ECIDs, som även fortsättningsvis är de primära identifierarna i Adobe Experience Cloud-program.

Om du vill skicka en FPID för en webbplatsbesökare till Edge Network måste du inkludera FPID i identityMap för den besökaren. Mer information finns i avsnittet längre ned i det här dokumentet om att använda FPID:n i identityMap.

Krav för formatering av enhets-ID från första part formatting-requirements

Edge Network accepterar bara IDs som överensstämmer med UIDv4-formatet. Enhets-ID:n som inte är i formatet UUIDv4 kommer att avvisas.

Generering av UUID resulterar nästan alltid i ett unikt, slumpmässigt ID, med sannolikheten för att en kollision inträffar är försumbar. UUIDv4 kan inte dirigeras med IP-adresser eller annan personlig identifierbar information (PII). UUIDs är vanligt förekommande och bibliotek kan hittas för praktiskt taget alla programmeringsspråk för att generera dem.

Ställa in en cookie för ett första parts-ID i användargränssnittet för datastreams setting-cookie-datastreams

Du kan ange ett cookie-namn i Datastreams-användargränssnittet, 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 från första part kan du inte synkronisera ID:n från tredje part. Synkronisering av tredjeparts-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 det omöjligt att synkronisera tredje parts-ID.

När du använder förstaparts-ID:n stöds inte Audience Manager-funktioner som är avsedda för aktivering på partnerplattformar, eftersom Audience Manager partner-ID-synk oftast baseras på UUIDs eller DIDs. ECID som härleds från ett första part-ID är inte länkat till en UUID, vilket gör den oadresserbar.

Ange en cookie med din egen server set-cookie-server

När du ställer in en cookie med en server som du äger kan du använda olika metoder för att förhindra att cookien begränsas på grund av webbläsarprinciper:

När cookien ska ställas in when-to-set-cookie

Cookien FPID 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 ECID fortfarande med befintliga metoder och fungerar som primär identifierare så länge som cookien finns.

Om ECID så småningom påverkas av en princip för borttagning av webbläsare, men FPID inte gör det, kommer FPID att bli den primära identifieraren vid nästa besök och kommer att användas för att dirigera ECID vid varje efterföljande besök.

Ange förfallodatum för cookien set-expiration

Att ange förfallodatum för en cookie är något som du bör tänka på noga när du implementerar funktionen FPID. 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 cookie-flag-impact

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 Edge Network läsa värdet för cookien FPID kan du genom att ställa in flaggan HTTPOnly se till att värdet inte är tillgängligt för klientskript, men inte har någon negativ inverkan på Edge Network för att läsa cookien.

Secure secure

Cookies som angetts med attributet Secure skickas bara till servern med en krypterad begäran via protokollet HTTPS. 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 en 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 en autentiserad CRM ID:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "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 bara hämta den 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 primary-indikatorn för FPID saknas. 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}"
    }
}

Ställa in ett FPID på din egen domän setting-fpid-domain

Förutom att ange FPID i identitetskartan kan du ange FPID-cookien på din egen domän, om du har konfigurerat en första part-datainsamling CNAME.

När datainsamling från första part aktiveras med en CNAME skickas alla cookies för din domän på begäranden som görs till datainsamlingsslutpunkten.

Alla cookies som inte är relevanta för Adobe datainsamling tas bort. För FPID kan du ange namnet på cookien FPID i datastream-konfigurationen. När du gör detta läser Edge Network innehållet i cookien FPID i stället för att leta efter FPID i identitetskartan.

Om du vill använda den här funktionen måste du ange FPID på den översta nivån i din domän i stället för en specifik underdomän. Om du anger värdet för en underdomän skickas inte cookie-värdet till Edge Network och lösningen FPID fungerar inte som den ska.

ID-hierarki id-hierarchy

När både ECID och FPID finns med prioriteras ECID när användaren identifieras. Detta garanterar att när en befintlig ECID finns i webbläsar-cookie-arkivet förblir 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 förfaller eller tas bort som ett resultat av en webbläsarprincip eller manuell process.

Identiteter prioriteras i följande ordning:

Migrera till enhets-ID:n från första part migrating-to-fpid

Om du migrerar till enhets-ID: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 den här processen bör du överväga ett scenario där en kund som tidigare besökt din webbplats deltar och vilken inverkan en FPID-migrering skulle ha på hur kunden identifieras i Adobe-lösningar.

Vanliga frågor och svar faq

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 FPID som skickas till Adobe Experience Cloud konverteras till ECID med hjälp av en deterministisk algoritm. Varje gång samma FPID skickas till Edge Network dirigeras samma ECID från FPID.

När ska det första parts enhets-ID genereras?

Om du vill 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 ECID fortfarande att genereras för den användaren och kommer att användas som primär identifierare. FPID som skapades blir inte primär identifierare förrän ECID 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 enhets-ID:n från första part.

Lagras första parts enhets-ID på någon plattforms- eller Experience Cloud-lösning?

När FPID har använts för att skapa startvärdet för en ECID tas den bort från identityMap och ersätts med ECID som har genererats. FPID lagras inte i några Adobe Experience Platform- eller Experience Cloud-lösningar.