Données d’identité dans Web SDK

Adobe Experience Platform Web SDK utilise des identifiants Adobe Experience Cloud (ECID) pour suivre le comportement des visiteurs. Grâce à ECIDs, vous pouvez vous assurer que chaque appareil dispose d’un identifiant unique qui peut persister sur plusieurs sessions, liant tous les accès qui se produisent pendant et entre les sessions web à un appareil spécifique.

Ce document présente un aperçu de la gestion des ECIDs et des CORE IDs à l’aide de Web SDK.

Suivi des ECID à l’aide de Web SDK tracking-ecids-web-sdk

Le SDK Web attribue et suit les ECIDs à l’aide de cookies, avec plusieurs méthodes disponibles pour configurer la manière dont ces cookies sont générés.

Lorsqu’un nouvel utilisateur arrive sur votre site web, le service d’identités Adobe Experience Cloud tente de définir un cookie d’identification d’appareil pour cet utilisateur.

Une fois le cookie contenant le ECID défini, chaque requête suivante générée par le SDK Web inclut un ECID codé dans le cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity.

Lors de l’utilisation de cookies pour l’identification d’un appareil, vous avez deux façons d’interagir avec l’Edge Network :

Comme expliqué dans les sections ci-dessous, la méthode de collecte de données que vous choisissez d’utiliser a un impact direct sur la durée de vie des cookies dans les navigateurs.

Suivi des identifiants CORE à l’aide de Web SDK tracking-coreid-web-sdk

Lors de l’utilisation de Google Chrome avec des cookies tiers activés et qu’aucun cookie kndctr_{YOUR-ORG-ID}_AdobeOrg_identity n’est défini, la première demande d’Edge Network passe par un domaine demdex.net, qui définit un cookie demdex. Ce cookie contient un CORE ID. Il s’agit d’un identifiant utilisateur unique, différent du ECID.

Selon votre implémentation, vous pouvez accéder au CORE ID.

Collecte de données propriétaire first-party

La collecte de données propriétaire implique de définir des cookies par le biais d’un CNAME sur votre propre domaine qui pointe vers adobedc.net.

Bien que les navigateurs aient longtemps traité les cookies définis par CNAME points d’entrée de la même manière que ceux définis par les points d’entrée appartenant au site, des modifications récentes mises en œuvre par les navigateurs ont créé une distinction dans la manière dont les cookies CNAME sont traités. Bien qu’aucun navigateur ne bloque actuellement les cookies CNAME propriétaires par défaut, certains navigateurs limitent la durée de vie des cookies définis à l’aide d’un CNAME à seulement sept jours.

Collecte de données tierces third-party

La collecte de données tierces implique l’envoi direct de données au adobedc.net de domaine Edge Network.

Ces dernières années, les navigateurs web sont devenus de plus en plus restrictifs dans leur gestion des cookies définis par des tiers. Certains navigateurs bloquent les cookies tiers par défaut. Si vous utilisez des cookies tiers pour identifier les visiteurs du site, la durée de vie de ces cookies est presque toujours inférieure à celle qui serait disponible autrement à l’aide de cookies propriétaires. Parfois, un cookie tiers arrive à expiration dans un délai aussi court que sept jours.

En outre, lorsque vous utilisez la collecte de données tierce, certains bloqueurs d’annonces limitent le trafic aux points d’entrée de la collecte de données d’Adobe.

Effets de la durée de vie des cookies sur les applications Adobe Experience Cloud lifespans

Que vous choisissiez la collecte de données propriétaire ou tierce, la durée pendant laquelle un cookie peut persister a un impact direct sur le nombre de visiteurs dans Adobe Analytics et Customer Journey Analytics. En outre, les utilisateurs finaux peuvent rencontrer des expériences de personnalisation incohérentes lorsque Adobe Target ou Offer decisioningsont utilisés sur le site.

Supposons, par exemple, que vous ayez créé une expérience de personnalisation qui promeut n’importe quel élément sur la page d’accueil si un utilisateur l’a consulté trois fois au cours des sept derniers jours.

Si un utilisateur final visite le site trois fois par semaine et ne revient pas sur le site pendant sept jours, il peut être considéré comme un nouvel utilisateur lorsqu’il y revient, car ses cookies peuvent avoir été supprimés par une politique de navigateur (en fonction du navigateur qu’il utilisait lors de sa visite). Si cela se produit, votre outil Analytics traite le visiteur comme un nouvel utilisateur, même s’il a visité le site il y a un peu plus de sept jours. En outre, tout effort de personnalisation de l’expérience pour l’utilisateur ou l’utilisatrice recommence.

