Définition des Analytics ID et Experience Cloud ID setting-analytics-and-experience-cloud-ids
Le service Experience Cloud Identity remplace les anciennes méthodes d’identification des visiteurs d’Analytics.
Une fois le service d’ID mis en œuvre, ce code s’exécute avant AppMeasurement. Le service d’ID récupère les Experience Cloud et Analytics ID afin que ces valeurs soient prêtes au chargement d’AppMeasurement.
Au chargement d’AppMeasurement, les valeurs des Experience Cloud et Analytics ID sont demandées par le service d’ID et sont envoyées à la collecte de données avec chaque appel au serveur. Dans la mesure où le service d’ID détermine l’identifiant du visiteur et le transmet simplement à AppMeasurement, il doit être inclus et implémenté sur chaque page avant votre fichier JavaScript AppMeasurement.
Modifications du processus d’Analytics ID section-79bb86ae63f546419bb1a7ef5e710462
Le principal changement lors de la migration vers le service Experience Cloud ID concerne la définition du cookie ID. Désormais, il est défini à l’aide de JavaScript, plutôt que dans l’en-tête HTTP renvoyé par le serveur web de collecte de données. Pour comprendre cette modification, les sections suivantes décrivent comment les cookies sont définis à l’aide de ces deux méthodes.
En-tête HTTP
Une réponse HTTP d’un serveur Web définit les cookies dans un navigateur. C’est de cette façon que le s_vi cookie est défini. Le s_vi cookie identifie les visiteurs Analytics. Une fois défini, le cookie est envoyé à ce serveur avec toutes les demandes HTTP ultérieures.
Lors de l’envoi d’une demande au serveur de collecte de données Adobe, le cookie s_vi est recherché dans l’en-tête. S’il est présent dans la demande, il est utilisé pour identifier le visiteur. Dans le cas contraire, le serveur génère un Experience Cloud ID unique, le définit comme cookie dans l’en-tête de réponse HTTP, puis le renvoie avec la requête. Le cookie est stocké dans le navigateur et renvoyé au serveur de collecte de données au cours des visites suivantes du site. Cela permet au visiteur d’être identifié entre plusieurs visites.
Certains navigateurs, comme Apple Safari, n’acceptent toutefois pas de cookies tiers. Il s’agit de cookies définis dans le navigateur à partir de domaines autres que le site Web actif. En outre, Safari bloque les cookies des domaines tiers si un visiteur ne s’est pas rendu auparavant sur celui-ci. Supposons que vous visitiez le site mysite.com et que votre serveur de collecte de données soit mysite.omtrdc.net. Dans ce cas, le cookie renvoyé dans l’en-tête HTTP en provenance de mysite.omtrdc.net risque d’être rejeté par le navigateur.
Pour éviter ce cas de figure, de nombreux clients ont implémenté des enregistrements CNAME pour leurs serveurs de collecte de données dans le cadre d’une stratégie de mise en œuvre de cookies propriétaires. Si un enregistrement CNAME est configuré pour mapper un nom d’hôte sur le domaine du client au serveur de collecte de données (mappage de metrics.mysite.com à mysite.omtrdc.net, par exemple), le cookie Experience Cloud ID est stocké, étant donné que le domaine de collecte de données correspond désormais à celui du site web. Cela augmente la probabilité que le cookie du service d’ID soit stocké. Toutefois, cette opération entraîne des frais supplémentaires, car vous devez configurer des enregistrements CNAME et gérer des certificats SSL pour les serveurs de collecte de données.
JavaScript
JavaScript peut lire et écrire des cookies définis dans le domaine propriétaire (domaine du site Web actuel). Le service Experience Cloud ID applique cette méthode pour définir le cookie AMCV_###@AdobeOrg qui contient tous les identifiants visiteur. De cette manière, le domaine du serveur de suivi ne doit plus nécessairement correspondre à celui du site web pour que le cookie Identifiant visiteur soit stocké. Dans la plupart des cas, il s’agit de la méthode privilégiée pour définir le cookie du service d’ID, car elle élimine les frais supplémentaires liés aux enregistrements CNAME et des certificats SSL.
Analytics ID personnalisés section-b6a7bd19e9ff432390010062450808f6
La définition d’un ID de client à l’aide de s.visitorID permet d’identifier les utilisateurs dans Analytics. Cependant, les intégrations dans lesquelles des données Analytics sont exportées ou importées à l’aide du service d’ID ne fonctionneront pas lorsqu’un visiteur est identifié à l’aide de s.visitorID.
Cela comprend, sans s’y limiter, les audiences partagées, Analytics for Target (A4T) et les attributs du client. Pour ces intégrations, la définition d’un Analytics ID personnalisé n’est pas prise en charge.
Ordre des identifiants visiteur Analytics section-de1dc9fc9b6d4388995b70e35b8bcddf
Après avoir déployé le service d’ID des visiteurs, il existe cinq façons d’identifier un visiteur dans Analytics (répertoriées dans le tableau suivant par ordre de préférence) :
Un navigateur n’accepte pas les cookies tiers. Or, le serveur de suivi Analytics est configuré en tant que serveur de suivi tiers.
Remarque : Le fid est un identifiant hérité. Il n’est pas utilisé si vous avez implémenté le service d’ID sur votre site. Dans ce cas, le fid n’est pas nécessaire, car le cookie AMCV propriétaire le rend obsolète. Il a été conservé pour prendre en charge le code hérité et pour des raisons historiques.
Dans de nombreux scénarios, il se peut qu’il y ait 2 ou 3 ID distincts pour un appel. Analytics utilisera comme Experience Cloud ID officiel le premier ID présent dans cette liste. Par exemple, si vous définissez un identifiant visiteur personnalisé (y compris dans le paramètre de requête « vid »), cet identifiant sera utilisé avant les autres identifiants susceptibles d’être présents pour ce même accès.