Dados de identidade no SDK da Web

O SDK da Web da Adobe Experience Platform usa Adobe Experience Cloud IDs (ECIDs) para rastrear o comportamento do visitante. Usando ECIDs, você pode garantir que cada dispositivo tenha um identificador exclusivo que possa persistir em várias sessões, vinculando todas as ocorrências que ocorrem durante e entre sessões da Web a um dispositivo específico.

Este documento fornece uma visão geral de como gerenciar ECIDs usando o SDK da Web da plataforma.

Rastreamento de ECIDs usando o SDK

O SDK da Web da Platform atribui e rastreia ECIDs usando cookies, com vários métodos disponíveis para configurar como esses cookies são gerados.

Quando um novo usuário chega ao seu site, o Serviço de identidade da Adobe Experience Cloud tenta definir um cookie de identificação de dispositivo para esse usuário. Para visitantes novos, uma ECID é gerada e retornada na primeira resposta do Edge Network Adobe Experience Platform. Para visitantes repetidos, a ECID é recuperada do cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity e adicionada à carga pelo Edge Network.

Depois que o cookie contendo a ECID for definido, cada solicitação subsequente gerada pelo SDK da Web incluirá uma ECID codificada no cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity.

Ao usar cookies para identificação de dispositivo, você tem duas opções para interagir com o Edge Network:

Conforme explicado nas seções abaixo, o método de coleta de dados que você escolhe usar tem um impacto direto na vida útil do cookie nos navegadores.

Coleta de dados de terceiros third-party

A coleta de dados de terceiros envolve o envio de dados diretamente para o domínio Edge Network adobedc.net.

Nos últimos anos, os navegadores da Web têm se tornado cada vez mais restritivos no manuseio de cookies definidos por terceiros. Alguns navegadores bloqueiam cookies de terceiros por padrão. Se você usar cookies de terceiros para identificar visitantes do site, a vida útil desses cookies é quase sempre mais curta do que o que estaria disponível usando cookies primários. Às vezes, um cookie de terceiros expira em apenas sete dias.

Além disso, quando a coleta de dados de terceiros é usada, alguns bloqueadores de anúncios restringem o tráfego aos endpoints de coleta de dados do Adobe.

Coleta de dados primários first-party

A coleta de dados primários envolve a configuração de cookies por meio de um CNAME em seu próprio domínio que aponta para adobedc.net.

Embora os navegadores tenham durante muito tempo tratado os cookies definidos por endpoints CNAME de maneira semelhante aos definidos por endpoints pertencentes ao site, as alterações recentes implementadas pelos navegadores criaram uma distinção em como os cookies CNAME são tratados. Embora não haja navegadores que atualmente bloqueiam cookies próprios CNAME por padrão, alguns navegadores restringem a duração dos cookies definidos usando um CNAME para apenas sete dias.

Efeitos da duração do cookie em aplicativos Adobe Experience Cloud lifespans

Independentemente de você escolher a coleta de dados própria ou de terceiros, o tempo em que um cookie pode persistir tem um impacto direto na contagem de visitantes no Adobe Analytics e no Customer Journey Analytics. Além disso, os usuários finais podem experimentar experiências de personalização inconsistentes quando o Adobe Target ou o Offer Decisioning são usados no site.

Por exemplo, considere uma situação em que você criou uma experiência de personalização que promove qualquer item para a página inicial se um usuário o visualizou três vezes nos últimos sete dias.

Se um usuário final visitar três vezes por semana e não retornar ao site por sete dias, ele poderá ser considerado um novo usuário quando retornar ao site, pois seus cookies podem ter sido excluídos por uma política do navegador (dependendo do navegador usado quando visitou o site). Se isso ocorrer, a ferramenta do Analytics tratará o visitante como um novo usuário, embora ele tenha visitado o site há pouco mais de sete dias. Além disso, qualquer esforço para personalizar a experiência do usuário começa novamente.

IDs de dispositivo próprio

Para levar em conta os efeitos da duração do cookie conforme descrito acima, você pode optar por definir e gerenciar seus próprios identificadores de dispositivo. Consulte o manual sobre IDs de dispositivo próprio para obter mais informações.

Recuperar a ECID e a região do usuário atual retrieve-ecid

Dependendo do seu caso de uso, há duas maneiras de acessar o ECID:

Recuperar o ECID por meio do Preparo de Dados para a Coleção de Dados retrieve-ecid-data-prep

Use o Preparo de Dados para a Coleção de Dados para mapear o ECID para um campo XDM. Esta é a maneira recomendada de acessar o ECID.

Para fazer isso, defina o campo de origem para o seguinte caminho:

xdm.identityMap.ECID[0].id

Em seguida, defina o campo de destino como um caminho XDM, onde o campo é do tipo string.

Recuperar o ECID através do comando getIdentity() retrieve-ecid-getidentity

Para recuperar a ECID exclusiva do visitante atual, use o comando getIdentity. Para visitantes novos que ainda não têm um ECID, esse comando gera um novo ECID. getIdentity também retorna a ID da região do visitante.

alloy("getIdentity")
  .then(function(result) {
    // The command succeeded.
    console.log("ECID:", result.identity.ECID);
    console.log("RegionId:", result.edge.regionId);
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information.
  });

Usando o identityMap using-identitymap

Usando um campo XDM identityMap, você pode identificar um dispositivo/usuário usando várias identidades, definir seu estado de autenticação e decidir qual identificador é considerado o principal. Se nenhum identificador tiver sido definido como primary, o padrão principal será ECID.

identityMap campos são atualizados usando o comando sentEvent.

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "authenticated",
          "primary": true
        }
      ]
    }
  }
});

Cada propriedade em identityMap representa identidades pertencentes a um namespace de identidade específico. O nome da propriedade deve ser o símbolo de namespace de identidade, que pode ser encontrado listado na interface do usuário do Adobe Experience Platform em "Identidades". O valor da propriedade deve ser uma matriz de identidades pertencentes a esse namespace de identidade.

Cada objeto de identidade na matriz de identidades contém as seguintes propriedades:

O uso do campo identityMap para identificar dispositivos ou usuários leva ao mesmo resultado que o uso do método setCustomerIDs de ID Service API. Consulte a documentação da API do serviço de ID para obter mais detalhes.

Migração da API do visitante para ECID

Ao migrar do usando a API do visitante, também é possível migrar os cookies AMCV existentes. Para habilitar a migração da ECID, defina o parâmetro idMigrationEnabled na configuração. A migração de ID habilita os seguintes casos de uso:

Atualização de características para migração

Quando dados formatados em XDM são enviados para o Audience Manager, esses dados devem ser convertidos em sinais ao migrar. Suas características devem ser atualizadas para refletir as novas chaves que o XDM fornece. Este processo é facilitado com a ferramenta BAAAM criada pelo Audience Manager.

Usar no encaminhamento de eventos

Se você tiver o encaminhamento de eventos habilitado e estiver usando o appmeasurement.js e o visitor.js, poderá manter o recurso de encaminhamento de eventos habilitado e isso não causará problemas. No back-end, o Adobe busca segmentos AAM e os adiciona à chamada para o Analytics. Se a chamada para o Analytics contiver esses segmentos, o Analytics não chamará o Audience Manager para encaminhar dados, portanto, não há nenhuma coleta de dados dupla. Também não há necessidade de Dica de localização ao usar o SDK da Web, pois os mesmos pontos de extremidade de segmentação são chamados no back-end.