Usar IDs de dispositivo primário no Web SDK

O Adobe Experience Platform Web SDK atribui Adobe Experience Cloud IDs (ECIDs) aos visitantes do site usando cookies para rastrear o comportamento do usuário. Para resolver as restrições do navegador nas vidas do cookie, você pode definir e gerenciar seus próprios identificadores de dispositivo, conhecidos como IDs de dispositivo primário (FPIDs).

Pré-requisitos prerequisites

Antes de começar, familiarize-se com o funcionamento dos dados de identidade no Web SDK, incluindo ECIDs e identityMap. Consulte a visão geral sobre dados de identidade no Web SDK para obter mais informações.

Requisitos de formatação de ID de dispositivo próprio formatting-requirements

O Edge Network só aceita IDs que estejam em conformidade com o formato UUIDv4. As IDs de dispositivo que não estão no formato UUIDv4 serão rejeitadas.

Definir o cookie FPID usando seu próprio servidor set-cookie-server

Ao definir um cookie por meio do seu próprio servidor, você pode usar vários métodos para impedir que o cookie seja restrito devido a políticas do navegador:

Além disso, você sempre deve definir o cookie FPID no registro A do seu domínio.

Quando definir o cookie when-to-set-cookie

Idealmente, o cookie FPID deve ser definido antes de fazer qualquer solicitação para a Edge Network. No entanto, em cenários em que isso não é possível, um ECID ainda é gerado usando métodos existentes e atua como o identificador principal, desde que o cookie exista.

Supondo que ECID seja afetado por uma política de exclusão de navegador, mas FPID não, FPID se tornará o identificador principal na próxima visita e será usado para propagar ECID em cada visita subsequente.

Definição da expiração do cookie set-expiration

Definir a expiração de um cookie é algo que deve ser considerado cuidadosamente ao implementar a funcionalidade FPID. Ao decidir isso, você deve considerar os países ou regiões em que sua organização opera, juntamente com as leis e políticas em cada uma dessas regiões.

Como parte dessa decisão, você pode adotar uma política de configuração de cookies em toda a empresa ou uma que varie para os usuários em cada local onde você opera.

Independentemente da configuração escolhida para a expiração inicial de um cookie, você deve garantir que inclua uma lógica que estenda a expiração do cookie toda vez que ocorrer uma nova visita ao site.

Impacto dos sinalizadores de cookies cookie-flag-impact

Há vários sinalizadores de cookies que afetam como os cookies são tratados em navegadores diferentes:

HTTPOnly http-only

Os cookies definidos com o sinalizador HTTPOnly não podem ser acessados com scripts do lado do cliente. Isso significa que, se você definir um sinalizador HTTPOnly ao definir o FPID, deverá usar uma linguagem de script do lado do servidor para ler o valor do cookie para inclusão no identityMap.

Se você optar por fazer o Edge Network ler o valor do cookie FPID, definir o sinalizador HTTPOnly garantirá que o valor não seja acessível por scripts do lado do cliente, mas não terá nenhum impacto negativo na capacidade do Edge Network de ler o cookie.

Secure secure

Os cookies definidos com o atributo Secure só são enviados ao servidor com uma solicitação criptografada através do protocolo HTTPS. O uso desse sinalizador pode ajudar a garantir que invasores intermediários não possam acessar facilmente o valor do cookie. Quando possível, é sempre uma boa ideia definir o sinalizador Secure.

SameSite same-site

O atributo SameSite permite que os servidores determinem se os cookies são enviados com solicitações entre sites. O atributo fornece alguma proteção contra ataques de falsificação entre sites. Existem três valores possíveis: Strict, Lax e None. Consulte sua equipe interna para determinar qual é a configuração certa para sua organização.

Se nenhum atributo SameSite for especificado, a configuração padrão para alguns navegadores agora será SameSite=Lax.

Hierarquia de ID id-hierarchy

Quando um ECID e FPID estão presentes, o ECID é priorizado na identificação do usuário. Isso garante que, quando um ECID existente estiver presente no armazenamento de cookies do navegador, ele permanecerá o identificador principal e as contagens de visitantes existentes não correm o risco de serem afetadas. Para usuários existentes, o FPID não se tornará a identidade principal até que o ECID expire ou seja excluído como resultado de uma política de navegador ou processo manual.

As identidades são priorizadas na seguinte ordem:

Migração para IDs de dispositivos primários migrating-to-fpid

Se você estiver migrando de uma implementação anterior para IDs de dispositivo primário, pode ser difícil visualizar como a transição pode parecer em um nível baixo.

Para ajudar a ilustrar esse processo, considere um cenário que envolva um cliente que visitou seu site anteriormente e o impacto que uma migração do FPID teria em como esse cliente é identificado nas soluções da Adobe.

Uso de IDs de dispositivo primário (FPIDs) using-fpid

