Données d’identité dans le SDK Web

Le SDK Web de Adobe Experience Platform utilise Adobe Experience Cloud ID (ECID) pour effectuer le suivi du comportement des visiteurs. Grâce aux ECID, vous pouvez vous assurer que chaque appareil dispose d’un identifiant unique qui peut persister au cours de plusieurs sessions, en liant tous les accès qui surviennent pendant et entre les sessions web à un appareil spécifique.

Ce document présente la gestion des ECID à l’aide du SDK Web Platform.

Suivi des ECID à l’aide du SDK

Le SDK Web Platform affecte et suit les ECID à 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 Adobe Experience Cloud Identity tente de définir un cookie d’identification de périphérique pour cet utilisateur. Pour les nouveaux visiteurs, un ECID est généré et renvoyé dans la première réponse du réseau Adobe Experience Platform Edge. Pour les visiteurs réguliers, l’ECID est récupéré à partir de la variable kndctr_{YOUR-ORG-ID}_AdobeOrg_identity et ajouté à la charge utile par le réseau Edge.

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

Lors de l’utilisation de cookies pour l’identification des périphériques, vous disposez de deux options pour interagir avec le réseau Edge :

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.

Collecte de données tierces third-party

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

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 par défaut les cookies tiers. Si vous utilisez des cookies tiers pour identifier les visiteurs du site, la durée de vie de ces cookies est presque toujours plus courte que celle qui serait normalement disponible à l’aide de cookies propriétaires. Parfois, un cookie tiers expire dans seulement sept jours.

En outre, lorsque la collecte de données tierces est utilisée, certains bloqueurs d’annonces limitent le trafic aux points de terminaison de collecte de données d’Adobe.

Collecte de données propriétaires first-party

La collecte de données propriétaires 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 les points de terminaison CNAME de la même manière que ceux définis par les points de terminaison détenus par le site, les récentes modifications implémentées par les navigateurs ont créé une distinction dans la manière dont les cookies CNAME sont géré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.

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étaires ou tierces, la durée de conservation d’un cookie 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 lorsqu’Adobe Target ou Offer Decisioning sont utilisés sur le site.

Supposons, par exemple, que vous ayez créé une expérience de personnalisation qui fait la promotion d’un é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 se rend sur le site trois fois par semaine, puis ne revient pas sur le site pendant sept jours, il peut être considéré comme un nouvel utilisateur lorsqu’il revient sur le site, car ses cookies peuvent avoir été supprimés par une stratégie de navigateur (en fonction du navigateur utilisé 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, toute tentative de personnalisation de l’expérience pour l’utilisateur recommence.

Identifiants d’appareils propriétaires

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ération de l’ECID et de la région pour l’utilisateur actuel

Pour récupérer l’ECID unique du visiteur actuel, utilisez la variable getIdentity . Pour les nouveaux visiteurs qui n’ont pas encore d’ECID, cette commande génère un nouvel ECID. getIdentity renvoie également l’identifiant de région du 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.
  });

Utilisation de identityMap

Utilisation de XDM identityMap field, 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 l’identifiant principal. Si aucun identifiant n’a été défini comme primary, la valeur par défaut principale est la valeur ECID.

identityMap Les champs sont mis à jour à l’aide de la fonction 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 les identités appartenant à un espace de noms d’identité. Le nom de la propriété doit être le symbole de l’espace de noms d’identité, que vous trouverez dans l’interface utilisateur de Adobe Experience Platform sous "Identités". La valeur de propriété doit être un tableau d’identités appartenant à cet espace de noms d’identité.

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

En utilisant la variable identityMap pour identifier les appareils ou les utilisateurs, le résultat obtenu est le même que pour l’utilisation de la variable setCustomerIDs de la méthode ID Service API. Voir Documentation de l’API du service d’ID pour plus d’informations.

Migration de l’API visiteur vers ECID

Lors de la migration depuis à l’aide de l’API visiteur, vous pouvez également migrer les cookies AMCV existants. Pour activer la migration ECID, définissez la variable idMigrationEnabled dans la configuration. La migration des identifiants permet 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 plus facile en utilisant la variable Outil BAAAM cette Audience Manager a été créée.

Utilisation dans le transfert d’événement

Si vous avez actuellement transfert d’événement activée et utilisent appmeasurement.js et visitor.js, vous pouvez conserver la fonction de transfert d’événement activée, ce qui ne posera 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 aucune donnée. Il n’y a donc pas de collecte de données double. Il n’est pas non plus nécessaire d’avoir des conseils sur l’emplacement lors de l’utilisation du SDK Web, car les mêmes points de fin de segmentation sont appelés dans le serveur principal.