Adobe Experience Cloud IDs

O SDK da Web da Adobe Experience Platform aproveita o Adobe Identity Service. Isso garante que cada dispositivo tenha um identificador exclusivo que seja mantido no dispositivo para que a atividade entre páginas possa ser vinculada.

Identidade própria

O Identity Service armazena a identidade em um cookie em um domínio próprio. O Identity Service tenta definir o cookie usando um cabeçalho HTTP no domínio. Se isso falhar, o Identity Service voltará à configuração de cookies com JavaScript. É recomendável configurar um CNAME para a Edge Domain config.

Cada ocorrência proveniente do SDK da Web da plataforma tem uma ECID adicionada a ela pelo Serviço de identidade na Rede de borda. Para visitantes pela primeira vez, a ECID é gerada e adicionada à carga. Para visitantes repetitivos, a ECID é recuperada do cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity e adicionada à carga.

A ECID é adicionada sob o campo identityMap em seu xdm. Usando a ferramenta dev do navegador, você pode exibir a ECID na resposta sob a carga com o tipo : identity:result, mas você não pode ver a ECID na solicitação.

Implementações CNAME permitem personalizar o domínio de coleção usado pelo Adobe para que corresponda ao seu próprio domínio. Isso permite que o Adobe defina cookies primários no lado do servidor, em vez de no lado do cliente, usando JavaScript. Anteriormente, esses cookies primários do lado do servidor não estavam sujeitos aos limites impostos pela política de Prevenção de Rastreamento Inteligente (ITP) da Apple em navegadores Safari. No entanto, em novembro de 2020, a Apple atualizou suas políticas para que essas limitações também fossem aplicadas a cookies definidos por CNAME. Atualmente, os cookies definidos no lado do servidor pelo CNAME e os cookies definidos no lado do cliente pelo JavaScript são limitados a um prazo de sete dias ou 24 horas no ITP. Para obter mais informações sobre a política ITP, consulte este documento da Apple sobre prevenção de rastreamento.

Embora a implementação CNAME não forneça benefícios em termos de duração do cookie, pode haver outros benefícios, como bloqueadores de anúncios e navegadores menos comuns, impedindo que os dados sejam enviados para domínios que classificam como rastreadores. Nesses casos, o uso de um CNAME pode impedir que sua coleta de dados seja interrompida para usuários que utilizam essas ferramentas.

Identidade de terceiros

O Identity Service tem a capacidade de sincronizar uma ID com um domínio de terceiros (demdex.net) para ativar o rastreamento entre sites. Quando isso estiver ativado, a primeira solicitação de um visitante (por exemplo, alguém sem uma ECID) será feita para demdex.net. Isso só será feito em navegadores que permitem (como o Chrome) e é controlado pelo parâmetro thirdPartyCookiesEnabled na configuração. Se quiser desativar esse recurso completamente, defina thirdPartyCookiesEnabled como falso.

Migração de ID

Ao migrar da API de visitante, você também pode migrar cookies AMCV existentes. Para habilitar a migração da ECID, defina o parâmetro idMigrationEnabled na configuração. A migração de ID permite os seguintes casos de uso:

  • Quando algumas páginas de um domínio estão usando a API do visitante e outras estão usando esse SDK. Para ser compatível com esse caso, o SDK lê os cookies AMCV existentes e grava um novo cookie com a ECID existente. Além disso, o SDK grava cookies AMCV para que, se a ECID for obtida primeiro em uma página instrumentada com o SDK, as páginas subsequentes instrumentadas com a API do visitante tenham a mesma ECID.
  • Quando o SDK da Web da Adobe Experience Platform é configurado em uma página que também tem a API do visitante. Para ser compatível com esse caso, se o cookie AMCV não estiver definido, o SDK procura a API do visitante na página e a chama para obter a ECID.
  • Quando o site inteiro estiver usando o SDK da Web da Adobe Experience Platform e não tiver a API de visitante, é útil migrar as ECIDs para que as informações de visitante de retorno sejam retidas. Depois que o SDK é implantado com idMigrationEnabled por um período de tempo para que a maioria dos cookies do visitante seja migrada, a configuração pode ser desativada.

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

Quando os dados formatados do XDM são enviados para o Audience Manager, esses dados precisam ser convertidos em sinais ao migrar. Suas características precisarão ser atualizadas para refletir as novas chaves fornecidas pelo XDM. Esse processo é facilitado usando a ferramenta BAAAM que o Audience Manager criou.

Encaminhamento pelo lado do servidor

Se você tiver o encaminhamento pelo lado do servidor habilitado e estiver usando appmeasurement.js. e visitor.js você pode manter o recurso de encaminhamento pelo lado do servidor habilitado e isso não causará problemas. No back-end, o Adobe busca qualquer segmento de 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, de modo que não haja 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 endpoints de segmentação são chamados no back-end.

Recuperar a ID de visitante e a ID de região

Se quiser usar a ID de visitante exclusiva, use o comando getIdentity. getIdentity retorna a ECID existente para o visitante atual. Para visitantes pela primeira vez que ainda não têm uma ECID, esse comando gera uma nova ECID. getIdentity também retorna a ID da região do visitante. Consulte o Guia do Usuário do Adobe Audience Manager para obter mais informações.

OBSERVAÇÃO

Normalmente, esse método é usado com soluções personalizadas que exigem a leitura da ID Experience Cloud ou precisam da dica de localização do Adobe Audience Manager. Ela não é usada em uma implementação padrão.

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

Sincronização de identidades

OBSERVAÇÃO

O método syncIdentity foi removido na versão 2.1.0, além do recurso de hash. Se estiver usando a versão 2.1.0+ e quiser sincronizar identidades, é possível enviá-las diretamente na opção xdm do comando sendEvent, no campo identityMap.

Além disso, o Identity Service permite sincronizar seus próprios identificadores com a ECID usando o comando syncIdentity.

OBSERVAÇÃO

É altamente recomendável transmitir todas as identidades disponíveis em cada comando sendEvent. Isso desbloqueia uma variedade de casos de uso, incluindo personalização. Agora que você pode passar essas identidades no comando sendEvent, elas podem ser colocadas diretamente em seu DataLayer.

A sincronização de identidades permite 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.

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

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

Cada objeto de identidade na matriz de identidades é estruturado da seguinte maneira:

id

Tipo Obrigatório Valor padrão
String Sim None

Essa é a ID que você deseja sincronizar para o namespace em questão.

authenticationState

Tipo Obrigatório Valor padrão Valores possíveis
String Sim ambíguo ambíguo, autenticado e loggedOut

O estado de autenticação da ID.

primary

Tipo Obrigatório Valor padrão
Booleano opcional false

Determina se essa identidade deve ser usada como um fragmento principal no perfil unificado. Por padrão, a ECID é definida como o identificador principal do usuário.

Nesta página