Anfordern und Festlegen von IDs durch den Experience Cloud Identity Service
Eine Übersicht über den ID-Anforderungs- und -Antwortprozess. Diese Beispiele decken die ID-Zuweisung auf individuellen Sites, Site-übergreifend und für durch verschiedene Experience Cloud-Kunden verwaltete Sites mit eigenen Kunden-IDs ab.
NOTEAnfordern einer Experience Cloud ID
In den folgenden Beispielen wird dargestellt, wie der ID-Service die Experience Cloud-Besucher-ID anfordert und erhält. Es wird anhand zweier fiktiver Unternehmen, „Food Company“ und „Sports Company“, erklärt, wie die Datenflüsse für ID-Anforderungen und -Antworten funktionieren. Jede Firma verfügt über eine eindeutige Experience Cloud-Organisations-ID und hat den ID-Service-Code auf allen ihren Sites implementiert. In diesen Anwendungsfällen werden die Datenströme für eine allgemeine ID-Service-Implementierung ohne Analytics, Legacy-IDs oder Drittanbieter-Cookies blockierende Browser dargestellt.
Erste Anfrage
In diesem Beispiel kommt ein neuer Besucher zur Pizza-Site, die von der Food Company verwaltet wird. Die Food Company hat auf der Pizza-Site ID-Service-Code implementiert. Beim Laden der Site wird vom ID-Dienst-Code das AMCV-Cookie in der Pizzadomäne gesucht.
- Ist das AMCV-Cookie gesetzt, verfügt der Site-Besucher über eine Experience Cloud ID. In diesem Fall verfolgt das Cookie den Besucher und teilt Daten mit anderen Experience Cloud-Lösungen.
- Wenn das AMCV-Cookie nicht gesetzt ist, ruft der ID-Servicecode einen regionalen Datenerfassungs-Server (DCS) unter
dpm.demdex.net/idauf (siehe auch Aufrufe an die Domain Demdex). Im Aufruf enthalten ist auch die Organisations-ID der Food Company. Die Organisations-ID wird in der FunktionVisitor.getInstancedes ID-Service-Codes festgelegt.
Erste Antwort
In der Antwort gibt der DES die Experience Cloud ID (MID) und den demdex-Cookie zurück. Der ID-Service-Code schreibt den MID-Wert in das AMCV-Cookie. Wenn der DES beispielswiese einen MID-Wert von 1234 zurückgibt, würde dieser als mid|1234 im AMCV-Cookie gespeichert und in der Erstanbieter-Pizzadomäne gesetzt werden. Das demdex-Cookie enthält auch eine eindeutige ID (nennen wir sie 5678). Dieses Cookie wird in der Drittanbieterdomäne „demdex.net“ gesetzt, die von der Pizzadomäne verschieden ist.
Wie Sie im nächsten Beispiel sehen werden, ermöglichen die demdex-ID und die Organisations-ID dem ID-Service, die richtige MID zu erstellen und zurückzugeben, wenn unser Besucher zu einer anderen Site wechselt, die zur Food Company gehört.
Site-übergreifende Anforderung und Antwort
In diesem Beispiel navigiert der Besucher der Food Company von der Pizza-Site zur Taco-Site. Die Food Company hat auf der Taco-Site ID-Service-Code implementiert. Der Besucher war noch nie auf der Taco-Website.
Unter diesen Bedingungen gibt es auf der Taco-Site kein AMCV-Cookie. Der ID-Service kann das auf der Pizza-Site festgelegte AMCV-Cookie nicht verwenden, da es spezifisch für die Pizzadomäne ist. Daher muss der ID-Service den DCS aufrufen, um eine Besucher-ID zu suchen und anzufordern. In diesem Fall enthält der DCS-Aufruf die Organisations-ID der Food Company und die demdex-ID. Denken Sie daran, dass die demdex-ID von der Pizza-Site abgerufen und als Drittanbieter-Cookie unter der Domain „demdex.net“ gespeichert wird.
Nachdem der DCS die Organisations-ID und die demdex-ID erhalten hat, wird die korrekte MID für unseren Site-Besucher erstellt und zurückgegeben. Da die mathematisch anhand der Organisations-ID und der demdex-ID ermittelt wird, enthält das AMCV-Cookie den MID-Wert mid = 1234.
ID-Anforderungen von anderen Sites
In diesem Beispiel verlässt der Besucher die Sites der Food Company und navigiert zur Fußball-Site, die der Sports Company gehört. Wenn der Besucher die Fußball-Site besucht, funktionieren die ID-Überprüfung und der Anforderungsprozess auf die gleiche Weise wie in den vorherigen Beispielen beschrieben. Da die Sports Company jedoch über eine eigene Organisations-ID verfügt, gibt der ID-Service eine andere MID zurück. Die neue MID ist für die von der Sports Company verwalteten Domänen eindeutig und ermöglicht es dem Unternehmen, Besucherdaten zu verfolgen und lösungsübergreifend in der Experience Cloud freizugeben. Die demdex-ID bleibt für den Besucher gleich, da sie in einem Drittanbieter-Cookie enthalten ist und domänenübergreifend fortbesteht.
