ID de dispositivos de origen en el SDK web

El SDK web de Adobe Experience Platform asigna Adobe Experience Cloud ID (ECID) a los visitantes del sitio web mediante cookies, para realizar un seguimiento del comportamiento del usuario. Para tener en cuenta las restricciones del explorador sobre la duración de las cookies, puede optar por establecer y administrar sus propios identificadores de dispositivo en su lugar. Estos se denominan ID de dispositivos de origen (FPID).

Este documento explica cómo configurar los ID de dispositivos de origen para la implementación del SDK web de Platform.

Requisitos previos

En esta guía se da por hecho que está familiarizado con el funcionamiento de los datos de identidad para el SDK web de Platform, incluida la función de los ECID y identityMap. Consulte la información general sobre datos de identidad en el SDK web para obtener más información.

Uso de FPID

Los FPID rastrean visitantes mediante cookies de origen. Las cookies de origen son más efectivas cuando se establecen mediante un servidor que utiliza un DNS Un registro (para IPv4) o registro AAAA (para IPv6), a diferencia de un CNAME o código JavaScript de DNS.

Una vez establecida una cookie FPID, su valor se puede recuperar y enviar al Adobe a medida que se recopilan los datos del evento. Los FPID recopilados se utilizan como semillas para generar ECID, que siguen siendo los identificadores principales en las aplicaciones de Adobe Experience Cloud.

Para enviar un FPID para un visitante de un sitio web a Platform Edge Network, debe incluir el FPID en la identityMap para ese visitante. Consulte la sección más adelante en este documento sobre uso de FPID en identityMap para obtener más información.

Requisitos de formato de ID

Platform Edge Network solo acepta ID que cumplan con las Formato UUIDv4. Los ID de dispositivo que no estén en formato UUIDv4 se rechazarán.

La generación de un UUID casi siempre resultará en un ID único y aleatorio, con una probabilidad insignificante de que se produzca una colisión. UUIDv4 no se puede inicializar mediante direcciones IP u otra información de identificación personal (PII). Los UUID son ubicuos y se pueden encontrar bibliotecas para prácticamente todos los lenguajes de programación para generarlos.

Configuración de una cookie de ID de origen en la interfaz de usuario de flujos de datos setting-cookie-datastreams

Puede especificar un nombre de cookie en la interfaz de usuario de flujos de datos, donde la variable FPID puede residir, en lugar de tener que leer el valor de la cookie e incluir el FPID en el mapa de identidad.

Consulte la documentación de flujos de datos para obtener información detallada sobre cómo configurar un conjunto de datos.

Al configurar la secuencia de datos, habilite la opción Cookie de ID de origen opción. Esta configuración indica a la red perimetral que haga referencia a una cookie especificada al buscar un ID de dispositivo de origen, en lugar de buscar este valor en la Mapa de identidad.

Consulte la documentación sobre cookies de origen para obtener más información sobre cómo funcionan con Adobe Experience Cloud.

Al habilitar esta configuración, debe proporcionar el nombre de la cookie en la que se espera almacenar el ID.

Cuando utiliza ID de origen, no puede realizar sincronizaciones de ID de terceros. Las sincronizaciones de ID de terceros se basan en Visitor ID y el UUID generado por ese servicio. Al utilizar la funcionalidad de ID de origen, el ECID se genera sin el uso del Visitor ID , que hace que las sincronizaciones de ID de terceros sean imposibles.

Cuando se utilizan ID de origen, no se admiten las funciones de Audience Manager dirigidas a la activación en plataformas de socios, dado que las sincronizaciones de ID de socios de Audience Manager se basan principalmente en UUIDs o DIDs. El ECID derivado de un ID de origen no está vinculado a un UUID, haciéndolo no direccionable.

Configuración de una cookie mediante su propio servidor

Al configurar una cookie mediante un servidor de su propiedad, se pueden utilizar varios métodos para evitar que la cookie se restrinja debido a las políticas del explorador:

Cuándo se establece la cookie

Lo ideal es que la cookie FPID se establezca antes de realizar cualquier solicitud a la red perimetral. Sin embargo, en los casos en los que esto no es posible, se sigue generando un ECID con los métodos existentes y actúa como identificador principal siempre que exista la cookie.

Suponiendo que el ECID se vea afectado finalmente por una política de eliminación del explorador, pero el FPID no, el FPID se convertirá en el identificador principal en la siguiente visita y se utilizará para inicializar el ECID en cada visita posterior.

Configuración de la caducidad de la cookie

Configurar la caducidad de una cookie es algo que debe considerarse cuidadosamente al implementar la funcionalidad FPID. Al decidir esto, debe tener en cuenta los países o regiones en los que opera su organización junto con las leyes y políticas de cada una de esas regiones.

Como parte de esta decisión, es posible que desee adoptar una política de establecimiento de cookies para toda la compañía o una que varíe para los usuarios en cada configuración regional en la que opera.

