Använd enhets-ID:n från första part i datainsamling

Experience Platform Edge Network använder Experience Cloud ID (ECID) för att identifiera webbplatsbesökare. Om du vill förbättra identitetshållbarheten för egna egenskaper kan du ange och hantera egna enhetsidentifierare, så kallade FPID:n (First-party device ID:n). Edge Network använder FPID för att dirigera den ECID som används i Adobe lösningar.

Den här sidan förutsätter att du känner till ECID:n och identityMap. Mer information finns i Identitet i datainsamling.

När FPID ska användas when-to-use

Webbläsarbegränsningar kan korta livet på cookies som Adobe använder för att identifiera återkommande besökare. Om du behöver en mer hållbar identitet på webbplatser som din organisation äger och kontrollerar, kan du med FPID hantera din egen enhetsidentifierare och använda den för att skapa en egen ECID.

FPID:n stöds för webbimplementeringar som använder Web SDK, inklusive taggtillägget Web SDK. De är idealiska när ditt huvudmål är starkare identitetskonsistens på domäner som organisationen äger, eller du vill ha bättre kontinuitet för rapportering och personalisering av ägda webbegenskaper. De gör det även möjligt att konfigurera och hantera en cookie från en egen infrastruktur som du har kontroll över.

FPID:n är inte det rätta verktyget när huvudmålet är att skicka från app till webben eller att upprätthålla identiteten i flera domäner. Se delning av mobil-till-webbidentitet och delning mellan domäner för dessa scenarier.

Fördelarna med att använda FPID är bland annat:

Övergångar till användning av FPID är bland annat:

Installationsväg på hög nivå

Hur FPID fungerar how-fpids-work

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 Edge Network dirigeras samma ECID från FPID. När FPID har använts för att skicka ett ECID tas det bort från identityMap och ersätts med det genererade ECID:t. FPID lagras inte i Adobe Experience Platform- eller Experience Cloud-lösningar.

När både ett ECID och ett FPID finns används alltid ECID för att identifiera användaren först. Denna prioritering säkerställer att när ett befintligt ECID finns i cookie-butiken i webbläsaren förblir det den primära identifieraren och befintligt antal besökare inte riskerar inflationen. 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 webbläsarprincipen eller manuella åtgärder.

Identiteter prioriteras i följande ordning:

Generera och ange FPID-cookie set-fpid-cookie

Edge Network godkänner endast ID:n som är kompatibla med formatet UIDv4. Enhets-ID:n som inte är i UUIDv4-format nekas.

Inställning för cookie på serversidan set-cookie-server

När du ställer in en cookie via din egen server kan du använda olika metoder för att förhindra att cookien begränsas av webbläsarprinciper:

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.

Observera att A- eller AAAA-poster bara stöds för att ange och spåra cookies. Den primära metoden för datainsamling är via en DNS CNAME. FPID:n anges med en A- eller AAAA-post och skickas till Adobe med en CNAME. Med Adobe-hanterat certifikatprogram kan du konfigurera CNAME för datainsamling.

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

FPID-cookien är idealisk innan data skickas till Edge Network. Om implementeringen kräver samtycke innan du samlar in data, se Godkänn med enhets-ID:n från första part för vägledning om hur du koordinerar FPID-cookien med ditt medgivandeflöde. Besökarinflationen minskar när du ser till att FPID är tillgängligt för att skicka ECID från första begäran. I scenarier där detta inte är möjligt genereras ett ECID fortfarande med befintliga metoder och fungerar som primär identifierare så länge som cookien finns. Det genererade FPID:t blir inte den primära identifieraren förrän ECID:t inte längre 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, blir FPID den primära identifieraren vid nästa besök och används för att förorsaka ECID vid varje påföljande besök.

Ange förfallodatum set-expiration

Adobe rekommenderar att du noggrant undersöker livstiden för din FPID-cookie. Se till att ni tar hänsyn till organisationens integritetspolicy tillsammans med lagstiftningen och policyn i de länder eller regioner där organisationen är verksam. Beroende på hur din organisation är konfigurerad kan du anta en företagsomfattande cookie-inställningsprincip eller en som varierar för användare på de olika språkområden där du arbetar. Oavsett hur länge cookie-filen förfaller ska du se till att inkludera logik som förlänger förfallotiden varje gång ett nytt webbplatsbesök inträffar.

Cookie-flaggor cookie-flags

Det finns flera cookie-flaggor som påverkar hur cookies hanteras i olika webbläsare:

Skicka FPID till Edge Network send-fpid

Du kan skicka FPID:n till Edge Network på två sätt:

Metod 1: Konfigurera en CNAME och ange en cookie för ett första part-ID i ditt datastream setting-cookie-datastreams

Om du vill ange en FPID-cookie från din egen domän måste du konfigurera din egen CNAME för dina SDK-webbsamtal och sedan aktivera cookie-funktionen för första parts-ID i din datastream-konfiguration. Med en CNAME-post i din DNS kan du skapa ett alias från ett domännamn till ett annat. Det här aliaset kan hjälpa till att få tredjepartstjänster att se ut som om de är en del av din egen domän, så att deras cookies ser ut som cookies från första part. När datainsamling från första part har aktiverats med en CNAME skickas alla cookies för din domän på begäranden som görs till datainsamlingsslutpunkten.

Metod 2: Använd FPID i identityMap identityMap

Som ett alternativ till att lagra FPID i din egen cookie kan du skicka FPID:t till Edge Network via identitetskartan.

Nedan visas ett exempel på hur du anger 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 exempel innehåller FPID med ett autentiserat CRM-ID:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "EMAIL": [
      {
        "id": "user@example.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": "user@example.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Följande identityMap ger ett felsvar från Edge Network eftersom den saknar primary-indikatorn för FPID. Minst ett ID i identityMap måste markeras som primary.

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "user@example.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

Migrera till FPID 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 denna process bör du överväga ett scenario där en kund som tidigare besökt er webbplats deltar och vilken effekt en FPID-migrering skulle ha på hur kunden identifieras i Adobe-lösningar.