Show Menu
TOPICS×

Einrichten von Analytics- und Experience Cloud IDs

Der Experience Cloud Identity-Dienst ersetzt die Legacy ID-Methoden für Analytics.
Nach der Implementierung des ID-Diensts wird dieser Code vor AppMeasurement ausgeführt. Der ID-Dienst ruft die Experience Cloud IDs und Analytics-IDs ab, damit diese Werte beim Laden von AppMeasurement verfügbar sind.
Beim Laden von AppMeasurement werden die Werte für Experience Cloud IDs und Analytics-IDs vom ID-Dienst angefordert und mit jedem Server-Aufruf an die Datenerfassung gesendet. Da der ID-Dienst die Besucher-ID bestimmt und sie einfach an AppMeasurement übergibt, muss der ID-Dienst auf jeder Seite vor Ihrer AppMeasurement-JavaScript-Datei eingebunden und implementiert werden.

Änderungen beim ID-Vorgang für Analytics

Die wesentliche Änderung bei der Migration auf den Experience Cloud ID-Dienst besteht darin, dass das ID-Cookie nun mit JavaScript gesetzt wird und nicht mehr im HTTP-Header, der vom Datenerfassungs-Webserver zurückgegeben wird. Um diese Änderung zu verstehen, wird in den folgenden Abschnitten beschrieben, wie Cookies mithilfe dieser beiden Methoden gesetzt werden.
HTTP-Header
Eine HTTP-Antwort eines Webservers setzt Cookies in einem Browser. So wird das
s_vi
-Cookie gesetzt. Mit dem
s_vi
-Cookie werden Analytics-Besucher identifiziert. Nachdem ein Cookie gesetzt wurde, wird es mit allen nachfolgenden HTTP-Anforderungen an den Server gesendet.
Wenn eine Anforderung an den Adobe-Datenerfassungsserver gesendet wird, wird geprüft, ob der Header einen
s_vi
-Cookie enthält. Wenn der Cookie in der Anforderung enthalten ist, wird er zur Identifizierung des Besuchers verwendet. Wenn der Cookie nicht in der Anforderung enthalten ist, generiert der Server eine eindeutige Experience Cloud ID, setzt sie als Cookie im HTTP-Antwort-Header und sendet diesen mit der Anforderung zurück. Das Cookie wird im Browser gespeichert und bei nachfolgenden Besuchen der Site an den Datenerfassungs-Server zurückgesendet. Dadurch kann der Besucher besuchsübergreifend identifiziert werden.
Einige Browser wie Apple Safari akzeptieren jedoch keine Drittanbieter-Cookies. Hierbei handelt es sich um Cookies, die im Browser von anderen Domänen als der aktuellen Website gesetzt werden. Zusätzlich blockiert Safari Cookies auf Drittanbieterdomänen, wenn ein Besucher diese Domäne noch nie zuvor besucht hat. Wenn Ihre Domäne z. B.
mysite.com
ist und sich Ihr Datenerfassungsserver unter der Domäne
mysite.omtrdc.net
befindet, wird der von
mysite.omtrdc.net
im HTTP-Header zurückgegebene Cookie möglicherweise vom Browser abgewiesen.
Damit dies umgangen werden kann, haben viele Kunden CNAME-Einträge für ihre Datenerfassungsserver implementiert. Dies kann ein effektiver Bestandteil einer Erstanbieter-Cookie-Implementierungsstrategie sein. Wenn ein CNAME-Eintrag so konfiguriert wurde, dass ein Hostname unter der Domäne des Kunden einem Datenerfassungsserver zugeordnet wird (z. B. die Zuordnung von
metrics.mysite.com
zu
mysite.omtrdc.net
), wird das Experience Cloud ID-Cookie gespeichert, da die Datenerfassungsdomäne nun mit der Domäne der Website übereinstimmt. Somit erhöht sich die Wahrscheinlicheit, dass das Cookie des ID-Diensts gespeichert wird. Auf der anderen Seite verursacht diese Strategie Zusatzaufwand, da CNAME-Einträge erstellt und SSL-Zertifikate der Datenerfassungsserver gepflegt werden müssen.
JavaScript
JavaScript kann in der Erstanbieterdomäne (der Domäne der aktuellen Website) gesetzte Cookies lesen und schreiben. Der Experience Cloud ID-Dienst verwendet diese Methode, um den Cookie
AMCV_###@AdobeOrg
zu setzen, der sämtliche Besucher-IDs enthält. Die Domäne des Tracking-Servers muss dabei nicht mehr mit der Domäne der Website übereinstimmen, damit der Besucher-ID-Cookie gespeichert wird. In den meisten Fällen ist dies die bevorzugte Methode zum Setzen des ID-Dienst-Cookies, da dadurch der Mehraufwand für CNAME-Einträge und SSL-Zertifikate entfällt.
Es gibt jedoch einige Situationen, in denen das Setzen des Cookies im HTTP-Header für das domänenübergreifende Tracking Vorteil ist. Dies wird unter Datenerfassungs-CNAMEs und domänenübergreifendes Tracking beschrieben.

Benutzerdefinierte ID für Analytics

In Analytics können Besucher identifiziert werden, indem eine Kunden-ID mit
s.visitorID
festgelegt wird. Integrationen jedoch, bei denen Daten mithilfe des ID-Dienstes aus Analytics exportiert oder in die Anwendung importiert werden, funktionieren nicht, wenn ein Besucher mithilfe von
s.visitorID
.
Hierzu gehören unter anderem gemeinsam genutzte Zielgruppen, Analytics for Target (A4T) und Kundenattribute. Bei diesen Integrationen wird die Festlegung einer benutzerdefinierten Analytics ID nicht unterstützt.

Reihenfolge für Analytics-Besucher-IDs

Nach der Bereitstellung des Besucher-ID-Diensts gibt es fünf Möglichkeiten, einen Besucher in Analytics zu identifizieren (in der folgenden Tabelle in der bevorzugten Reihenfolge aufgeführt):
Verwendete Reihenfolge
Abfrageparameter (Erfassungsmethode)
Vorhanden, wenn
s.visitorID festgelegt ist.
der Besucher bereits über ein s_vi-Cookie verfügte, bevor Sie den
Experience Cloud
ID-Dienst einsetzten, oder Sie haben eine Übergangsphase konfiguriert.
mid (AMCV_-Cookie, das vom Experience Cloud-Besucher-ID-Dienst gesetzt wird)
der Browser des Besuchers Erstanbieter-Cookies akzeptiert.
Ein Browser akzeptiert keine Drittanbietercookies, und der Analytics-Tracking-Server ist als ein Drittanbieter-Tracking-Server eingerichtet.
Hinweis: Das
fid
ist eine Legacy-ID und wird nicht verwendet, wenn Sie den ID-Dienst auf Ihrer Website implementiert haben. In diesem Fall wird
fid
nicht benötigt, da das Erstanbieter- AMCV-Cookie es obsolet macht. Es wurde für die Unterstützung von altem Code und aus Verlaufsgründen beibehalten.
der Browser des Besuchers keine Cookies akzeptiert.
In vielen Szenarios können für einen Aufruf zwei oder drei verschiedene IDs vorliegen. Analytics verwendet jedoch die erste ID in der Liste als offizielle Experience Cloud ID. Wenn Sie beispielsweise eine benutzerspezifische Besucher-ID festlegen (die im vid-Abfrageparameter enthalten ist), wird diese ID bevorzugt vor anderen IDs verwendet, die möglicherweise für denselben Treffer vorliegen.