Datos de identidad en el SDK web

El SDK web de Adobe Experience Platform usa Adobe Experience Cloud ID (ECID) para hacer un seguimiento del comportamiento de los visitantes. Con ECIDs, puede asegurarse de que cada dispositivo tenga un identificador único que pueda persistir en varias sesiones y que vincule todas las visitas que se producen durante las sesiones web y entre ellas a un dispositivo específico.

Este documento proporciona información general sobre cómo administrar ECIDs y CORE IDs mediante el SDK web.

Seguimiento de ECID mediante SDK web tracking-ecids-web-sdk

El SDK web asigna y rastrea ECIDs mediante cookies, con varios métodos disponibles para configurar cómo se generan estas cookies.

Cuando un usuario nuevo 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.

Una vez establecida la cookie que contiene ECID, cada solicitud posterior generada por el SDK web incluye ECID codificado en la cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity.

Al utilizar cookies para identificar el dispositivo, tiene dos formas de interactuar con el Edge Network:

Como se explica en las secciones siguientes, el método de recopilación de datos que decide utilizar tiene un impacto directo en la duración de las cookies en los exploradores.

Seguimiento de ID de CORE mediante SDK web tracking-coreid-web-sdk

Cuando se usa Google Chrome con cookies de terceros habilitadas y no se ha establecido ninguna cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity, la primera solicitud de Edge Network pasa por un dominio demdex.net, que establece una cookie demdex. Esta cookie contiene un CORE ID. Se trata de un identificador de usuario único, distinto del ECID.

Según su implementación, es posible que desee acceder a CORE ID.

Recopilación de datos de origen first-party

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 durante mucho tiempo las cookies configuradas por CNAME extremos de manera similar a las establecidas por los extremos propiedad del sitio, los cambios recientes implementados por los exploradores han creado una distinción en la forma en que se administran las cookies de CNAME. Aunque no hay exploradores que bloqueen las cookies de origen CNAME de forma predeterminada, algunos restringen la duración de las cookies configuradas con un CNAME a solo siete días.

Recopilación de datos de terceros third-party

La recopilación de datos de terceros implica el envío de datos directamente al dominio Edge Network adobedc.net.

En los últimos años, los navegadores web se han vuelto cada vez más restrictivos en el manejo de cookies configuradas por terceros. Algunos exploradores bloquean las cookies de terceros de forma predeterminada. Si utiliza cookies de terceros para identificar a los visitantes del sitio, la duración de dichas cookies es casi siempre más corta que la que estaría disponible de otro modo utilizando cookies de origen en su lugar. A veces, una cookie de terceros caduca en tan solo siete días.

Además, al utilizar 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 por completo.

Efectos de la duración de las cookies en las aplicaciones de Adobe Experience Cloud lifespans

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 los recuentos de visitantes en Adobe Analytics y Customer Journey Analytics. Además, los usuarios finales pueden experimentar experiencias de personalización incoherentes cuando se usan Adobe Target o Offer decisioning en el sitio.

Por ejemplo, considere una situación en la que ha creado una experiencia de personalización que promociona cualquier elemento 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 regresa al sitio durante siete días, ese usuario podría considerarse un nuevo usuario cuando vuelva al sitio porque una política de explorador puede haber eliminado sus cookies (según el explorador que estuviera utilizando cuando visitó el sitio). Si esto sucede, la herramienta Analytics trata al visitante como un nuevo usuario aunque haya visitado el sitio hace poco más de siete días. Además, cualquier esfuerzo por personalizar la experiencia para el usuario comienza de nuevo.

ID de dispositivos de origen (FPID) fpid

Para tener en cuenta los efectos de la duración de las cookies como se describe más arriba, puede elegir establecer y administrar sus propios identificadores de dispositivo en su lugar. Consulte la guía de ID de dispositivos de origen para obtener más información.

Recupere el ECID y la región del usuario actual retrieve-ecid

Según su caso de uso, puede acceder a ECID de dos formas:

Recuperar ECID mediante la preparación de datos para la recopilación de datos retrieve-ecid-data-prep

Use la preparación de datos para la recopilación de datos para asignar ECID a un campo de XDM. Esta es la forma recomendada de obtener acceso a ECID.

Para ello, establezca el campo de origen en la siguiente ruta:

xdm.identityMap.ECID[0].id

A continuación, establezca el campo de destino en una ruta XDM donde el campo sea del tipo string.

Recuperar ECID mediante el comando getIdentity() retrieve-ecid-getidentity

Para recuperar el ECID único del visitante actual, use el comando getIdentity. 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.

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.
  });

Recuperar el CORE ID del usuario actual retrieve-coreid

Para recuperar el CORE ID de un usuario, puede utilizar el comando getIdentity(), como se muestra a continuación.

alloy("getIdentity",{
  "namespaces": ["CORE"]
});

Usando identityMap using-identitymap

Con un campo XDM identityMap, puede identificar un dispositivo o usuario con 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 campos se han actualizado mediante el comando sentEvent.

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "authenticated",
          "primary": true
        }
      ]
    }
  }
});

Cada propiedad de identityMap representa identidades que pertenecen a un área de nombres de identidad en particular. El nombre de propiedad debe ser el símbolo del área de nombres de identidad, que se puede encontrar en la interfaz de usuario de Adobe Experience Platform en "Identities". El valor de la propiedad debe ser una matriz de identidades pertenecientes a ese área de nombres de identidad.

Cada objeto de identidad de la matriz de identidades contiene las siguientes propiedades:

El uso del campo identityMap para identificar dispositivos o usuarios lleva al mismo resultado que el uso del método setCustomerIDs desde ID Service API. Consulte la documentación de la API del servicio de ID para obtener más información.

Migración de la API de visitante a ECID migrating-visitor-api-ecid

Al migrar desde la API de visitante, también puede migrar las cookies AMCV existentes. Para habilitar la migración de ECID, establezca el parámetro idMigrationEnabled en la configuración. La migración de ID habilita los siguientes casos de uso:

Actualización de características para la migración

Cuando se envían datos con formato XDM a Audience Manager, estos datos deben convertirse en señales al migrar. Las características deben actualizarse para reflejar las nuevas claves que proporciona XDM. Este proceso es más fácil gracias a la herramienta BAAAM que el Audience Manager ha creado.

Uso en el reenvío de eventos

Si actualmente tiene habilitado reenvío de eventos y usa appmeasurement.js y visitor.js, puede mantener habilitada la característica de reenvío de eventos y esto no causará ningún problema. En el back-end, el Adobe AAM recupera cualquier segmento de y lo añade a la llamada a Analytics. Si la llamada a Analytics contiene esos segmentos, Analytics no llamará al Audience Manager para reenviar ningún dato, por lo que no hay ninguna recopilación de datos doble. Tampoco es necesario utilizar una sugerencia de ubicación al utilizar el SDK web, ya que se llaman los mismos extremos de segmentación en el backend.