As IDs de dispositivo próprio (FPIDs) rastreiam visitantes usando cookies próprios. Os cookies próprios são mais eficazes quando definidos com um servidor que usa um registro A DNS (para IPv4) ou registro AAAA (para IPv6), em vez de um código CNAME ou JavaScript DNS.

Depois que um cookie FPID é definido, seu valor pode ser buscado e enviado para a Adobe à medida que os dados do evento são coletados. Os FPIDs coletados são usados para gerar ECIDs, que são os identificadores primários em aplicativos Adobe Experience Cloud.

Você pode usar FPIDs de duas maneiras:

Método 1: configurar um CNAME para suas chamadas do Web SDK e definir um cookie de ID primária na sua sequência de dados setting-cookie-datastreams

Para definir um cookie FPID do seu próprio domínio, você precisa configurar seu próprio CNAME (Nome Canônico) para suas chamadas do Web SDK e habilitar a funcionalidade First Party ID Cookie na configuração da sequência de dados.

Etapa 1. Configure um CNAME para seu domínio de implantação do Web SDK

Um registro CNAME no DNS permite criar um alias de um nome de domínio para outro. Isso pode ajudar a fazer com que serviços de terceiros pareçam fazer parte do seu próprio domínio, fazendo com que seus cookies pareçam cookies primários.

Exemplo

Considere que você deseja implementar o Web SDK em seu site mywebsite.com. O Web SDK envia dados à Edge Network para o domínio edge.adobedc.net.

Quando a coleta de dados primários é habilitada usando um CNAME, todos os cookies do seu domínio serão enviados em solicitações feitas ao ponto de extremidade da coleta de dados.

Para usar essa funcionalidade, você precisa definir o cookie FPID no nível superior do seu domínio, em vez de um subdomínio específico. Se você o definir em um subdomínio, o valor do cookie não será enviado para a Edge Network e a solução FPID não funcionará conforme o esperado.

Etapa 2. Habilitar a funcionalidade de ​​ Cookie de ID de Primário ​​ para sua sequência de dados

Após configurar seu CNAME, você deve habilitar a opção Cookie de ID primária para sua sequência de dados. Esta configuração informa ao Edge Network para fazer referência a um cookie especificado ao pesquisar uma ID de dispositivo primário, em vez de pesquisar esse valor no mapa de identidade.

Consulte a documentação de configuração da sequência de dados para saber como configurar a sequência de dados.

Consulte a documentação sobre cookies próprios para obter mais detalhes sobre como eles funcionam com a Adobe Experience Cloud.

Ao habilitar esta configuração, você deve fornecer o nome do cookie no qual se espera que o FPID seja armazenado.

Método 2: usar FPIDs em identityMap identityMap

Como alternativa ao armazenamento de FPID em seu próprio cookie, você pode enviar o FPID para a Edge Network por meio do mapa de identidade.

Veja abaixo um exemplo de como você definiria um FPID no identityMap:

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

Assim como em outros tipos de identidade, você pode incluir FPID com outras identidades em identityMap. Este é um exemplo de FPID incluído com um CRM ID autenticado:

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

Se FPID estiver contido em um cookie que está sendo lido pela Edge Network quando a coleta de dados próprios estiver habilitada, você deverá capturar apenas o CRM ID autenticado:

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

O seguinte identityMap resultaria em uma resposta de erro do Edge Network, pois o indicador primary para FPID está ausente. Pelo menos uma das IDs presentes em identityMap deve ser marcada como primary.

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

A resposta do erro retornada pela Edge Network nesse caso seria semelhante ao seguinte:

{
    "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}"
    }
}

Perguntas frequentes faq

Esta é uma lista de respostas para perguntas frequentes sobre IDs de dispositivos primários.

Qual a diferença entre o seed de uma ID e a simples geração de uma ID?

O conceito de propagação é exclusivo, na medida em que o FPID transmitido ao Adobe Experience Cloud é convertido em um ECID usando um algoritmo determinístico. Sempre que o mesmo FPID for enviado ao Edge Network, o mesmo ECID será propagado do FPID.

Quando a ID de dispositivo primário deve ser gerada?

Para reduzir a inflação potencial de visitantes, o FPID deve ser gerado antes de fazer sua primeira solicitação usando o Web SDK. No entanto, se você não conseguir fazer isso, um ECID ainda será gerado para esse usuário e será usado como o identificador principal. O FPID que foi gerado não se tornará o identificador principal até que o ECID não esteja mais presente.

Quais métodos de coleta de dados oferecem suporte a IDs de dispositivos primários?

Atualmente, somente o Web SDK oferece suporte a IDs de dispositivos primários.

As IDs de dispositivo primárias são armazenadas em qualquer plataforma ou solução da Experience Cloud?

Depois que o FPID tiver sido usado para propagar um ECID, ele será descartado do identityMap e substituído pelo ECID que foi gerado. O FPID não está armazenado em nenhuma solução da Adobe Experience Platform ou da Experience Cloud.