Uso de ID de dispositivos de origen en Web SDK

Adobe Experience Platform Web SDK asigna Adobe Experience Cloud ID (ECID) a los visitantes del sitio web que usan cookies para realizar un seguimiento del comportamiento del usuario. Para abordar las restricciones del explorador sobre la duración de las cookies, puede establecer y administrar sus propios identificadores de dispositivo, conocidos como ID de dispositivos de origen (FPID).

Requisitos previos prerequisites

Antes de empezar, asegúrese de estar familiarizado con el funcionamiento de los datos de identidad en Web SDK, incluidos los ECID y identityMap. Consulte la descripción general de datos de identidad en Web SDK para obtener más información.

Requisitos de formato de ID de dispositivo de origen formatting-requirements

Edge Network solo acepta ID que cumplan con el formato UUIDv4. Los ID de dispositivo que no tengan el formato UUIDv4 se rechazarán.

Establecer la cookie FPID con su propio servidor set-cookie-server

Al configurar una cookie a través de su propio servidor, puede utilizar varios métodos para evitar que la cookie se restrinja debido a las políticas del explorador:

Además, siempre debe establecer la cookie FPID en el registro A de su dominio.

Cuándo se establece la cookie when-to-set-cookie

Lo ideal es configurar la cookie FPID antes de realizar cualquier solicitud a Edge Network. Sin embargo, en los casos en los que esto no sea posible, ECID se seguirá generando utilizando los métodos existentes y actuará como identificador principal siempre que exista la cookie.

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

Configuración de la caducidad de la cookie set-expiration

Configurar la caducidad de una cookie es algo que debe tenerse en cuenta 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 cookie-flag-impact

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

HTTPOnly http-only

No se puede tener acceso a las cookies configuradas con el indicador HTTPOnly mediante scripts del lado del cliente. Esto significa que si establece un indicador HTTPOnly al configurar FPID, debe usar un lenguaje de scripts del lado del servidor para leer el valor de la cookie para incluirlo en identityMap.

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

Secure secure

Las cookies configuradas con el atributo 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 establecer el indicador Secure.

SameSite same-site

El atributo SameSite 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 se especifica ningún atributo SameSite, la configuración predeterminada para algunos exploradores es ahora SameSite=Lax.

Jerarquía de ID id-hierarchy

Cuando hay presentes tanto un ECID como un FPID, se da prioridad al ECID en la identificación del usuario. Esto garantiza que cuando un(a) ECID existente esté presente en el almacén de cookies del explorador, permanezca como el identificador principal y que los recuentos de visitantes existentes no se vean afectados. Para los usuarios existentes, FPID no se convertirá en la identidad principal hasta que ECID caduque o se elimine como resultado de una directiva de explorador o un proceso manual.

Las identidades se priorizan en el siguiente orden:

Migración a ID de dispositivos de origen migrating-to-fpid

Si está migrando a ID de dispositivos de origen 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 involucre a un cliente que ya haya visitado su sitio y el impacto que una migración de FPID tendría en la forma en que se identifica a ese cliente en las soluciones de Adobe.

Uso de ID de dispositivos de origen (FPID) using-fpid

Los identificadores de dispositivos de origen (FPIDs) rastrean visitantes mediante cookies de origen. Las cookies de origen son más eficaces cuando se establecen con un servidor que usa un registro DNS A (para IPv4) o registro AAAA (para IPv6), a diferencia de un código DNS CNAME o JavaScript.

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

Puede usar FPIDs de dos maneras:

Método 1: Configuración de un CNAME para las llamadas SDK web y establecimiento de una cookie de ID de origen en el conjunto de datos setting-cookie-datastreams

Para establecer una cookie FPID desde su propio dominio, debe configurar su propio CNAME (nombre canónico) para sus llamadas SDK web y, a continuación, habilitar la funcionalidad First Party ID Cookie en la configuración de su secuencia de datos.

Paso 1. Configure un CNAME para el dominio de implementación de Web SDK

Un registro CNAME en su DNS le permite crear un alias de un nombre de dominio a otro. Esto puede ayudar a que los servicios de terceros aparezcan como si fueran parte de su propio dominio, lo que hace que sus cookies parezcan cookies de origen.

Ejemplo

Consideremos que desea implementar Web SDK en el sitio web mywebsite.com. Web SDK envía datos a Edge Network al dominio edge.adobedc.net.

Cuando la recopilación de datos de origen se habilita mediante CNAME, todas las cookies de su dominio se enviarán en solicitudes realizadas al extremo de recopilación de datos.

Para utilizar esta funcionalidad, debe establecer la cookie FPID en el nivel superior de su dominio en lugar de un subdominio específico. Si lo establece en un subdominio, el valor de la cookie no se enviará a Edge Network y la solución FPID no funcionará como estaba previsto.

Paso 2. Habilitar la funcionalidad ​​ First Party ID Cookie ​​ para su secuencia de datos

Una vez que haya configurado su CNAME, debe habilitar la opción Cookie de ID de origen para su secuencia de datos. Esta configuración indica a Edge Network que haga referencia a una cookie especificada cuando busque un ID de dispositivo de origen, en lugar de buscar este valor en el mapa de identidad.

Consulte la documentación de configuración de secuencia de datos para obtener información sobre cómo configurar su secuencia de datos.

Consulte la documentación de 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 donde se espera que se almacene FPID.

Método 2: usar FPID en identityMap identityMap

Como alternativa al almacenamiento de FPID en su propia cookie, puede enviar FPID a Edge Network a través del mapa de identidad.

A continuación se muestra un ejemplo de cómo establecería un FPID en el identityMap:

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

Al igual que con otros tipos de identidad, puede incluir FPID con otras identidades dentro de identityMap. El siguiente es un ejemplo de FPID incluido con un CRM ID autenticado:

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

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

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

Los(as) siguientes identityMap resultarían en una respuesta de error de Edge Network, ya que le falta el indicador primary para FPID. Al menos uno de los identificadores 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 Edge Network 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}"
    }
}

Preguntas frecuentes faq

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 en el sentido de que FPID pasado a Adobe Experience Cloud se convierte en un ECID mediante un algoritmo determinístico. Cada vez que se envíe el mismo(a) FPID a Edge Network, se sembrará el mismo(a) ECID desde FPID.

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

Para reducir la inflación potencial de visitantes, FPID debe generarse antes de realizar la primera solicitud mediante Web SDK. Sin embargo, si no puede hacerlo, se generará un ECID para ese usuario y se utilizará como identificador principal. El FPID que se generó 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 Web SDK admite ID de dispositivos de origen.

¿Los ID de dispositivo de origen se almacenan en cualquier plataforma o solución de Experience Cloud?

Una vez que FPID se ha utilizado para inicializar ECID, se quita de identityMap y se reemplaza por ECID que se ha generado. FPID no está almacenado en ninguna solución de Adobe Experience Platform o Experience Cloud.