Identitätsdaten in Web SDK

Das 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 über mehrere Sitzungen hinweg bestehen bleiben kann, wobei alle Treffer, die während und über mehrere Websitzungen hinweg auftreten, an ein bestimmtes Gerät gebunden werden.

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

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

Das Web SDK weist ECIDs mithilfe von Cookies zu und verfolgt sie nach, wobei mehrere verfügbare Methoden zum Konfigurieren der Erstellung dieser Cookies verfügbar sind.

Wenn ein neuer Benutzer auf Ihre Website gelangt, versucht der Adobe Experience Cloud Identity Service, ein Identifizierungs-Cookie für den betreffenden Benutzer zu setzen.

Nachdem das Cookie mit dem ECID gesetzt wurde, enthält jede nachfolgende vom Web SDK generierte Anforderung einen kodierten ECID im kndctr_{YOUR-ORG-ID}_AdobeOrg_identity -Cookie.

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

Wie in den folgenden Abschnitten erläutert, wirkt sich die von Ihnen gewählte Datenerfassungsmethode direkt auf die Cookie-Lebensdauer in allen Browsern aus.

Tracking von CORE-IDs mit dem 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, durchläuft die erste Edge Network-Anfrage eine demdex.net -Domäne, die einen demdex-Cookie setzt. Dieses Cookie enthält einen CORE ID. Dies ist eine eindeutige Benutzer-ID, die sich von der ECID unterscheidet.

Abhängig von Ihrer Implementierung können Sie auf den CORE ID zugreifen.

Erstanbieter-Datenerfassung first-party

Die Datenerfassung von Erstanbietern umfasst das Setzen von Cookies über eine CNAME in Ihrer eigenen Domäne, die auf adobedc.net verweist.

Während Browser Cookies, die von CNAME -Endpunkten gesetzt werden, seit langem ähnlich wie von Site-eigenen Endpunkten behandeln, haben jüngste, von Browsern implementierte Änderungen eine Unterscheidung in der Handhabung von CNAME -Cookies geschaffen. Es gibt zwar keine Browser, die standardmäßig Erstanbieter-Cookies vom Typ CNAME blockieren, aber einige Browser beschränken die Lebensdauer von Cookies, die mit dem Wert CNAME gesetzt werden, auf nur sieben Tage.

Datenerfassung von Drittanbietern third-party

Die Datenerfassung von Drittanbietern beinhaltet das direkte Senden von Daten an die Edge Network-Domäne adobedc.net.

In den letzten Jahren haben die Webbrowser bei der Behandlung von Cookies, die von Dritten gesetzt werden, immer restriktiver werden. Einige Browser blockieren standardmäßig Drittanbieter-Cookies. Wenn Sie zur Identifizierung von Site-Besuchern Drittanbieter-Cookies verwenden, ist die Lebensdauer dieser Cookies fast immer kürzer, als dies sonst durch Erstanbieter-Cookies möglich wäre. Manchmal läuft ein Drittanbieter-Cookie in nur sieben Tagen ab.

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

Auswirkungen von Cookie-Lebenszyklen auf Adobe Experience Cloud-Anwendungen lifespans

Unabhängig davon, ob Sie die Datenerfassung von Erstanbietern oder Drittanbietern auswählen, hat die Dauer, die ein Cookie beibehalten werden kann, direkte Auswirkungen auf die Besucherzahlen in Adobe Analytics und Customer Journey Analytics. Außerdem kann es bei Endbenutzern zu inkonsistenten Personalisierungserlebnissen kommen, wenn Adobe Target oder Offer decisioning auf der Site verwendet werden.

Angenommen, Sie haben ein Personalisierungs-Erlebnis erstellt, das jedes Element auf die Startseite weiterleitet, wenn ein Benutzer es in den letzten sieben Tagen dreimal angesehen hat.

Wenn ein Endbenutzer die Site dreimal in einer Woche besucht und dann sieben Tage lang nicht erneut aufruft, kann dieser Benutzer bei seiner Rückkehr zur Site als neuer Benutzer gelten, da seine Cookies möglicherweise von einer Browserrichtlinie gelöscht wurden (je nach dem Browser, den er bei seinem Besuch auf der Site verwendet hat). In diesem Fall behandelt Ihr Analytics-Tool den Besucher als neuen Benutzer, auch wenn er die Site vor etwas mehr als sieben Tagen besucht hat. Außerdem beginnt jeder Versuch, das Erlebnis für den Benutzer zu personalisieren, erneut.

Erstanbieter-Geräte-IDs (FPIDs) fpid

Um die oben beschriebenen Auswirkungen von Cookie-Lebenszyklen 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 der Region für den aktuellen Benutzer retrieve-ecid

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

Abrufen des ECID über die Datenvorbereitung für die Datenerfassung retrieve-ecid-data-prep

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

Setzen Sie dazu das Quellfeld auf den folgenden Pfad:

xdm.identityMap.ECID[0].id

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

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

Verwenden Sie den Befehl getIdentity , um die eindeutige ECID für den aktuellen Besucher abzurufen. Für erstmalige Besucher, die noch nicht über "ECID" verfügen, 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 Befehl getIdentity() verwenden, wie unten dargestellt.

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

Verwenden identityMap using-identitymap

Mithilfe eines XDM identityMap-Feldskönnen Sie ein Gerät/einen Benutzer anhand mehrerer Identitäten identifizieren, seinen Authentifizierungsstatus festlegen und entscheiden, welche Kennung als die primäre ID gilt. Wenn keine Kennung als primary festgelegt wurde, ist die primäre Standardeinstellung die ECID.

identityMap -Felder werden mit dem Befehl sentEvent aktualisiert.

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

Jede Eigenschaft innerhalb von identityMap stellt Identitäten dar, die zu einem bestimmten Identitäts-Namespace gehören. Der Eigenschaftsname sollte das Identitäts-Namespace-Symbol sein, das Sie in der Adobe Experience Platform-Benutzeroberfläche unter "Identitäten"finden. Der Eigenschaftswert sollte ein Array von Identitäten sein, die sich auf diesen Identitäts-Namespace beziehen.

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

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

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

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

Eigenschaften für die Migration aktualisieren

Wenn XDM-formatierte Daten an Audience Manager gesendet werden, müssen diese Daten bei der Migration in Signale konvertiert werden. Ihre Eigenschaften müssen aktualisiert werden, um die neuen Schlüssel widerzuspiegeln, die XDM bereitstellt. Dieser Vorgang wird durch die Verwendung des von Audience Manager erstellten BAAAM-Tools vereinfacht.

Verwendung in der Ereignisweiterleitung

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