Show Menu
TOPICS×

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.
Após o serviço de ID ser implementado, este 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 no 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 mudança, as seções a seguir descrevem como os cookies são definidos usando estes dois métodos.
Cabeçalho HTTP
Uma resposta HTTP de um servidor da Web define os cookies de 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 para o servidor responsável pela coleta de dados durante as visitas subsequentes ao site. Isso permite que o visitante seja identificado quando fizer uma visita.
No entanto, alguns navegadores, como o Apple Safari, não aceitam cookies de terceiros. Esses cookies são definidos no navegador por domínios diferentes daqueles do site atual. Além disso, o Safari bloqueia cookies em domínios de terceiros se um visitante estiver naquele domínio pela primeira vez. 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. Essa 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 dos cookies do serviço de ID serem armazenados. No entanto, isso apresenta alguma sobrecarga porque é necessário configurar os registros CNAME e manter os certificados SSL dos servidores responsáveis pela coleta de dados.
JavaScript
O JavaScript pode ler e gravar cookies definidos pelo 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. Essa costuma ser a maneira preferida para definir o cookie do serviço de ID, pois elimina a sobrecarga dos registros CNAME e certificados SSL.
Entretanto, existem algumas situações em que definir o cookie no cabeçalho HTTP traz vantagens para o Rastreamento entre domínios, descrito em Coletas de dados CNAME 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):
Ordem usada
Parâmetro de consulta (método de coleta)
Presente 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 (AMCV_ cookie 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.