IDs de dispositivo próprio no SDK da Web

O SDK da Web da Adobe Experience Platform atribui Adobe Experience Cloud IDs (ECIDs) aos visitantes do site usando cookies para rastrear o comportamento do usuário. Para levar em conta as restrições do navegador nas vidas dos cookies, você pode optar por definir e gerenciar seus próprios identificadores de dispositivo. Elas são chamadas de IDs de dispositivos primários (FPIDs).

Este documento explica como configurar IDs de dispositivo primário para a implementação do SDK da Web.

Pré-requisitos

Este guia supõe que você esteja familiarizado com como os dados de identidade funcionam para o SDK da Web da Platform, incluindo a função das ECIDs e do identityMap. Consulte a visão geral sobre dados de identidade no SDK da Web para obter mais informações.

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 o Adobe conforme os dados do evento são coletados. Os FPIDs coletados são usados como seeds para gerar ECIDs, que continuam a ser os identificadores primários nos aplicativos do Adobe Experience Cloud.

Para enviar um FPID para um visitante do site para o Edge Network, você deve incluir o FPID no identityMap para esse visitante. Consulte a seção mais abaixo neste documento sobre uso de FPIDs em identityMap 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.

A geração de um UUID quase sempre resultará em uma ID exclusiva e aleatória, com a probabilidade de ocorrer uma colisão sendo insignificante. UUIDv4 não pode ser propagado usando endereços IP ou qualquer outra informação pessoal identificável (PII). UUIDs são universais e podem ser encontradas bibliotecas para praticamente todas as linguagens de programação para gerá-los.

Configuração de um cookie de ID primário na interface dos fluxos de dados setting-cookie-datastreams

Você pode especificar um nome de cookie na interface dos Datastreams, onde o FPID pode residir, em vez de ter que ler o valor do cookie e incluir o FPID no mapa de identidade.

Consulte a documentação de sequências de dados para obter informações detalhadas sobre como configurar uma sequência de dados.

Ao configurar sua sequência de dados, habilite a opção Cookie de ID primária. Esta configuração informa o Edge Network a fazer referência a um cookie especificado ao pesquisar uma ID de dispositivo primário, em vez de procurar esse valor no mapa de identidade.

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

Ao ativar essa configuração, você deve fornecer o nome do cookie no qual a ID deve ser armazenada.

Ao usar IDs primárias, não é possível executar sincronizações de ID de terceiros. As sincronizações de ID de terceiros dependem do serviço Visitor ID e do UUID gerado por esse serviço. Ao usar a funcionalidade de ID própria, o ECID é gerado sem o uso do serviço Visitor ID, o que torna as sincronizações de ID de terceiros impossíveis.

Quando você usa IDs primárias, os recursos de Audience Manager direcionados para ativação em plataformas de parceiros não são compatíveis, considerando que as sincronizações de ID de parceiro de Audience Manager se baseiam principalmente em UUIDs ou DIDs. O ECID derivado de uma ID própria não está vinculado a um UUID, tornando-o inendereçável.

Configurar um cookie usando seu próprio servidor set-cookie-server

Ao definir um cookie usando um servidor que você possui, é possível usar vários métodos para impedir que o cookie seja restrito devido a políticas do navegador:

Quando definir o cookie when-to-set-cookie

Idealmente, o cookie FPID deve ser definido antes de fazer qualquer solicitação para o 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 com que o Edge Network leia o valor do cookie FPID, definir o sinalizador HTTPOnly garante que o valor não esteja acessível por nenhum script 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.

Usando FPIDs em identityMap identityMap

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 pelo 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 o 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"
      }
    ]
  }
}

Nesse caso, a resposta do erro retornada pelo Edge Network 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}"
    }
}

Configurar um FPID no seu próprio domínio setting-fpid-domain

Além de definir o FPID no mapa de identidade, você pode definir o cookie FPID em seu próprio domínio, se tiver uma coleção de dados próprios CNAME configurada.

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.

Todos os cookies não relevantes para os fins de coleta de dados do Adobe são descartados. Para FPID, você pode especificar o nome do cookie FPID na configuração da sequência de dados. Ao fazer isso, o Edge Network lerá o conteúdo do cookie FPID em vez de procurar por FPID no mapa de identidade.

Para usar essa funcionalidade, você precisa definir o 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 o Edge Network e a solução FPID não funcionará conforme o esperado.

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 Adobe.

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 para o 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 SDK da Web. 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 SDK da Web oferece suporte a IDs de dispositivos primários.

As IDs de dispositivo primárias são armazenadas em qualquer plataforma ou solução 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 Adobe Experience Platform ou Experience Cloud.