Definir Analytics e Experience Cloud IDs setting-analytics-and-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 section-79bb86ae63f546419bb1a7ef5e710462
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.
IDs personalizadas do Analytics section-b6a7bd19e9ff432390010062450808f6
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 section-de1dc9fc9b6d4388995b70e35b8bcddf
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):
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.
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.