IDs von Erstanbieter-Geräten in Web SDK
Adobe Experience Platform Web SDK weist Website-Besuchern mithilfe von Cookies Adobe Experience Cloud-IDs (ECIDs zu, um das Benutzerverhalten zu verfolgen. Um Browser-Einschränkungen hinsichtlich der Cookie-Lebensdauer 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.
Sie können entweder Erstanbieter-Geräte-IDs verwenden oder Drittanbieter-Cookies verwenden. Sie können jedoch nicht beide Funktionen gleichzeitig verwenden.
In diesem Dokument wird erläutert, wie Erstanbieter-Geräte-IDs für Ihre Web SDK-Implementierung konfiguriert werden.
Voraussetzungen
In diesem Handbuch wird davon ausgegangen, dass Sie mit der Funktionsweise von Identitätsdaten für Platform Web SDK vertraut sind, einschließlich der Rolle von ECIDs und identityMap
. Weitere Informationen finden Sie in der Übersicht Identitätsdaten in der WebSDK) .
Verwenden von First-Party-Geräte-IDs (FPIDs) using-fpid
Erstanbieter-Geräte-IDs (FPIDs) verfolgen Besucher mithilfe von Erstanbieter-Cookies. Erstanbieter-Cookies sind am effektivsten, wenn sie mit einem Server gesetzt werden, der einen DNS-A-Eintrag (für IPv4) oder AAAA-Eintrag (für IPv6) im Gegensatz zu einem DNS-CNAME oder JavaScript-Code verwendet.
Sobald ein FPID Cookie gesetzt wurde, kann sein Wert abgerufen und bei der Erfassung von Ereignisdaten an Adobe gesendet werden. Die erfassten FPIDs werden als Testadressen verwendet, um ECIDs zu generieren, die weiterhin die primären IDs in Adobe Experience Cloud-Programmen sind.
Um eine FPID für einen Website-Besucher an das Edge Network zu senden, müssen Sie die FPID in die identityMap
für diesen Besucher einschließen. Weitere Informationen finden Sie im Abschnitt weiter unten in diesem Dokument Verwenden von FPIDs in identityMap
.
Formatierungsanforderungen für First-Party-Geräte-IDs formatting-requirements
Das 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, dass eine Kollision auftritt, vernachlässigbar ist. UUIDv4 können nicht mit IP-Adressen oder anderen personenbezogenen Daten (PII) gesendet werden. UUIDs sind allgegenwärtig und Bibliotheken können für praktisch jede Programmiersprache gefunden werden, um sie zu erzeugen.
Festlegen eines Erstanbieter-ID-Cookies in der Datenstrom-Benutzeroberfläche setting-cookie-datastreams
Sie können einen Cookie-Namen in der Datenstrom-Benutzeroberfläche angeben, in dem sich der FPID befinden kann, anstatt den Cookie-Wert lesen und den FPID in die Identitätszuordnung einschließen zu müssen.
Siehe Dokumentation zu Datenströmen für detaillierte Informationen zur Konfiguration eines Datenstroms.
Aktivieren Sie beim Konfigurieren Ihres Datenstroms die Option Erstanbieter-ID-Cookie . Diese Einstellung weist das Edge Network an, bei der Suche nach einer First-Party-Geräte-ID ein bestimmtes Cookie zu verwenden, anstatt nach diesem Wert in der Identitätszuordnung.
Weitere Informationen zur Funktionsweise Erstanbieter-Cookies findenin der Dokumentation zu Adobe Experience Cloud .
Wenn Sie diese Einstellung aktivieren, müssen Sie den Namen des Cookies angeben, in dem die ID gespeichert ist.
Wenn Sie Erstanbieter-IDs verwenden, können Sie keine ID-Synchronisierungen von Drittanbietern durchführen. ID-Synchronisierungen von Drittanbietern basieren auf dem Visitor ID-Service und den von diesem Service generierten UUID
. Bei Verwendung der ID-Funktion von Erstanbietern wird die ECID ohne Verwendung des Visitor ID-Service generiert, was die Synchronisierung von Drittanbieter-IDs unmöglich macht.
Wenn Sie Erstanbieter-IDs verwenden, werden Audience Manager-Funktionen, die auf die Aktivierung in Partnerplattformen abzielen, nicht unterstützt, da die Synchronisierung der Audience Manager-Partner-IDs größtenteils auf UUIDs
oder DIDs
basiert. Die von einer Erstanbieter-ID abgeleitete ECID ist nicht mit einer UUID
verknüpft, sodass sie nicht adressierbar ist.
Setzen eines Cookies mit Ihrem eigenen Server set-cookie-server
Beim Setzen eines Cookies mit einem Server, dessen Eigentümer Sie sind, können Sie verschiedene Methoden verwenden, um zu verhindern, dass das Cookie aufgrund von Browser-Richtlinien eingeschränkt wird:
- Generieren von Cookies mithilfe von Server-seitigen Skriptsprachen
- Setzen von Cookies als Reaktion auf eine API-Anfrage an eine Subdomain oder einen anderen Endpunkt auf der Website
- Generieren von Cookies mithilfe eines CMS
- Generieren von Cookies mithilfe eines CDN
document.cookie
-Methode von JavaScript gesetzt werden, sind fast nie vor Browser-Richtlinien geschützt, die die Cookie-Dauer beschränken.Wann das Cookie gesetzt werden soll when-to-set-cookie
Das FPID-Cookie sollte idealerweise gesetzt werden, bevor Anfragen an das Edge Network gesendet werden. In Fällen, in denen dies nicht möglich ist, wird jedoch weiterhin ein ECID mit vorhandenen Methoden generiert und fungiert als primäre Kennung, solange das Cookie vorhanden ist.
Angenommen, die ECID ist letztendlich von einer Browser-Löschrichtlinie betroffen, die FPID jedoch nicht, wird die FPID beim nächsten Besuch zur primären Kennung und wird zum Seed der ECID bei jedem nachfolgenden Besuch verwendet.
Einstellen des Ablaufs für das Cookie set-expiration
Das Setzen des Ablaufs eines Cookies sollte bei der Implementierung der FPID sorgfältig berücksichtigt werden. Bei der 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 möglicherweise eine unternehmensweite Cookie-Setzungsrichtlinie oder eine Richtlinie einführen, die für die Benutzer in jedem Gebietsschema, in dem Sie tätig sind, variiert.
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 jedes Mal verlängert, wenn eine neue Website besucht wird.
Auswirkungen von Cookie-Flags cookie-flag-impact
Es gibt verschiedene Cookie-Flags, die sich darauf auswirken, wie Cookies in verschiedenen Browsern behandelt werden:
HTTPOnly
http-only
Auf Cookies, die mit dem HTTPOnly
-Flag gesetzt werden, kann nicht über Client-seitige Skripte zugegriffen werden. Wenn Sie also beim Festlegen der FPID ein HTTPOnly
-Flag festlegen, müssen Sie eine Server-seitige Skriptsprache verwenden, um den Cookie-Wert zur Aufnahme in die identityMap
zu lesen.
Wenn Sie möchten, dass das Edge Network den Wert des FPID Cookies liest, wird durch das Setzen des HTTPOnly
-Flags sichergestellt, dass Client-seitige Skripte nicht auf den Wert zugreifen können, jedoch keine negativen Auswirkungen auf die Fähigkeit des Edge Networks haben, das Cookie zu lesen.
HTTPOnly
-Flags hat keine Auswirkungen auf die Cookie-Richtlinien, die die Cookie-Lebensdauer einschränken können. Sie sollten dies jedoch berücksichtigen, wenn Sie den Wert der FPID festlegen und lesen.Secure
secure
Cookies, die mit dem Secure
-Attribut gesetzt werden, werden nur mit einer verschlüsselten Anfrage über das HTTPS-Protokoll an den Server gesendet. Die Verwendung dieser Markierung kann sicherstellen, dass für Man-in-the-Middle-Angreifer kein einfacher Zugriff auf den Wert des Cookies möglich ist. Wenn möglich, ist es immer eine gute Idee, die Secure
Flag zu setzen.
SameSite
same-site
Mit dem Attribut SameSite
können Server bestimmen, ob Cookies mit Site-übergreifenden Anfragen gesendet werden. Das -Attribut bietet einen gewissen Schutz vor Cross-Site-Forgery-Angriffen. Es gibt drei mögliche Werte: Strict
, Lax
und None
. Besprechen Sie mit Ihrem internen Team, welche Einstellung für Ihr Unternehmen am besten geeignet ist.
Wenn kein SameSite
-Attribut angegeben ist, ist die Standardeinstellung für einige Browser jetzt SameSite=Lax
.
Verwenden von FPIDs in identityMap
identityMap
Im Folgenden finden Sie ein Beispiel dafür, wie Sie ein FPID im identityMap
festlegen:
{
"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
einbeziehen. Im Folgenden finden Sie ein Beispiel für die FPID, die in einem authentifizierten CRM ID enthalten sind:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": false
}
],
"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 authentifizierten CRM ID erfassen:
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Das folgende identityMap
würde zu einer Fehlerantwort des Edge Networks führen, da es nicht den primary
für die FPID enthält. Mindestens eine der in identityMap
vorhandenen IDs muss als primary
markiert sein.
{
"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}"
}
}
Festlegen einer FPID in Ihrer eigenen Domain setting-fpid-domain
Sie können nicht nur den FPID in der Identitätszuordnung festlegen, sondern auch das FPID-Cookie in Ihrer eigenen Domain, wenn Sie eine Erstanbieter-Datenerfassung konfiguriert CNAME.
Wenn die Erstanbieter-Datenerfassung mithilfe eines CNAME aktiviert ist, werden alle Cookies für Ihre Domain bei Anfragen an den Datenerfassungsendpunkt gesendet.
Alle Cookies, die für die Datenerfassung der Adobe nicht relevant sind, werden gelöscht. Sie können FPID den Namen des FPID-Cookies in der Datenstromkonfiguration angeben. In diesem Fall liest das Edge Network den Inhalt des FPID-Cookies, anstatt nach dem FPID in der Identitätszuordnung zu suchen.
Um diese Funktion verwenden zu können, müssen Sie die FPID auf der obersten Ebene Ihrer Domain anstatt einer bestimmten Subdomain festlegen. Wenn Sie ihn für eine Subdomain festlegen, wird der Cookie-Wert nicht an das Edge Network gesendet und die FPID Lösung funktioniert nicht wie beabsichtigt.
ID-Hierarchie id-hierarchy
Wenn sowohl ein ECID als auch ein FPID vorhanden sind, wird der ECID bei der Identifizierung des Benutzers priorisiert. Dadurch wird sichergestellt, dass eine vorhandene ECID im Browser-Cookie-Speicher vorhanden ist, die primäre Kennung bleibt und die Anzahl vorhandener Besucher nicht beeinträchtigt wird. Für bestehende Benutzer wird die FPID erst dann zur primären Identität, wenn die ECID abläuft oder als Ergebnis einer Browser-Richtlinie oder eines manuellen Prozesses gelöscht wird.
Identitäten werden in der folgenden Reihenfolge priorisiert:
- In der
identityMap
enthaltene ECID - In einem Cookie gespeicherte ECID
- In der
identityMap
enthaltene FPID - In einem Cookie gespeicherte FPID
Migrieren zu First-Party-Geräte-IDs migrating-to-fpid
Wenn Sie von einer früheren Implementierung zu Erstanbieter-Geräte-IDs migrieren, kann es schwierig sein, sich ein Bild davon zu machen, wie die Transition auf niedriger Ebene aussehen könnte.
Zur Veranschaulichung dieses Prozesses sollten Sie sich ein Szenario ansehen, in dem ein Kunde involviert ist, der bereits Ihre Site besucht hat, und welche Auswirkungen eine FPID auf die Art und Weise hätte, wie dieser Kunde in Adobe-Lösungen identifiziert wird.
ECID
-Cookie hat immer Vorrang vor dem FPID
.Häufig gestellte Fragen faq
Im Folgenden finden Sie eine Liste von Antworten auf häufig gestellte Fragen zu Erstanbieter-Geräte-IDs.
Inwiefern unterscheidet sich das Seeding einer ID vom einfachen Generieren einer ID?
Das Seeding-Konzept ist insofern einzigartig, als die an Adobe Experience Cloud übergebene FPID mithilfe eines deterministischen Algorithmus in eine ECID konvertiert wird. Jedes Mal, wenn derselbe FPID an das Edge Network gesendet wird, wird derselbe ECID vom FPID gesendet.
Wann soll die First-Party-Geräte-ID generiert werden?
Um die mögliche Besucherinflation zu reduzieren, sollte die FPID vor der ersten Anfrage mit dem Web SDK generiert werden. Wenn Sie dies nicht tun können, wird dennoch eine ECID für diesen Benutzer generiert und als primäre Kennung verwendet. Die generierte FPID wird erst dann zur primären Kennung, wenn die ECID nicht mehr vorhanden ist.
Welche Datenerfassungsmethoden unterstützen First-Party-Geräte-IDs?
Derzeit unterstützt nur Web SDK IDs von Erstanbieter-Geräten.
Werden First-Party-Geräte-IDs auf beliebigen Platform- oder Experience Cloud-Lösungen gespeichert?
Nachdem der FPID zum Seed eines ECID verwendet wurde, wird er aus dem identityMap
gelöscht und durch den generierten ECID ersetzt. Das FPID wird in keiner Adobe Experience Platform- oder Experience Cloud-Lösung gespeichert.