Show Menu
TÓPICOS×

Definir Analytics e Experience Cloud IDs

O serviço de identidade da Experience Cloud substitui os métodos de ID de visitante herdados do Analytics.
Depois que o serviço de ID é implementado, esse código é executado antes do AppMeasurement. O serviço de ID recupera as IDs da Experience Cloud e do Analytics para que esses valores estejam prontos quando o AppMeasurement for carregado.
Quando o AppMeasurement é carregado, os valores das IDs da Experience Cloud e do Analytics são solicitados do serviço de ID e enviados para a coleta de dados com cada chamada de servidor. Como o serviço de ID determina a ID de visitante e a transfere para o AppMeasurement, o serviço de ID deve ser incluído e implementado em cada página antes do arquivo JavaScript do AppMeasurement.

Mudanças no processo de ID do Analytics

A mudança principal ao migrar para o serviço de ID da Experience Cloud é que o cookie da ID é configurado usando o JavaScript em vez do cabeçalho HTTP retornado pelo servidor da Web da coleta de dados. Para entender essa alteração, as seções a seguir descrevem como os cookies são definidos usando esses dois métodos.
Cabeçalho HTTP
Uma resposta HTTP de um servidor da Web define cookies em um navegador. É assim que o s_vi cookie é definido. O s_vi cookie identifica os visitantes do Analytics. Depois que um cookie é configurado, ele é enviado com todas as solicitações HTTP subsequentes para esse servidor.
Quando uma solicitação é enviada para o servidor de coleta de dados da Adobe, o cabeçalho é verificado para procurar um cookie s_vi . Se este cookie estiver na solicitação, ele é usado para identificar o visitante. Se o cookie não está na solicitação, o servidor gera uma Experience Cloud ID exclusiva, a configura como um cookie no cabeçalho de resposta HTTP e a envia com a solicitação. O cookie é armazenado no navegador e enviado de volta ao servidor de coleta de dados durante visitas subsequentes ao site. Isso permite que o visitante seja identificado nas visitas.
No entanto, alguns navegadores, como o Apple Safari, não aceitam cookies de terceiros. Esses cookies são definidos no navegador a partir de domínios diferentes do site atual. Além disso, o Safari bloqueia cookies em domínios de terceiros se um visitante não tiver estado nesse domínio antes. Por exemplo, se você está em mysite.com e o servidor de coleta de dados for mysite.omtrdc.net , o cookie retornado no cabeçalho HTTP de mysite.omtrdc.net pode ser rejeitado pelo navegador.
Para evitar isso, vários clientes implementaram registros CNAME para os servidores responsáveis pela coleta de dados. Esta pode ser uma parte eficiente de uma estratégia de implementação de cookies próprios . Se um registro CNAME estiver configurado para mapear um nome de host no domínio do cliente para o servidor de coleta de dados (por exemplo, mapear metrics.mysite.com para mysite.omtrdc.net ), o cookie da Experience Cloud é armazenado, pois o domínio de coleta de dados agora corresponde ao domínio do site. Isso aumenta a probabilidade de o cookie do serviço de ID ser armazenado. No entanto, isso apresenta alguma sobrecarga, pois é necessário configurar registros CNAME e manter certificados SSL para os servidores de coleta de dados.
JavaScript
O JavaScript pode ler e gravar cookies definidos no domínio próprio (o domínio do site atual). O serviço da Experience Cloud ID usa esse método para definir o cookie AMCV_###@AdobeOrg que contém todas as IDs de visitante, para que o domínio do servidor de rastreamento não precise mais corresponder ao domínio do site para que o cookie da ID seja armazenado. Na maioria das circunstâncias, essa é a maneira preferida de definir o cookie do serviço de ID, pois elimina a sobrecarga dos registros CNAME e certificados SSL.
Entretanto, há algumas situações em que a configuração do cookie no cabeçalho HTTP é benéfica para o rastreamento entre domínios, que estão descritas em CNAMEs de coleção de dados e Rastreamento entre domínios .

IDs personalizadas do Analytics

Definir uma ID do cliente usando s.visitorID é um método para identificar usuários no Analytics. No entanto, as integrações em que os dados do Analytics são exportados ou importados usando o Serviço de ID não funcionam quando um visitante é identificado usando s.visitorID .
Isso inclui, mas não está limitado a, públicos-alvo compartilhados, Analytics for Target (A4T) e atributos do cliente. Para essas integrações, não há suporte para uma ID personalizada do Analytics.

Ordem da ID de visitante do Analytics

Depois de implantar o serviço de ID de visitante, há cinco maneiras de identificar um visitante no Analytics (listadas na tabela a seguir em ordem de preferência):
Pedido usado Parâmetro do query (método de coleta) Apresentar quando
s.visitorID está definido
O visitante tinha um s_vi cookie antes de você implantar o serviço de ID da Experience Cloud ou você tem um período de carência configurado.
mid (cookie AMCV_ definido pelo serviço de ID de visitante da Experience Cloud)
O navegador do visitante aceita cookies próprios
Um navegador não aceita cookies de terceiros e o servidor de rastreamento do Analytics está configurado como um servidor de rastreamento de terceiros.
Observação: o fid é um identificador herdado e não é usado se você implementou o serviço de ID do site. Nesse caso, o fid não é necessário porque o cookie próprio AMCV o torna obsoleto. Foi mantido para comportar o código herdado e por motivos históricos.
O navegador do visitante não aceita cookies.
Em muitos casos, você verá duas ou três IDs diferentes em uma chamada, mas o Analytics usará a primeira ID apresentada na lista como a Experience Cloud oficial. Por exemplo, se você estiver enviando uma ID de visitante personalizada (incluída no parâmetro de consulta "vid"), essa ID será usada antes de outras IDs que possam estar presentes nessa mesma ocorrência.