Identitetsdata i Web SDK

Adobe Experience Platform Web SDK använder Adobe Experience Cloud ID:n (ECID:n) för att spåra besökares beteende. Om du använder ECIDs kan du se till att varje enhet har en unik identifierare som kan finnas kvar i flera sessioner och koppla alla träffar som inträffar under och mellan webbsessioner till en viss enhet.

Det här dokumentet innehåller en översikt över hur du hanterar ECIDs och CORE IDs med Web SDK.

Spåra ECID:n med Web SDK tracking-ecids-web-sdk

Web SDK tilldelar och spårar ECIDs med hjälp av cookies, med flera tillgängliga metoder för att konfigurera hur dessa cookies genereras.

När en ny användare kommer till din webbplats försöker Adobe Experience Cloud Identity Service att ange en cookie för enhetsidentifiering för den användaren.

När cookie-filen som innehåller ECID har ställts in, kommer varje efterföljande begäran som genereras av Web SDK att innehålla en kodad ECID i kndctr_{YOUR-ORG-ID}_AdobeOrg_identity-cookien.

När du använder cookies för enhetsidentifiering har du två sätt att interagera med Edge Network:

Som förklaras i avsnitten nedan har den datainsamlingsmetod som du väljer att använda en direkt inverkan på cookie-livstiden i olika webbläsare.

Spåra CORE ID:n med Web SDK tracking-coreid-web-sdk

När du använder Google Chrome med cookies från tredje part aktiverade och det inte finns någon cookie för kndctr_{YOUR-ORG-ID}_AdobeOrg_identity går den första Edge Network-begäran igenom en demdex.net-domän, som ställer in en demonstrationscookie. Den här cookien innehåller en CORE ID. Detta är ett unikt användar-ID, som skiljer sig från ECID.

Beroende på implementeringen kan du vilja komma åt CORE ID.

Insamling av data från första part first-party

Första parts datainsamling innebär att ange cookies via en CNAME på din egen domän som pekar på adobedc.net.

Webbläsare har långa behandlade cookies som anges av CNAME slutpunkter på ungefär samma sätt som de som anges av webbplatsägda slutpunkter, men de senaste ändringar som implementeras av webbläsare har gjort skillnad i hur CNAME cookies hanteras. Det finns inga webbläsare som blockerar cookies från första part som standard, men vissa webbläsare begränsar livstiden för cookies som anges med CNAME till endast sju dagar.CNAME

Datainsamling från tredje part third-party

Insamling av data från tredje part innebär att data skickas direkt till Edge Network-domänen adobedc.net.

Under de senaste åren har webbläsare blivit allt mer restriktiva när det gäller hantering av cookies som fastställs av tredje parter. Vissa webbläsare blockerar cookies från tredje part som standard. Om du använder cookies från tredje part för att identifiera webbplatsbesökare är livslängden för dessa cookies nästan alltid kortare än vad som annars skulle vara tillgängligt med cookies från första part i stället. Ibland upphör en cookie från tredje part om så lite som sju dagar.

När du använder datainsamling från tredje part begränsar vissa annonsblockerare dessutom trafiken till slutpunkterna för datainsamling i Adobe helt och hållet.

Effekter av livscykeln för cookies i Adobe Experience Cloud-program lifespans

Oavsett om du väljer datainsamling från första part eller från tredje part har den tid en cookie kan finnas kvar en direkt inverkan på besökarantal i Adobe Analytics och Customer Journey Analytics. Slutanvändare kan även uppleva inkonsekventa personaliseringsupplevelser när Adobe Target eller Offer decisioning används på webbplatsen.

Tänk dig till exempel en situation där du har skapat en personaliseringsupplevelse som befordrar ett objekt till hemsidan om en användare har visat det tre gånger under de senaste sju dagarna.

Om en slutanvändare besöker webbplatsen tre gånger i veckan och sedan inte återvänder till webbplatsen på sju dagar, kan den användaren betraktas som en ny användare när han eller hon kommer tillbaka till webbplatsen, eftersom deras cookies kan ha tagits bort av en webbläsarprincip (beroende på vilken webbläsare användaren använde när han eller hon besökte webbplatsen). Om detta händer behandlar analysverktyget besökaren som en ny användare trots att de besökte webbplatsen för bara lite över sju dagar sedan. Alla försök att personalisera upplevelsen för användaren börjar också om.

