Identitätsdaten in Web SDK

Adobe Experience Platform Web SDK verwendet Adobe Experience Cloud IDs (ECIDs) um das Besucherverhalten zu verfolgen. Mit ECIDs können Sie sicherstellen, dass jedes Gerät über eine eindeutige Kennung verfügt, die sitzungsübergreifend beibehalten werden kann. So können Sie alle Treffer, die während und über Web-Sitzungen hinweg auftreten, mit einem bestimmten Gerät verknüpfen.

Dieses Dokument bietet einen Überblick darüber, wie Sie ECIDs und CORE IDs mit der Web SDK verwalten.

Tracking von ECIDs mit Web SDK tracking-ecids-web-sdk

Web SDK weist ECIDs mithilfe von Cookies zu und verfolgt diese. Dabei stehen mehrere Methoden zur Konfiguration der Erstellung dieser Cookies zur Verfügung.

Wenn ein neuer Benutzer auf Ihre Website gelangt, versucht der Adobe Experience Cloud Identity Service, ein Gerätekennungs-Cookie für diesen Benutzer zu setzen.

Nachdem das Cookie, das die ECID enthält, gesetzt wurde, enthält jede nachfolgende, von der Web-SDK generierte Anfrage eine codierte ECID im kndctr_{YOUR-ORG-ID}_AdobeOrg_identity-Cookie.

Bei der Verwendung von Cookies zur Geräte-Identifizierung haben Sie zwei Möglichkeiten, mit dem Edge Network zu interagieren:

Wie in den folgenden Abschnitten erläutert, hat die von Ihnen gewählte Datenerfassungsmethode direkte Auswirkungen auf die Cookie-Lebensdauer in allen Browsern.

Tracking von CORE-IDs mit Web SDK tracking-coreid-web-sdk

Wenn Sie Google Chrome mit aktivierten Drittanbieter-Cookies verwenden und kein kndctr_{YOUR-ORG-ID}_AdobeOrg_identity-Cookie gesetzt ist, wird die erste Edge Network-Anfrage über eine demdex.net-Domain gesendet, die ein demdex-Cookie setzt. Dieses Cookie enthält eine CORE ID. Dies ist eine eindeutige Benutzer-ID, die sich von der ECID unterscheidet.

Abhängig von Ihrer -Implementierung möchten Sie möglicherweise auf zugreifen CORE ID.

Erstanbieter-Datenerfassung first-party

Bei der Erstanbieter-Datenerfassung werden Cookies über eine CNAME in Ihrer eigenen Domain gesetzt, die auf adobedc.net verweist.

Während Browser Cookies, die von CNAME-Endpunkten gesetzt werden, seit langem ähnlich wie diejenigen behandeln, die von Website-eigenen Endpunkten gesetzt werden, haben jüngste von Browsern implementierte Änderungen zu einem Unterschied bei der Verarbeitung CNAME Cookies geführt. Es gibt zwar keine Browser, die derzeit standardmäßig Erstanbieter-CNAME-Cookies blockieren, aber einige Browser beschränken die Lebensdauer von Cookies, die mit einem CNAME gesetzt werden, auf nur sieben Tage.

Datenerfassung durch Dritte third-party

Die Datenerfassung von Drittanbietern umfasst das direkte Senden von Daten an die Edge Network-Domain adobedc.net.

In den letzten Jahren wurden Webbrowser immer restriktiver in ihrer Handhabung von Cookies, die von Dritten gesetzt werden. Einige Browser blockieren standardmäßig Cookies von Drittanbietern. Wenn Sie Drittanbieter-Cookies verwenden, um Besucher der Website zu identifizieren, ist die Lebensdauer dieser Cookies fast immer kürzer als die, die andernfalls mit Erstanbieter-Cookies verfügbar wären. Manchmal läuft ein Drittanbieter-Cookie in nur sieben Tagen ab.

Bei der Verwendung der Datenerfassung von Drittanbietern beschränken einige Anzeigenblocker den Traffic außerdem vollständig auf Adobe-Datenerfassungsendpunkte.

Auswirkungen der Cookie-Lebensdauer auf Adobe Experience Cloud-Anwendungen lifespans

Unabhängig davon, ob Sie die Datenerfassung von Erstanbietern oder Drittanbietern auswählen, wirkt sich die Dauer, während der ein Cookie bestehen kann, direkt auf die Besucherzahlen in Adobe Analytics und Customer Journey Analytics aus. Außerdem kann es bei Endbenutzern zu inkonsistenten Personalisierungserlebnissen kommen, wenn Adobe TargetOffer decisioningoder 🔗 auf der Website verwendet werden.

Stellen Sie sich beispielsweise eine Situation vor, in der Sie ein Personalisierungserlebnis erstellt haben, das jedes Element auf die Startseite höher stuft, wenn ein Benutzer es in den letzten sieben Tagen dreimal angesehen hat.

