Dados de identidade no Web SDK

O Adobe Experience Platform Web SDK usa Adobe Experience Cloud IDs (ECIDs) para rastrear o comportamento do visitante. Usando o 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 e CORE IDs usando o Web SDK.

Rastreamento de ECIDs usando o Web SDK tracking-ecids-web-sdk

O Web SDK 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 Adobe Experience Cloud Identity Service tenta definir um cookie de identificação do dispositivo para esse usuário.

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

Ao usar cookies para identificação de dispositivo, você tem duas maneiras de 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.

Rastreamento de IDs principais usando o Web SDK tracking-coreid-web-sdk

Ao usar o Google Chrome com cookies de terceiros habilitados e não houver nenhum cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity definido, a primeira solicitação de Edge Network passa por um domínio demdex.net, que define um cookie demdex. Este cookie contém um CORE ID. Este é um identificador de usuário único, diferente do ECID.

Dependendo da sua implementação, talvez você queira acessar o CORE ID.

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 cookies definidos por CNAME pontos de extremidade de maneira semelhante aos definidos por pontos de extremidade de propriedade do 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 o tempo de vida dos cookies definidos com um CNAME para apenas sete dias.

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, ao usar a coleta de dados de terceiros, alguns bloqueadores de anúncios restringem o tráfego aos endpoints de coleta de dados do Adobe.

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

Independentemente de você escolher a coleção de dados próprios ou de terceiros, o período de tempo em que um cookie pode persistir tem um impacto direto na contagem de visitantes no Adobe Analytics e 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 acontecer, 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 (FPIDs) fpid

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.
  });

Recuperar a ID PRINCIPAL do usuário atual retrieve-coreid

Para recuperar a ID CORE de um usuário, você pode usar o comando getIdentity(), conforme mostrado abaixo.

alloy("getIdentity",{
  "namespaces": ["CORE"]
});

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 migrating-visitor-api-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 Web SDK, pois os mesmos pontos de extremidade de segmentação são chamados no back-end.