Das Adobe Experience Platform Web SDK weist Adobe Experience Cloud IDs (ECIDs) Website-Besuchern durch die Verwendung von Cookies, um das Benutzerverhalten zu verfolgen. Um Browserbeschränkungen für Cookie-Lebenszyklen zu berücksichtigen, können Sie stattdessen Ihre eigenen Geräte-IDs festlegen und verwalten. Diese werden als First-Party-Geräte-IDs (FPIDs) bezeichnet.
Die Unterstützung der Erstanbieter-Geräte-ID ist nur verfügbar, wenn Daten über das Platform Web SDK an das Platform Edge Network gesendet werden.
In diesem Dokument wird beschrieben, wie Sie Erstanbieter-Geräte-IDs für Ihre Platform Web SDK-Implementierung konfigurieren.
In diesem Handbuch wird davon ausgegangen, dass Sie mit der Funktionsweise von Identitätsdaten für das Platform Web SDK vertraut sind, einschließlich der Rolle von ECIDs und identityMap
. Siehe Übersicht unter Identitätsdaten im Web SDK für weitere Informationen.
FPIDs verfolgen Besucher mithilfe von Erstanbieter-Cookies. Erstanbieter-Cookies sind am effektivsten, wenn sie mit einem Server gesetzt werden, der ein DNS nutzt Ein Datensatz (für IPv4) oder AAAA-Eintrag (für IPv6) im Gegensatz zu DNS-CNAME oder JavaScript-Code.
Datensätze oder AAAA-Einträge werden nur zum Setzen und Verfolgen von Cookies unterstützt. Die primäre Methode für die Datenerfassung ist ein DNS-CNAME. Anders ausgedrückt: FPIDs werden mit einem A-Datensatz oder AAAA-Datensatz festgelegt und dann mit einem CNAME an Adobe gesendet.
Die Adobe-Managed Certificate Program wird auch bei der Erstanbieter-Datenerfassung unterstützt.
Sobald ein FPID-Cookie gesetzt ist, kann der zugehörige Wert abgerufen und an Adobe gesendet werden, während Ereignisdaten erfasst werden. Erfasste FPIDs werden als Samen zur Generierung von ECIDs verwendet, die in Adobe Experience Cloud-Anwendungen weiterhin die primäre IDs sind.
Um eine FPID für einen Website-Besucher an das Platform Edge Network zu senden, müssen Sie die FPID in die identityMap
für diesen Besucher. Siehe Abschnitt weiter unten in diesem Dokument unter Verwenden von FPIDs in identityMap
für weitere Informationen.
Das Platform Edge Network akzeptiert nur IDs, die dem Format "UUIDv4". Geräte-IDs, die nicht im UUIDv4-Format vorliegen, werden abgelehnt.
Die Erstellung einer UUID führt fast immer zu einer eindeutigen, zufälligen ID, wobei die Wahrscheinlichkeit eines Zusammenstoßes vernachlässigbar ist. UUIDv4 kann nicht mit IP-Adressen oder anderen personenbezogenen Daten (PII) gesendet werden. UUIDs sind allgegenwärtig und es gibt Bibliotheken für praktisch jede Programmiersprache, um sie zu generieren.
Beim Festlegen eines Cookies mithilfe eines Servers, dessen Eigentümer Sie sind, können verschiedene Methoden eingesetzt werden, um zu verhindern, dass das Cookie aufgrund von Browserrichtlinien eingeschränkt wird:
Cookies, die mithilfe von JavaScript document.cookie
-Methode wird fast nie vor Browserrichtlinien geschützt, die die Cookie-Dauer einschränken.
Das FPID-Cookie sollte idealerweise gesetzt werden, bevor Anforderungen an das Edge-Netzwerk gesendet werden. In Fällen, in denen dies nicht möglich ist, wird jedoch eine ECID nach wie vor mit vorhandenen Methoden generiert und dient als primäre Kennung, solange das Cookie vorhanden ist.
Wenn die ECID schließlich von einer Richtlinie zum Löschen von Browsern beeinflusst wird, die FPID jedoch nicht, wird die FPID beim nächsten Besuch zur primären Kennung und wird zum Testen der ECID bei jedem nachfolgenden Besuch verwendet.
Das Festlegen des Ablaufs eines Cookies sollte bei der Implementierung der FPID-Funktion sorgfältig berücksichtigt werden. Bei dieser Entscheidung sollten Sie die Länder oder Regionen berücksichtigen, in denen Ihre Organisation tätig ist, sowie die Gesetze und Richtlinien in jeder dieser Regionen.
Im Rahmen dieser Entscheidung sollten Sie eine unternehmensweite Cookie-Einstellungsrichtlinie oder eine Richtlinie festlegen, die für Benutzer in jedem Gebietsschema, in dem Sie tätig sind, unterschiedlich ist.
Unabhängig von der Einstellung, die Sie für den anfänglichen Ablauf eines Cookies auswählen, müssen Sie sicherstellen, dass Sie eine Logik einschließen, die den Ablauf des Cookies bei jedem neuen Besuch der Site verlängert.
Es gibt eine Vielzahl von Cookie-Flags, die sich auf die Behandlung von Cookies in verschiedenen Browsern auswirken:
HTTPOnly
Cookies, die mithilfe der Variablen HTTPOnly
kann nicht mit clientseitigen Skripten aufgerufen werden. Das bedeutet, dass Sie HTTPOnly
Flag beim Festlegen der FPID müssen Sie eine serverseitige Skriptsprache verwenden, um den Cookie-Wert zur Aufnahme in die identityMap
.
Wenn Sie sich dafür entscheiden, das Platform Edge Network den Wert des FPID-Cookies lesen zu lassen, legen Sie die HTTPOnly
-Markierung stellt sicher, dass der Wert von keinem clientseitigen Skript aufgerufen werden kann, hat jedoch keine negativen Auswirkungen auf die Fähigkeit des Platform Edge Network, das Cookie zu lesen.
Verwendung der HTTPOnly
hat keine Auswirkungen auf die Cookie-Richtlinien, die die Lebensdauer von Cookies einschränken können. Sie sollten dies jedoch dennoch berücksichtigen, während Sie den Wert der FPID festlegen und lesen.
Secure
Cookies, die mit dem Secure
-Attribut wird nur mit einer verschlüsselten Anfrage über das HTTPS-Protokoll an den Server gesendet. Die Verwendung dieses Flag kann dazu beitragen, dass man-in-the-Middle-Angreifer nicht einfach auf den Wert des Cookies zugreifen können. Wenn möglich, ist es immer empfehlenswert, die Secure
Markierung.
SameSite
Die SameSite
-Attribut können Server bestimmen, ob Cookies mit Site-übergreifenden Anforderungen gesendet werden. Das -Attribut bietet einen gewissen Schutz vor Site-übergreifenden Fälschungsangriffen. Es gibt drei mögliche Werte: Strict
, Lax
und None
. Wenden Sie sich an Ihr internes Team, um zu bestimmen, welche Einstellung für Ihre Organisation geeignet ist.
Wenn nicht SameSite
-Attribut festgelegt ist, ist die Standardeinstellung für einige Browser jetzt SameSite=Lax
.
identityMap
Im Folgenden finden Sie ein Beispiel dafür, wie Sie eine FPID auf ihrer eigenen im identityMap
:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
Wie bei anderen Identitätstypen können Sie die FPID mit anderen Identitäten in identityMap
. Im Folgenden finden Sie ein Beispiel der FPID, die mit einer authentifizierten CRM-ID enthalten ist:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Wenn die FPID in einem Cookie enthalten ist, das vom Edge Network gelesen wird, wenn die Erstanbieter-Datenerfassung aktiviert ist, sollten Sie nur die authentifizierte CRM-ID erfassen:
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Die folgenden identityMap
zu einer Fehlerantwort des Edge-Netzwerks führen, da das primary
Indikator für die FPID. Mindestens eine der IDs in identityMap
muss als primary
.
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"authenticatedState": "ambiguous"
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated"
}
]
}
}
Die vom Edge Network zurückgegebene Fehlerantwort würde in diesem Fall der folgenden ähneln:
{
"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}"
}
}
Wenn sowohl eine ECID als auch eine FPID vorhanden sind, wird die ECID bei der Identifizierung des Benutzers priorisiert. Dadurch wird sichergestellt, dass eine vorhandene ECID, die im Browser-Cookie-Store vorhanden ist, weiterhin die primäre Kennung ist und die vorhandenen Besucherzahlen keine Auswirkungen haben. Für bestehende Benutzer wird die FPID erst dann zur primären Identität, wenn die ECID abläuft oder infolge einer Browserrichtlinie oder eines manuellen Prozesses gelöscht wird.
Identitäten werden in der folgenden Reihenfolge priorisiert:
identityMap
identityMap
Wenn Sie zur Verwendung von FPIDs aus einer früheren Implementierung migrieren, ist es möglicherweise schwierig, sich vorzustellen, wie die Transition auf einer niedrigen Ebene aussehen könnte.
Um diesen Vorgang zu veranschaulichen, sollten Sie sich ein Szenario ansehen, an dem ein Kunde beteiligt ist, der Ihre Site bereits besucht hat, und welche Auswirkungen eine FPID-Migration auf die Identifizierung dieses Kunden in Adobe-Lösungen haben würde.
Die ECID
-Cookie wird immer priorisiert über die FPID
.
Besuch | Beschreibung |
---|---|
Erster Besuch | Angenommen, Sie haben noch nicht mit dem Setzen des FPID-Cookies begonnen. Die ECID im AMCV-Cookie ist die Kennung, die zur Identifizierung des Besuchers verwendet wird. |
Zweiter Besuch | Der Rollout der Erstanbieter-Geräte-ID-Lösung wurde gestartet. Die vorhandene ECID ist weiterhin vorhanden und weiterhin die primäre Kennung für die Besucheridentifizierung. |
Dritter Besuch | Zwischen dem zweiten und dritten Besuch hat ausreichend Zeit verstrichen, dass die ECID aufgrund einer Browserrichtlinie gelöscht wurde. Da die FPID jedoch mithilfe eines DNS-A-Eintrags festgelegt wurde, bleibt die FPID bestehen. Die FPID wird jetzt als primäre ID betrachtet und zum Testen der ECID verwendet, die auf das Endbenutzergerät geschrieben wird. Der Benutzer wird nun als neuer Besucher in den Adobe Experience Platform- und Experience Cloud-Lösungen betrachtet. |
Vierter Besuch | Zwischen dem dritten und vierten Besuch hat ausreichend Zeit verstrichen, dass die ECID aufgrund der Browserrichtlinie gelöscht wurde. Wie beim vorherigen Besuch bleibt die FPID aufgrund der Art und Weise, wie sie festgelegt wurde. Diesmal wird dieselbe ECID wie beim vorherigen Besuch generiert. Der Benutzer wird in den Experience Platform- und Experience Cloud-Lösungen als derselbe Benutzer wie beim vorherigen Besuch gesehen. |
Fünfter Besuch | Zwischen dem vierten und fünften Besuch hat der Endbenutzer alle Cookies in seinem Browser gelöscht. Eine neue FPID wird generiert und zum Testen der Erstellung einer neuen ECID verwendet. Der Benutzer wird nun als neuer Besucher in den Adobe Experience Platform- und Experience Cloud-Lösungen betrachtet. |
Im Folgenden finden Sie eine Liste von Antworten auf häufig gestellte Fragen zu Erstanbieter-Geräte-IDs.
Das Sitzungskonzept ist insofern eindeutig, als die an Adobe Experience Cloud übergebene FPID mithilfe eines deterministischen Algorithmus in eine ECID konvertiert wird. Jedes Mal, wenn dieselbe FPID an das Adobe Experience Platform Edge Network gesendet wird, wird dieselbe ECID von der FPID gesendet.
Um die potenzielle Besucherinflation zu reduzieren, sollte die FPID generiert werden, bevor Sie Ihre erste Anfrage mit dem Platform Web SDK stellen. Wenn Sie dies jedoch nicht tun können, wird für diesen Benutzer weiterhin eine ECID generiert und als primäre Kennung verwendet. Die generierte FPID wird erst dann zur primären Kennung, wenn die ECID nicht mehr vorhanden ist.
Derzeit unterstützt nur das Platform Web SDK FPIDs.
Sobald die FPID zum Testen einer ECID verwendet wurde, wird sie aus dem identityMap
und durch die generierte ECID ersetzt. Die FPID wird nicht in Adobe Experience Platform- oder Experience Cloud-Lösungen gespeichert.