El SDK web de Adobe Experience Platform aprovecha Adobe Experience Cloud ID (ECID) para realizar un seguimiento del comportamiento de los visitantes. Con los ECID, se puede garantizar que cada dispositivo tenga un identificador único que pueda persistir en varias sesiones, vinculando todas las visitas que se producen durante y entre sesiones web a un dispositivo específico.
Este documento proporciona información general sobre cómo administrar los ECID mediante el SDK web de Platform.
El SDK web de Platform asigna y rastrea los ECID mediante el uso de cookies, con varios métodos disponibles para configurar cómo se generan estas cookies.
Cuando un nuevo usuario llega a su sitio web, el servicio de identidad de Adobe Experience Cloud intenta establecer una cookie de identificación de dispositivo para ese usuario. Para los visitantes nuevos, se genera un ECID que se devuelve en la primera respuesta de Adobe Experience Platform Edge Network. Para los visitantes repetidos, el ECID se recupera del kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
y la red perimetral la agrega a la carga útil.
Una vez configurada la cookie que contiene el ECID, cada solicitud posterior generada por el SDK web incluirá un ECID codificado en la variable kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
cookie.
Al utilizar cookies para la identificación de dispositivos, tiene dos opciones para interactuar con la red perimetral:
adobedc.net
. Este método se denomina recopilación de datos de terceros.adobedc.net
. Este método se denomina recopilación de datos de origen.Como se explica en las secciones siguientes, el método de recopilación de datos que elija usar tiene un impacto directo en la duración de las cookies en los distintos navegadores.
La recopilación de datos de terceros implica enviar datos directamente al dominio de red perimetral adobedc.net
.
En los últimos años, los navegadores web se han vuelto cada vez más restrictivos en su gestión de cookies establecidas por terceros. Algunos exploradores bloquean las cookies de terceros de forma predeterminada. Si usa cookies de terceros para identificar visitantes del sitio, la duración de esas cookies es casi siempre menor que la que estaría disponible de otro modo mediante cookies de origen. En algunos casos, una cookie de terceros caducará en tan solo siete días.
Además, cuando se utiliza la recopilación de datos de terceros, algunos bloqueadores de anuncios restringen el tráfico a los extremos de recopilación de datos de Adobe.
La recopilación de datos de origen implica la configuración de cookies a través de un CNAME en su propio dominio que señala a adobedc.net
.
Aunque los exploradores han tratado las cookies establecidas por los endpoints CNAME de forma similar a las establecidas por los endpoints de propiedad del sitio, los cambios recientes implementados por los exploradores han creado una distinción en el modo en que se gestionan las cookies CNAME. Aunque no hay exploradores que actualmente bloqueen las cookies CNAME de origen de forma predeterminada, algunos exploradores restringen la duración de las cookies configuradas con un CNAME a solo siete días.
Independientemente de si elige la recopilación de datos de origen o de terceros, el tiempo que una cookie puede persistir tiene un impacto directo en el recuento de visitantes en Adobe Analytics y en el Customer Journey Analytics. Además, los usuarios finales pueden experimentar experiencias de personalización incoherentes cuando se utiliza Adobe Target o Offer decisioning en el sitio.
Por ejemplo, imaginemos una situación en la que ha creado una experiencia de personalización que promoverá cualquier artículo a la página principal si un usuario lo ha visto tres veces en los últimos siete días.
Si un usuario final visita el sitio tres veces en una semana y luego no vuelve al sitio durante siete días, ese uso podría considerarse como un usuario nuevo cuando vuelva al sitio, ya que las cookies pueden haber sido eliminadas por una directiva de explorador (en función del explorador que estaba usando cuando visitó el sitio). Si esto sucede, la herramienta Analytics tratará al visitante como un nuevo usuario aunque haya visitado el sitio hace poco más de siete días. Además, cualquier esfuerzo para personalizar la experiencia para el usuario empezará de nuevo.
Para tener en cuenta los efectos de los planes de vida de las cookies como se describe más arriba, puede optar por establecer y administrar sus propios identificadores de dispositivo. Consulte la guía de ID de dispositivos de origen para obtener más información.
Para recuperar el ECID único para el visitante actual, utilice la variable getIdentity
comando. Para los visitantes nuevos que aún no tienen un ECID, este comando genera un nuevo ECID. getIdentity
también devuelve el ID de región del visitante.
Este método se utiliza generalmente con soluciones personalizadas que requieren leer la variable Experience Cloud ID o necesita una sugerencia de ubicación para Adobe Audience Manager. No se utiliza en una implementación estándar.
alloy("getIdentity")
.then(function(result) {
// The command succeeded.
console.log("ECID:", result.identity.ECID);
console.log("RegionId:", result.edge.regionId);
})
.catch(function(error) {
// The command failed.
// "error" will be an error object with additional information.
});
identityMap
Uso de un XDM identityMap
field, puede identificar un dispositivo o usuario que utilice varias identidades, establecer su estado de autenticación y decidir qué identificador se considera el principal. Si no se ha establecido ningún identificador como primary
, el valor predeterminado principal es ECID
.
identityMap
los campos se actualizan utilizando la variable sentEvent
comando.
alloy("sendEvent", {
xdm: {
"identityMap": {
"ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
{
"id": "1234",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
});
Cada propiedad de identityMap
representa identidades pertenecientes a una área de nombres de identidad. El nombre de la propiedad debe ser el símbolo del área de nombres de identidad, que puede encontrar en la interfaz de usuario de Adobe Experience Platform en "Identidades". El valor de la propiedad debe ser una matriz de identidades pertenecientes a ese área de nombres de identidad.
El ID de área de nombres pasado en la variable identityMap
distingue entre mayúsculas y minúsculas. Asegúrese de utilizar el ID de área de nombres correcto para evitar una recopilación de datos incompleta.
Cada objeto de identidad de la matriz de identidades contiene las siguientes propiedades:
Propiedad | Tipo de datos | Descripción |
---|---|---|
id |
Cadena | (Obligatorio) El ID que desea establecer para el área de nombres dada. |
authenticationState |
Cadena | (Obligatorio) El estado de autenticación del ID. Los valores posibles son ambiguous , authenticated y loggedOut . |
primary |
Booleano | Determina si esta identidad debe utilizarse como fragmento principal en el perfil. De forma predeterminada, el ECID se establece como identificador principal para el usuario. Si se omite, el valor predeterminado es false . |
Al migrar desde la API de visitante, también puede migrar las cookies AMCV existentes. Para habilitar la migración de ECID, establezca la variable idMigrationEnabled
en la configuración. La migración de ID habilita los siguientes casos de uso:
idMigrationEnabled
durante un periodo de tiempo para migrar la mayoría de las cookies del visitante, la configuración se puede desactivar.Cuando se envían datos con formato XDM al Audience Manager, estos datos deben convertirse en señales al migrar. Los rasgos deberán actualizarse para reflejar las nuevas claves que proporciona XDM. Este proceso se facilita mediante el uso de la variable Herramienta BAAAM ese Audience Manager ha creado.
Si tiene reenvío de eventos habilitada y está utilizando appmeasurement.js
y visitor.js
, puede mantener habilitada la función de reenvío de eventos, lo que no provocará ningún problema. En el back-end, Adobe busca cualquier segmento AAM y lo agrega a la llamada a Analytics. Si la llamada a Analytics contiene estos segmentos, Analytics no llamará al Audience Manager para reenviar datos, por lo que no hay ninguna recopilación de datos doble. Tampoco hay necesidad de indicio de ubicación al utilizar el SDK web, ya que se llaman los mismos puntos finales de segmentación en el servidor.