Första parts enhets-ID i Web SDK

Adobe Experience Platform Web SDK tilldelar Adobe Experience Cloud ID (ECID) till besökare via 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).

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örutsättningar

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 och identityMap. Se översikten på identitetsdata i Web SDK för mer information.

Använda FPID

FPID:n spårar besökare genom att använda cookies från första part. cookies från första part är mest effektiva när de ställs in med en server som använder en DNS En post (för IPv4) eller AAAA-post (för IPv6), till skillnad från 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 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 besökaren. Se avsnittet senare i det här dokumentet på använda FPID i identityMap för mer information.

Krav för ID-formatering

Platform Edge Network godkänner endast ID:n som uppfyller UUIDv4-format. 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.

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:

När cookien ska ställas in

FPID-cookien bör helst anges innan du skickar några förfrågningar 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

Cookies som anges med HTTPOnly kan inte nås 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 anger du HTTPOnly -flaggan säkerställer att värdet inte är tillgängligt för klientskript, men inte har någon negativ inverkan på plattformens Edge-nätverks förmåga att läsa cookien.

Secure secure

Cookies som anges med Secure -attribut 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 ställa in Secure flagga.

SameSite same-site

The SameSite -attribut låter 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, Laxoch None. Kontakta ditt interna team för att ta reda på vilken inställning som är rätt för din organisation.

Om nej SameSite har angetts, standardinställningen för vissa webbläsare är nu SameSite=Lax.

Använda FPID i identityMap identityMap

Nedan visas ett exempel på hur du ställer in 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 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 aktiverat, 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 det saknar primary -indikator för FPID. Minst ett ID finns 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 returneras av Edge Network 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:

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.

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 förväxla ett ECID tas det bort från identityMap och ersatts med det ECID som har genererats. FPID lagras inte i någon Adobe Experience Platform- eller Experience Cloud-lösning.