Show Menu
SUJETS×

Identité - Récupération de l'ID d'Experience Cloud

Le Adobe Experience Platform Web SDK tire parti du service d'identité Adobe. Ainsi, chaque périphérique dispose d’un identifiant unique qui est conservé sur le périphérique, de sorte que l’activité entre les pages puisse être liée ensemble.

Identité de premier niveau

L’ Identity Service utilisateur stocke l’identité dans un cookie dans un domaine propriétaire. Le cookie Identity Service tente de le définir à l’aide d’un en-tête HTTP sur le domaine. Si cela échoue, la Identity Service fonction revient à définir des cookies via Javascript. adobe vous recommande de configurer un CNAME pour vous assurer que vos cookies ne seront pas plafonnés par les restrictions ITP côté client.

Identité tierce

Il Identity Service peut synchroniser un identifiant avec un domaine tiers (demdex.net) pour activer le suivi sur plusieurs sites. Lorsque cette option est activée, la première demande d’un visiteur (par exemple, une personne sans ECID) sera envoyée à demdex.net. Cela ne sera fait que sur les navigateurs qui l’autorisent (Chrome, par exemple) et qui est contrôlé par le thirdPartyCookiesEnabled paramètre de la configuration. Si vous souhaitez désactiver cette fonctionnalité ensemble, définissez la valeur thirdPartyCookiesEnabled sur false.

Migration des identifiants

Lors de la migration à partir de l’API du Visiteur, vous pouvez également migrer les cookies AMCV existants. Pour activer la migration ECID, définissez le idMigrationEnabled paramètre dans la configuration. La migration des identifiants est configurée pour activer certains cas d’utilisation :
  • Lorsque certaines pages d’un domaine utilisent l’API du Visiteur et que d’autres pages utilisent ce SDK. Pour prendre en charge ce cas, le SDK lit les cookies AMCV existants et écrit un nouveau cookie avec l’ECID existant. En outre, le SDK écrit des cookies AMCV de sorte que si l’ECID est obtenu en premier sur une page instrumentée avec le SDK Web AEP, les pages suivantes instrumentées avec l’API Visiteur ont le même ECID.
  • Lorsque le SDK Web AEP est configuré sur une page qui comporte également une API de Visiteur. Pour prendre en charge ce cas, si le cookie AMCV n’est pas défini, le SDK recherche l’API du Visiteur sur la page et l’appelle pour obtenir l’ECID.
  • Lorsque le site entier utilise le SDK Web AEP et ne dispose pas d’API de Visiteur, il est utile de migrer les ECID pour que les informations de visiteur de retour soient conservées. Une fois le SDK déployé idMigrationEnabled pendant un certain temps afin que la plupart des cookies visiteurs soient migrés, le paramètre peut être désactivé.

Récupération de l’ID de Visiteur

Si vous souhaitez utiliser cet identifiant unique, utilisez la getIdentity commande. getIdentity renvoie l'ECID existant pour le visiteur actuel. Pour les nouveaux visiteurs qui n'ont pas encore d'ECID, cette commande génère un nouvel ECID.
This method is typically used with custom solutions that require reading the Experience Cloud ID. Elle n’est pas utilisée par une mise en œuvre standard.
alloy("getIdentity")
  .then(function(result.identity.ECID) {
    // This function will get called with Adobe Experience Cloud Id when the command promise is resolved
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information
  })

Synchronisation des identités

La syncIdentity méthode a été supprimée dans la version 2.1.0, en plus de la fonction de hachage. Si vous utilisez la version 2.1.0+ et souhaitez synchroniser les identités, vous pouvez les envoyer directement dans l' xdm option de la sendEvent commande, sous le identityMap champ.
En outre, la Identity Service permet de synchroniser vos propres identifiants avec l'ECID à l'aide de la syncIdentity commande.
Il est vivement recommandé de transmettre toutes les identités disponibles à chaque sendEvent commande. Cette opération permet de déverrouiller une gamme de cas d’utilisation, y compris la personnalisation. Maintenant que vous pouvez transmettre ces identités dans la sendEvent commande, elles peuvent être placées directement dans votre couche de données.
La synchronisation des identités vous permet d'identifier un périphérique/utilisateur à l'aide de plusieurs identités, de définir leur état d'authentification et de décider quel identifiant est considéré comme Principal. Si aucun identifiant n’a été défini comme primary , la valeur par défaut de l’identifiant Principal est ECID .
alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "ambiguous",
          "primary": true
        }
      ]
    }
  }
})

Options de synchronisation des identités

Symbole d'Espace de nommage d'identité

Type
Obligatoire
Valeur par défaut
Chaîne
Oui
Aucune
La clé de l'objet est le symbole d'Espace de nommage d'identité. Vous trouverez cette liste dans l’interface utilisateur de Adobe Experience Platform sous Identités.

id

Type
Obligatoire
Valeur par défaut
Chaîne
Oui
Aucune
Il s’agit de l’identifiant que vous souhaitez synchroniser pour l’espace de nommage donné.

authenticationState

Type
Obligatoire
Valeur par défaut
Valeurs possibles
Chaîne
Oui
ambigu
ambigu, authentifié et déconnecté
Etat d’authentification de l’ID.

primary

Type
Obligatoire
Valeur par défaut
Booléen
facultatif
false
Détermine si cette identité doit être utilisée comme Principal fragment dans le profil unifié. Par défaut, l’ECID est défini comme identifiant Principal de l’utilisateur.

hashEnabled

Type
Obligatoire
Valeur par défaut
Booléen
facultatif
false
S'il est activé, il hachera l'identité à l'aide du hachage SHA256.