Analyse- en Experience Cloud-id's instellen setting-analytics-and-experience-cloud-ids
De identiteitsservice van Experiencen Cloud vervangt de oude ID-methoden van Analytics-bezoekers.
Nadat de dienst van identiteitskaart wordt uitgevoerd, voert deze code vóór AppMeasurement uit. De dienst van identiteitskaart wint het Experience Cloud en Analytics IDs terug zodat zijn deze waarden klaar wanneer het AppMeasurement laadt.
Wanneer het AppMeasurement laadt, worden de waarden van Experience Cloud en van Analytics IDs gevraagd van de dienst van identiteitskaart en verzonden naar gegevensinzameling met elke servervraag. Aangezien de id-service de bezoeker-id bepaalt en deze gewoon doorgeeft aan het AppMeasurement, moet de id-service op elke pagina worden opgenomen en geïmplementeerd voordat het JavaScript-bestand van het AppMeasurement wordt verzonden.
Wijzigingen in het proces Analytics ID section-79bb86ae63f546419bb1a7ef5e710462
De belangrijkste wijziging bij het migreren naar de Experience Cloud ID-service is dat het ID-cookie wordt ingesteld met JavaScript in plaats van in de HTTP-header die wordt geretourneerd van de webserver voor gegevensverzameling. Om deze wijziging te begrijpen, wordt in de volgende secties beschreven hoe cookies met deze twee methoden worden ingesteld.
Kopbal van HTTP
Een HTTP-reactie van een webserver stelt cookies in een browser in. Zo wordt het cookie s_vi ingesteld. Het s_vi -cookie identificeert bezoekers van Analytics. Nadat een cookie is ingesteld, wordt deze met alle volgende HTTP-aanvragen naar die server verzonden.
Wanneer een aanvraag naar de gegevensverzamelingsserver van de Adobe wordt verzonden, wordt de header gecontroleerd op het cookie s_vi . Als deze cookie in de aanvraag staat, wordt deze gebruikt om de bezoeker te identificeren. Als het cookie zich niet in de aanvraag bevindt, genereert de server een unieke Experience Cloud ID, stelt deze in als een cookie in de HTTP-antwoordheader en stuurt deze terug met de aanvraag. Het cookie wordt opgeslagen in de browser en wordt teruggestuurd naar de server voor gegevensverzameling tijdens volgende bezoeken aan de site. Hierdoor kan de bezoeker worden geïdentificeerd bij verschillende bezoeken.
Sommige browsers, zoals Apple Safari, accepteren cookies van andere bedrijven echter niet. Dit zijn cookies die in de browser zijn ingesteld vanuit andere domeinen dan de huidige website. Bovendien blokkeert Safari cookies op domeinen van derden als een bezoeker niet eerder naar dat domein is geweest. Als u bijvoorbeeld mysite.com hebt ingeschakeld en uw gegevensverzamelingsserver is ingesteld op mysite.omtrdc.net , wordt het cookie dat vanuit mysite.omtrdc.net in de HTTP-header wordt geretourneerd, mogelijk door de browser geweigerd.
Om dit te vermijden, hebben vele klanten CNAME verslagen voor hun servers van de gegevensinzameling uitgevoerd. Dit kan een efficiënt deel van a 🔗 strategie van de implementatie van het a eerste-partijkoekje zijn. Als een CNAME-record is geconfigureerd om een hostnaam in het domein van de klant toe te wijzen aan de gegevensverzamelingsserver (bijvoorbeeld toewijzing metrics.mysite.com aan mysite.omtrdc.net ), wordt het Experience Cloud ID-cookie opgeslagen omdat het gegevensverzamelingsdomein nu overeenkomt met het domein van de website. Hierdoor wordt de kans groter dat het cookie van de ID-service wordt opgeslagen. Nochtans, introduceert dit sommige overheadkosten omdat u CNAME- verslagen moet vormen en SSL certificaten voor de servers van de gegevensinzameling handhaven.
JavaScript
JavaScript kan cookies lezen en schrijven die zijn ingesteld in het domein van de eerste partij (het domein van de huidige website). De id-service van Experience Cloud gebruikt deze methode om het cookie van AMCV_###@AdobeOrg in te stellen dat alle bezoeker-id's bevat. Het domein van de traceringsserver hoeft dus niet langer overeen te komen met het domein van de website om het cookie van de bezoeker-id te kunnen opslaan. In de meeste gevallen is dit de aangewezen manier om het de dienstkoekje van identiteitskaart te plaatsen omdat het de overheadkosten van CNAME- verslagen en SSL- certificaten elimineert.
Aangepaste analyse-id's section-b6a7bd19e9ff432390010062450808f6
Het instellen van een klant-id met s.visitorID is een methode om gebruikers in Analytics te identificeren. Integraties waarin analysegegevens worden geëxporteerd of geïmporteerd met de id-service werken echter niet wanneer een bezoeker wordt geïdentificeerd met s.visitorID .
Dit omvat, maar is niet beperkt tot, gedeeld publiek, Analytics voor Doel (A4T), en de Attributen van de Klant. Voor deze integraties wordt het instellen van een aangepaste Analytics-id niet ondersteund.
Bestelling van Bezoeker-id voor analyse section-de1dc9fc9b6d4388995b70e35b8bcddf
Nadat u de bezoeker-id-service hebt geïmplementeerd, zijn er vijf manieren waarop een bezoeker kan worden geïdentificeerd in Analytics (vermeld in de volgende tabel in volgorde van voorkeur):
Een browser accepteert geen cookies van derden en de Analytics tracking-server is ingesteld als een externe tracingserver.
Opmerking: fid is een oudere id en wordt niet gebruikt als u de id-service op uw site hebt geïmplementeerd. In dit geval is fid niet nodig omdat de cookie van de eerste partij, AMCV cookie, deze verouderd maakt. Het is om historische redenen en ter ondersteuning van de oude code gehandhaafd.
In veel scenario's zou u 2 of 3 verschillende IDs op een vraag kunnen zien, maar de Analytics zal eerste identiteitskaart gebruiken huidig van die lijst als officiële Experience Cloud identiteitskaart. Als u bijvoorbeeld een aangepaste bezoeker-id instelt (opgenomen in de query-parameter "vid"), wordt die id gebruikt vóór andere id's die op dezelfde hit aanwezig kunnen zijn.