Configuración de Analytics y Experience Cloud ID setting-analytics-and-experience-cloud-ids
El servicio de identidad de Experience Cloud sustituye a los métodos de ID de visitante de Analytics anteriores.
Una vez implementado el servicio de ID, este código se ejecuta antes que AppMeasurement. El servicio de ID recupera los Experience Cloud ID y Analytics para que los valores estén listos cuando se cargue AppMeasurement.
Cuando AppMeasurement se carga, los valores de los Experience Cloud ID y de Analytics se solicitan al servicio de ID y se envían a la recopilación de datos con cada llamada del servidor. El servicio de ID determina el ID de visitante y lo pasa a AppMeasurement directamente, por lo que este servicio debe incluirse e implementarse en todas las páginas antes que el archivo JavaScript de AppMeasurement.
Cambios en el proceso de ID de Analytics section-79bb86ae63f546419bb1a7ef5e710462
El cambio principal consiste en que, al migrar al servicio de ID de Experience Cloud, la cookie de ID se establece mediante JavaScript y no en el encabezado HTTP que devuelve el servidor web de recopilación de datos. Para comprender este cambio, las siguientes secciones describen cómo se configuran las cookies mediante estos dos métodos.
Encabezado HTTP
Una respuesta HTTP de un servidor web establece cookies en un explorador. Así es como se establece la s_vi cookie. La s_vi cookie identifica a los visitantes de Analytics. Cuando se establece una cookie, esta se envía con todas las solicitudes HTTP subsiguientes a este servidor.
Cuando se envía una solicitud al servidor de recopilación de datos de Adobe, se comprueba la existencia de la cookie s_vi en el encabezado. Si la cookie se encuentra en la solicitud, se usa para identificar al visitante. En caso contrario, el servidor genera un ID de Experience Cloud único, lo establece como una cookie en el encabezado de respuesta HTTP y lo devuelve con la solicitud. La cookie se almacena en el explorador y se devuelve al servidor de recopilación de datos durante las visitas posteriores al sitio. Esto permite identificar el visitante en todas las visitas.
Sin embargo, algunos exploradores, como Apple Safari, no aceptan cookies de terceros. Son cookies configuradas en el explorador desde dominios distintos del sitio web actual. Además, Safari bloquea las cookies en dominios de terceros si un visitante no ha estado antes en ese dominio. Por ejemplo, si está en mysite.com y el servidor de recopilación de datos es mysite.omtrdc.net, el explorador puede rechazar la cookie que se devuelve en el encabezado HTTP desde mysite.omtrdc.net.
Para evitarlo, muchos clientes han implementado registros CNAME para sus servidores de recopilación de datos. Esto puede ser una parte efectiva de una implementación de una cookie de origen. Si se configura la asignación de un registro CNAME a un nombre de host en el dominio del cliente para el servidor de recopilación de datos (por ejemplo, si se asigna metrics.mysite.com a mysite.omtrdc.net), se almacenará la cookie de ID de Experience Cloud, porque ahora coinciden los dominios de recopilación de datos y del sitio web. Esto aumenta la probabilidad de que se almacene la cookie del servicio de ID. Sin embargo, esto implica cierta sobrecarga porque necesita configurar registros CNAME y mantener certificados SSL para los servidores de recopilación de datos.
JavaScript
JavaScript puede leer y escribir cookies configuradas en el dominio de origen (el dominio del sitio web actual). El servicio de ID de Experience Cloud usa este método para establecer la cookie AMCV_###@AdobeOrg que contiene todos los ID de visitante, de modo que el dominio del servidor de seguimiento puede almacenar la cookie de ID de visitante sin necesidad de coincidir con el dominio del sitio web. En la mayoría de los casos, esta es la forma preferida de establecer la cookie del servicio de ID porque elimina la sobrecarga de registros CNAME y certificados SSL.
ID de Analytics personalizados section-b6a7bd19e9ff432390010062450808f6
El establecimiento de un ID de cliente mediante s.visitorID es un método para identificar a los usuarios en Analytics. Sin embargo, las integraciones en las que se exportan o importan datos de Analytics mediante el servicio de ID no funcionarán cuando se identifique a un visitante mediante s.visitorID.
Entre ellas se cuentan los públicos compartidos, Analytics for Target (A4T) y atributos del cliente. Estas integraciones no admiten la configuración de un ID de Analytics personalizado.
Pedido de ID de visitante de Analytics section-de1dc9fc9b6d4388995b70e35b8bcddf
Después de implementar el servicio de ID de visitante, hay cinco formas de identificar un visitante en Analytics (enumeradas en la siguiente tabla en orden de preferencia):
Un navegador no acepta cookies de terceros y el servidor de seguimiento de Analytics está configurado como servidor de seguimiento de terceros.
Nota: El valor fid es un identificador preexistente y no se utiliza si se ha implementado el servicio de ID en el sitio. En este caso, el fid no es necesario porque la cookie AMCV de origen hace que quede obsoleto. Se ha mantenido para admitir código heredado y por motivos históricos.
En muchos escenarios, es posible que vea dos o tres ID distintos en una llamada, pero Analytics utilizará el primer ID presente en la lista como el ID de Experience Cloud oficial. Por ejemplo, si configura un ID de visitante personalizado (incluido en el parámetro de consulta "vid"), ese ID se utilizará antes que otros ID que puedan existir en la misma visita.