Enhets-ID:n för första part (FPID:n) fpid

Om du vill ta hänsyn till effekterna av cookie-livscykler enligt ovan kan du välja att ställa in och hantera dina egna enhetsidentifierare i stället. Mer information finns i handboken om enhets-ID:n från första part.

Hämta ECID och region för den aktuella användaren retrieve-ecid

Beroende på ditt användningssätt kan du komma åt ECID på två sätt:

Hämta ECID via datapresten för datainsamling retrieve-ecid-data-prep

Använd Dataprep för datainsamling för att mappa ECID till ett XDM-fält. Det här är det rekommenderade sättet att komma åt ECID.

Om du vill göra det anger du följande sökväg i källfältet:

xdm.identityMap.ECID[0].id

Ange sedan målfältet till en XDM-sökväg där fältet är av typen string.

Hämta ECID via kommandot getIdentity() retrieve-ecid-getidentity

Om du vill hämta det unika ECID:t för den aktuella besökaren använder du kommandot getIdentity. För förstagångsbesökare som inte har ECID än genererar det här kommandot en ny ECID. getIdentity returnerar också region-ID:t för besökaren.

alloy("getIdentity")
  .then(function(result) {
    // The command succeeded.
    console.log("ECID:", result.identity.ECID);
    console.log("RegionId:", result.edge.regionId);
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information.
  });

Hämta CORE ID för den aktuella användaren retrieve-coreid

Om du vill hämta CORE-ID:t för en användare kan du använda kommandot getIdentity() enligt nedan.

alloy("getIdentity",{
  "namespaces": ["CORE"]
});

Använder identityMap using-identitymap

Med hjälp av ett XDM identityMap-fältkan du identifiera en enhet/användare med flera identiteter, ange deras autentiseringstillstånd och avgöra vilken identifierare som betraktas som den primära. Om ingen identifierare har angetts som primary blir standardvärdet ECID.

identityMap fält uppdateras med kommandot sentEvent.

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "authenticated",
          "primary": true
        }
      ]
    }
  }
});

Varje egenskap i identityMap representerar identiteter som tillhör ett visst identitetsnamnområde. Egenskapsnamnet ska vara identitetsnamnutrymmessymbolen, som du hittar i Adobe Experience Platform-användargränssnittet under Identities. Egenskapsvärdet ska vara en array med identiteter som gäller det identitetsnamnutrymmet.

Varje identitetsobjekt i identitetsarrayen innehåller följande egenskaper:

Om du använder fältet identityMap för att identifiera enheter eller användare får du samma resultat som om du använder metoden setCustomerIDs från metoden ID Service API. Mer information finns i API-dokumentationen för ID-tjänsten.

Migrera från Visitor API till ECID migrating-visitor-api-ecid

När du migrerar från med Visitor API kan du även migrera befintliga AMCV-cookies. Om du vill aktivera ECID-migrering anger du parametern idMigrationEnabled i konfigurationen. ID-migrering aktiverar följande användningsfall:

Uppdaterar egenskaper för migrering

När XDM-formaterade data skickas till Audience Manager måste dessa data konverteras till signaler vid migrering. Dina egenskaper måste uppdateras för att återspegla de nya nycklarna som finns i XDM. Den här processen blir enklare om du använder BAAAM-verktyget som Audience Manager har skapat.

Använd vid vidarebefordran av händelse

Om du för närvarande har vidarebefordring av händelser aktiverat och använder appmeasurement.js och visitor.js kan du behålla funktionen för vidarebefordran av händelser aktiverad och detta orsakar inga problem. På baksidan hämtar Adobe alla AAM segment och lägger till dem i anropet till Analytics. Om anropet till Analytics innehåller dessa segment kommer Analytics inte att anropa Audience Manager för att vidarebefordra data, så det finns ingen dubbel datainsamling. Du behöver heller inte använda platstips när du använder Web SDK eftersom samma segmenteringsslutpunkter anropas i serverdelen.