Independientemente de la configuración que elija para la caducidad inicial de una cookie, debe asegurarse de incluir una lógica que amplíe la caducidad de la cookie cada vez que se produce una nueva visita al sitio.

Impacto de los indicadores de cookies

Existen varios indicadores de cookies que afectan a cómo se tratan las cookies en los distintos exploradores:

HTTPOnly http-only

Cookies configuradas con HTTPOnly no se puede acceder al indicador mediante scripts del lado del cliente. Esto significa que si establece un HTTPOnly Indicador al configurar el FPID, debe utilizar un lenguaje de script del lado del servidor para leer el valor de la cookie para incluirlo en el identityMap.

Si elige que Platform Edge Network lea el valor de la cookie FPID, configure el HTTPOnly El indicador garantiza que ningún script del lado del cliente pueda acceder al valor, pero no tendrá ningún impacto negativo en la capacidad de Platform Edge Network para leer la cookie.

Secure secure

Cookies configuradas con Secure solo se envían al servidor con una solicitud cifrada a través del protocolo HTTPS. El uso de este indicador puede ayudar a garantizar que los atacantes intermediarios no puedan acceder fácilmente al valor de la cookie. Siempre que sea posible, es aconsejable configurar la variable Secure Indicador.

SameSite same-site

El SameSite El atributo permite a los servidores determinar si las cookies se envían con solicitudes entre sitios. El atributo proporciona cierta protección contra ataques de falsificación entre sitios. Existen tres valores posibles: Strict, Lax, y None. Consulte con su equipo interno para determinar qué configuración es correcta para su organización.

Si no SameSite se ha especificado, la configuración predeterminada para algunos exploradores es ahora SameSite=Lax.

Uso de FPID en identityMap identityMap

A continuación se muestra un ejemplo de cómo configuraría un FPID en la variable identityMap:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

Como con otros tipos de identidad, puede incluir el FPID con otras identidades dentro de identityMap. A continuación se muestra un ejemplo del FPID incluido con un ID de CRM autenticado:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Si el FPID está contenido en una cookie que está leyendo la red perimetral cuando la recopilación de datos de origen está habilitada, solo debe capturar el ID de CRM autenticado:

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Lo siguiente identityMap resultaría en una respuesta de error de la red perimetral, ya que le falta la variable primary para el FPID. Al menos uno de los ID presentes en identityMap debe marcarse como primary.

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

La respuesta de error devuelta por la red perimetral en este caso sería similar a la siguiente:

{
    "type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
    "status": 400,
    "title": "No primary identity set in request (event)",
    "detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
    "report": {
        "requestId": "{REQUEST_ID}",
        "configId": "{CONFIG_ID}",
        "orgId": "{ORG_ID}"
    }
}

Jerarquía de ID

Cuando hay presentes tanto un ECID como un FPID, el ECID tiene prioridad a la hora de identificar al usuario. Esto garantiza que, cuando un ECID existente esté presente en el almacén de cookies del explorador, siga siendo el identificador principal y que los recuentos de visitantes existentes no se vean afectados. Para los usuarios existentes, el FPID no se convertirá en la identidad principal hasta que el ECID caduque o se elimine como resultado de una política del explorador o un proceso manual.

Las identidades se priorizan en el siguiente orden:

Migración a ID de dispositivos de origen

Si está migrando a mediante FPID desde una implementación anterior, puede resultar difícil visualizar el aspecto que podría tener la transición en un nivel bajo.

Para ilustrar este proceso, considere un escenario que implique a un cliente que haya visitado anteriormente su sitio y el impacto que una migración FPID tendría en la forma en que se identifica a ese cliente en las soluciones de Adobe.

Preguntas frecuentes

A continuación se muestra una lista de respuestas a las preguntas frecuentes acerca de los ID de dispositivos de origen.

¿En qué se diferencia sembrar un ID de simplemente generarlo?

El concepto de inicialización es único, ya que el FPID pasado a Adobe Experience Cloud se convierte en un ECID utilizando un algoritmo determinista. Cada vez que se envía el mismo FPID a Adobe Experience Platform Edge Network, se siembra el mismo ECID desde el FPID.

¿Cuándo se debe generar el ID del dispositivo de origen?

Para reducir la inflación potencial de visitantes, el FPID debe generarse antes de realizar la primera solicitud mediante el SDK web. Sin embargo, si no puede hacerlo, se generará un ECID para ese usuario y se utilizará como identificador principal. El FPID generado no se convertirá en el identificador principal hasta que el ECID ya no esté presente.

¿Qué métodos de recopilación de datos admiten los ID de dispositivos de origen?

Actualmente, solo el SDK web admite FPID.

¿Los FPID se almacenan en alguna plataforma o solución de Experience Cloud?

Una vez que el FPID se ha utilizado para iniciar un ECID, se elimina del identityMap y reemplazado por el ECID que se ha generado. FPID no se almacena en ninguna solución de Adobe Experience Platform o de Experience Cloud.