Identifiants d’appareils propriétaires (FPID) fpid

Pour tenir compte des effets de la durée de vie des cookies comme indiqué ci-dessus, vous pouvez choisir de définir et de gérer vos propres identifiants d’appareil à la place. Pour plus d’informations, consultez le guide des Identifiants d’appareils propriétaires.

Récupérer l’ECID et la région pour l’utilisateur actuel retrieve-ecid

Selon votre cas d’utilisation, vous pouvez accéder au ECID de deux façons :

Récupérez le ECID via la préparation des données pour la collecte de données retrieve-ecid-data-prep

Utilisez Préparation des données pour la collecte de données pour mapper la ECID à un champ XDM. Il s’agit de la méthode recommandée pour accéder au ECID.

Pour ce faire, définissez le champ source sur le chemin suivant :

xdm.identityMap.ECID[0].id

Définissez ensuite le champ cible sur un chemin XDM où le champ est de type string.

Récupérez le ECID via la commande getIdentity() retrieve-ecid-getidentity

Pour récupérer l’ECID unique du visiteur actuel, utilisez la commande getIdentity . Pour les nouveaux visiteurs qui n’ont pas encore de ECID, cette commande génère une nouvelle ECID. getIdentity renvoie également l’ID de région pour le visiteur.

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

Récupérer l’ID CORE pour l’utilisateur actuel retrieve-coreid

Pour récupérer l’ID CORE d’un utilisateur, vous pouvez utiliser la commande getIdentity(), comme illustré ci-dessous.

alloy("getIdentity",{
  "namespaces": ["CORE"]
});

Utilisation de identityMap using-identitymap

À l’aide d’un champ de identityMap XDM vous pouvez identifier un appareil/utilisateur à l’aide de plusieurs identités, définir son état d’authentification et décider quel identifiant est considéré comme le principal. Si aucun identifiant n’a été défini comme primary, le principal est par défaut le ECID.

identityMap champs sont mis à jour à l’aide de la commande sentEvent .

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

Chaque propriété dans identityMap représente des identités appartenant à un espace de noms d’identité particulier. Le nom de la propriété doit être le symbole d’espace de noms d’identité. Il est répertorié dans l’interface utilisateur de Adobe Experience Platform sous « Identités ». La valeur de la propriété doit être un tableau d’identités appartenant à cet espace de noms d’identité.

Chaque objet d’identité du tableau d’identités contient les propriétés suivantes :

L’utilisation du champ identityMap pour identifier les appareils ou les utilisateurs aboutit au même résultat que l’utilisation de la méthode setCustomerIDs du ID Service API . Pour plus d’informations🔗 consultez la documentation de l’API du service ID.

Migration de l’API visiteur vers ECID migrating-visitor-api-ecid

Lors de la migration à partir de à l’aide de l’API visiteur, vous pouvez également migrer les cookies AMCV existants. Pour activer la migration ECID, définissez le paramètre idMigrationEnabled dans la configuration. La migration des identifiants active les cas d’utilisation suivants :

Mise à jour des caractéristiques pour la migration

Lorsque des données au format XDM sont envoyées en Audience Manager, ces données doivent être converties en signaux lors de la migration. Vos caractéristiques doivent être mises à jour pour refléter les nouvelles clés fournies par XDM. Ce processus est facilité par l’utilisation de l’outil BAAAM créé par l’Audience Manager.

Utilisation dans le transfert d’événement

Si le transfert d’événement est actuellement activé et que vous utilisez appmeasurement.js et visitor.js, vous pouvez conserver la fonctionnalité de transfert d’événement activée, ce qui ne provoquera aucun problème. Sur le serveur principal, Adobe récupère tous les segments AAM et les ajoute à l’appel à Analytics. Si l’appel à Analytics contient ces segments, Analytics n’appelle pas l’Audience Manager pour transférer des données. Il n’y a donc pas de double collecte de données. Il n’est pas non plus nécessaire d’utiliser l’indicateur d’emplacement lors de l’utilisation de Web SDK, car les mêmes points d’entrée de segmentation sont appelés dans le serveur principal.