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 do cookie, você pode optar por definir e gerenciar seus próprios identificadores de dispositivo. Elas são chamadas de IDs de dispositivos primários (FPIDs).
Você pode usar IDs de dispositivo primário ou cookies de terceiros, mas não pode usar ambos os recursos simultaneamente.
Este documento aborda como configurar IDs de dispositivo primário para a implementação do SDK da Web da Platform.
Pré-requisitos
Este guia supõe que você esteja familiarizado com como os dados de identidade funcionam para o SDK da Web da plataforma, incluindo a função das ECIDs e identityMap. Consulte a visão geral em dados de identidade no SDK da Web para obter mais informações.
Uso de FPIDs
Os FPIDs rastreiam visitantes usando cookies primários. Os cookies primários são mais eficazes quando definidos com um servidor que usa um DNS Registro A (para IPv4) ou Registro AAAA (para IPv6), ao contrário de um CNAME DNS ou código JavaScript.
A ou AAAA os registros só são compatíveis com a configuração e o rastreamento de cookies. O método principal de coleta de dados é por meio de um CNAME DNS. Em outras palavras, os FPIDs são definidos usando um registro A ou AAAA e são enviados para o Adobe usando um CNAME.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 principais nos aplicativos do Adobe Experience Cloud.
Para enviar um FPID para um visitante do site para a Rede de borda da Platform, você deve incluir o FPID no identityMap para esse visitante. Consulte a seção mais adiante neste documento em uso de FPIDs no identityMap para obter mais informações.
Requisitos de formatação de ID
A Platform Edge Network aceita somente IDs que estejam em conformidade com a Formato UUIDv4. As IDs de dispositivo que não estão no formato UUIDv4 serão rejeitadas.
A geração de uma UUID quase sempre resultará em uma ID exclusiva e aleatória, com a probabilidade de ocorrência de uma colisão sendo negligenciável. UUIDv4 não pode ser propagado usando endereços IP ou quaisquer outras informações pessoais identificáveis (PII). Os UUIDs são universais e as bibliotecas podem ser encontradas para praticamente todas as linguagens de programação gerá-los.
Definição de um cookie de ID próprio na interface dos fluxos de dados setting-cookie-datastreams
Você pode especificar um nome de cookie na interface dos Fluxos de dados, onde a variável FPID em vez de ter que ler o valor do cookie e incluir o FPID no Mapa de identidade.
Consulte a documentação dos datastreams para obter informações detalhadas sobre como configurar um fluxo de dados.
Ao configurar seu fluxo de dados, ative a opção Cookie de ID próprio opção. Essa configuração informa à Rede de borda a consultar um cookie especificado ao pesquisar uma ID de dispositivo primário, em vez de pesquisar esse valor na variável Mapa de identidade.
Consulte a documentação em cookies próprios para obter mais detalhes sobre como eles trabalham com o 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 Visitor ID serviço e o UUID por esse serviço. Ao usar a funcionalidade de ID própria, a ECID é gerada sem o uso da Visitor ID o que torna impossíveis as sincronizações de ID de terceiros.
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. A ECID derivada de uma ID própria não está vinculada a uma UUID, tornando-o não endereçável.
Configurar um cookie usando seu próprio servidor
Ao definir um cookie usando um servidor que você possui, vários métodos podem ser usados para impedir que o cookie seja restrito devido a políticas do navegador:
- Gerar cookies usando linguagens de script do lado do servidor
- Definir cookies em resposta a uma solicitação de API feita a um subdomínio ou outro endpoint no site
- Gerar cookies usando um CMS
- Gerar cookies usando um CDN
document.cookie O método quase nunca será protegido de políticas do navegador que restrinjam a duração de cookies.Quando definir o cookie
Idealmente, o cookie FPID deve ser definido antes de fazer qualquer solicitação para a Rede de borda. No entanto, em cenários em que isso não é possível, uma ECID ainda é gerada usando métodos existentes e atua como o identificador principal, desde que o cookie exista.
Supondo que a ECID seja afetada por uma política de exclusão do navegador, mas o FPID não, o FPID se tornará o identificador principal na próxima visita e será usado para propagar a ECID em cada visita subsequente.
Definição da expiração do cookie
Definir a expiração de um cookie é algo que deve ser cuidadosamente considerado 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
Há vários sinalizadores de cookies que afetam como os cookies são tratados em navegadores diferentes:
HTTPOnly http-only
Cookies definidos usando o HTTPOnly o sinalizador não pode ser acessado usando scripts do lado do cliente. Isso significa que se você definir um HTTPOnly ao definir o FPID, você deve usar uma linguagem de script do lado do servidor para ler o valor do cookie para inclusão na variável identityMap.
Se você optar que a Platform Edge Network leia o valor do cookie FPID, definindo o HTTPOnly O sinalizador 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 da Rede de borda da plataforma de ler o cookie.
HTTPOnly O sinalizador não afeta as políticas de cookies que podem restringir a duração do cookie. No entanto, ainda é algo que você deve considerar ao definir e ler o valor do FPID.Secure secure
Cookies definidos com o Secure Os atributos são enviados somente ao servidor com uma solicitação criptografada pelo 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 a Secure sinalizador.
SameSite same-site
A variável SameSite O atributo 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 não SameSite for especificado, a configuração padrão para alguns navegadores será SameSite=Lax.
Uso de FPIDs no identityMap identityMap
Veja abaixo um exemplo de como você definiria um FPID na variável identityMap:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
Assim como em outros tipos de identidade, você pode incluir o FPID com outras identidades no identityMap. Este é um exemplo do FPID incluído com uma ID de CRM autenticada:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Se o FPID estiver contido em um cookie que está sendo lido pela Rede de borda quando a coleta de dados primários estiver ativada, você deverá capturar somente a ID do CRM autenticada:
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
As seguintes identityMap resultaria em uma resposta de erro da Rede de borda, pois a variável primary indicador do FPID. Pelo menos uma das IDs presentes no identityMap deve ser marcado como primary.
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"authenticatedState": "ambiguous"
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated"
}
]
}
}
A resposta de erro retornada pela Rede de borda 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}"
}
}
Hierarquia de ID
Quando uma ECID e uma FPID estão presentes, a ECID é priorizada na identificação do usuário. Isso garante que, quando uma ECID existente estiver presente no armazenamento de cookies do navegador, ela permanecerá o identificador principal e as contagens de visitantes existentes não correm o risco de ser afetadas. Para usuários existentes, o FPID não se tornará a identidade principal até que a ECID expire ou seja excluída como resultado de uma política de navegador ou processo manual.
As identidades são priorizadas na seguinte ordem:
- ECID incluída na
identityMap - ECID armazenada em um cookie
- FPID incluído no
identityMap - FPID armazenado em um cookie
Migração para IDs de dispositivos primários
Se você estiver migrando para o uso de FPIDs de uma implementação anterior, pode ser difícil visualizar como a transição pode ser 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 qual impacto uma migração de FPID teria em como esse cliente é identificado nas soluções Adobe.
ECID o cookie é sempre priorizado em relação ao FPID.Perguntas frequentes
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 seed é exclusivo, pois o FPID transmitido ao Adobe Experience Cloud é convertido em uma ECID usando um algoritmo determinístico. Sempre que o mesmo FPID for enviado para a Rede de borda da Adobe Experience Platform, a mesma ECID será propagada 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, uma ECID ainda será gerada para esse usuário e usada como o identificador principal. O FPID gerado não se tornará o identificador principal até que a ECID não esteja mais presente.
Quais métodos de coleta de dados oferecem suporte a IDs de dispositivos primários?
Atualmente, apenas o SDK da Web é compatível com FPIDs.
Os FPIDs são armazenados em alguma plataforma ou solução de Experience Cloud?
Depois que o FPID for usado para propagar uma ECID, ele será descartado do identityMap e substituído pela ECID que foi gerada. O FPID não está armazenado em nenhuma solução Adobe Experience Platform ou Experience Cloud.