Wenn ein Endbenutzer dreimal in der Woche die Website besucht und dann sieben Tage lang nicht zu ihr zurückkehrt, kann dieser Benutzer bei der Rückkehr zur Website als neuer Benutzer betrachtet werden, da seine Cookies möglicherweise durch eine Browser-Richtlinie gelöscht wurden (je nach Browser, den er beim Besuch der Website verwendet hat). In diesem Fall behandelt Ihr Analytics-Tool den Besucher als neuen Benutzer, obwohl er die Website erst vor etwas mehr als sieben Tagen besucht hat. Außerdem beginnt jeder Versuch, das Erlebnis für den Benutzer zu personalisieren, wieder.

First-Party-Geräte-IDs (FPIDs) fpid

Um die Auswirkungen der Cookie-Lebensdauern wie oben beschrieben zu berücksichtigen, können Sie stattdessen Ihre eigenen Geräte-IDs festlegen und verwalten. Weitere Informationen finden Sie im Leitfaden zu IDs von Erstanbieter-Geräten.

Abrufen der ECID und Region für den aktuellen Benutzer retrieve-ecid

Je nach Anwendungsfall gibt es zwei Möglichkeiten, auf die ECID zuzugreifen:

Abrufen der ECID durch die Datenvorbereitung für die Datenerfassung retrieve-ecid-data-prep

Verwenden Datenvorbereitung für die Datenerfassung um die ECID einem XDM zuzuordnen. Dies ist die empfohlene Methode für den Zugriff auf die ECID.

Legen Sie dazu das Quellfeld auf den folgenden Pfad fest:

xdm.identityMap.ECID[0].id

Legen Sie dann das Zielfeld auf einen XDM-Pfad fest, in dem das Feld vom Typ string ist.

Rufen Sie die ECID über den getIdentity()-Befehl ab retrieve-ecid-getidentity

Um die eindeutige ECID für den aktuellen Besucher abzurufen, verwenden Sie den getIdentity. Für erstmalige Besucherinnen und Besucher, die noch keine ECID haben, generiert dieser Befehl eine neue ECID. getIdentity gibt auch die Regions-ID für den Besucher zurück.

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.
  });

Abrufen der CORE-ID für den aktuellen Benutzer retrieve-coreid

Um die CORE-ID für einen Benutzer abzurufen, können Sie den getIdentity()-Befehl verwenden, wie unten dargestellt.

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

Verwenden identityMap using-identitymap

Mithilfe eines XDM-identityMap könnenein Gerät/einen Benutzer mithilfe mehrerer Identitäten identifizieren, seinen Authentifizierungsstatus festlegen und entscheiden, welche Kennung als die primäre Kennung betrachtet wird. Wenn keine Kennung als primary festgelegt wurde, ist standardmäßig die ECID die primäre Kennung.

identityMap Felder werden mithilfe des Befehls sentEvent aktualisiert.

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

Jede Eigenschaft in identityMap stellt Identitäten dar, die zu einem bestimmten Identity-Namespace). Der Eigenschaftsname sollte das Identity-Namespace-Symbol sein, das in der Benutzeroberfläche von Adobe Experience Platform unter „Identitäten​ aufgeführt ​. Der Eigenschaftswert sollte ein Array von Identitäten sein, die zu diesem Identity-Namespace gehören.

Jedes Identitätsobjekt im Identitäts-Array enthält die folgenden Eigenschaften:

Die Verwendung des Felds identityMap zur Identifizierung von Geräten oder Benutzern führt zum gleichen Ergebnis wie die Verwendung der setCustomerIDs Methode aus der ID Service API. Weitere Informationen finden Sie in der ID-ServiceAPI-Dokumentation .

Migration von der Besucher-API zu ECID migrating-visitor-api-ecid

Bei der Migration von mit der Besucher-API können Sie auch vorhandene AMCV-Cookies migrieren. Um die ECID-Migration zu aktivieren, legen Sie den idMigrationEnabled in der Konfiguration fest. Die ID-Migration ermöglicht die folgenden Anwendungsfälle:

Aktualisieren von Eigenschaften für die Migration

Wenn XDM-formatierte Daten an den Audience Manager gesendet werden, müssen diese Daten bei der Migration in Signale umgewandelt werden. Ihre Eigenschaften müssen aktualisiert werden, um die neuen Schlüssel widerzuspiegeln, die XDM bereitstellt. Dieser Prozess wird durch die Verwendung des BAAAM-Tools das der Audience Manager erstellt hat, erleichtert.

Verwendung bei der Ereignisweiterleitung

Wenn Sie derzeit Ereignisweiterleitung aktiviert haben und appmeasurement.js und visitor.js verwenden, können Sie die Ereignisweiterleitungsfunktion aktiviert lassen, was keine Probleme verursacht. Am Back-End ruft Adobe alle AAM-Segmente ab und fügt sie dem Aufruf an Analytics hinzu. Wenn der Aufruf an Analytics diese Segmente enthält, ruft Analytics den Audience Manager nicht auf, um Daten weiterzuleiten, sodass keine doppelte Datenerfassung erfolgt. Bei Verwendung der Web-SDK ist auch kein Standorthinweis erforderlich, da dieselben Segmentierungsendpunkte im Backend aufgerufen werden.