Einrichten von Analytics- und Experience Cloud IDs setting-analytics-and-experience-cloud-ids
Der Experience Cloud Identity Service 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 section-79bb86ae63f546419bb1a7ef5e710462
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 Domain noch nie zuvor besucht hat. Wenn Ihre Domain z. B. mysite.com ist und sich Ihr Datenerfassungsserver unter der Domain 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 Domain 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 Domain 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 Domain 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 Domain des Tracking-Servers muss dabei nicht mehr mit der Domain 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.
Benutzerdefinierte ID für Analytics section-b6a7bd19e9ff432390010062450808f6
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 section-de1dc9fc9b6d4388995b70e35b8bcddf
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):
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.
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.