Utiliser des identifiants d’appareil propriétaires dans Web SDK

Adobe Experience Platform Web SDK attribue des identifiants Adobe Experience Cloud (ECID) aux visiteurs du site Web à l’aide de cookies pour suivre le comportement des utilisateurs. Pour gérer les restrictions de navigateur relatives à la durée de vie des cookies, vous pouvez définir et gérer vos propres identifiants d’appareil, appelés identifiants d’appareil propriétaires (FPID).

Conditions préalables prerequisites

Avant de commencer, assurez-vous de connaître le fonctionnement des données d’identité dans le SDK web, y compris les ECID et les identityMap. Pour plus d’informations, consultez la présentation des données d’identité dans le SDK Web.

Exigences de formatage des identifiants d’appareils propriétaires formatting-requirements

Edge Network accepte uniquement les identifiants conformes au format UUIDv4. Les identifiants d’appareil qui ne sont pas au format UUIDv4 seront rejetés.

Définition du cookie FPID à l’aide de votre propre serveur set-cookie-server

Lors de la définition d’un cookie sur votre propre serveur , vous pouvez utiliser différentes méthodes pour empêcher que le cookie ne soit restreint en raison de politiques de navigateur :

En outre, vous devez toujours définir le cookie FPID sous l’enregistrement A de votre domaine.

Quand définir le cookie when-to-set-cookie

Le cookie FPID doit idéalement être défini avant d’envoyer toute requête à Edge Network. Cependant, dans les cas où cela n’est pas possible, un ECID est toujours généré à l’aide des méthodes existantes et agit comme identifiant principal tant que le cookie existe.

En supposant que le ECID soit finalement affecté par une politique de suppression de navigateur, mais que le FPID ne l’est pas, le FPID deviendra l’identifiant principal lors de la visite suivante et sera utilisé pour amorcer le ECID à chaque visite suivante.

Définition de l’expiration du cookie set-expiration

La définition de l’expiration d’un cookie doit être prise en compte soigneusement lors de l’implémentation de la fonctionnalité FPID. Lorsque vous prenez cette décision, vous devez tenir compte des pays ou régions dans lesquels votre organisation opère, ainsi que des lois et politiques de chacune de ces régions.

Dans le cadre de cette décision, vous pouvez adopter une politique de configuration des cookies à l’échelle de l’entreprise ou une politique qui varie pour les utilisateurs dans chaque paramètre régional où vous intervenez.

Quel que soit le paramètre que vous choisissez pour l’expiration initiale d’un cookie, vous devez vous assurer d’inclure une logique qui prolonge l’expiration du cookie chaque fois qu’une nouvelle visite du site se produit.

Impact des indicateurs de cookie cookie-flag-impact

Plusieurs indicateurs de cookie affectent la manière dont les cookies sont traités sur différents navigateurs :

HTTPOnly http-only

Les cookies définis avec l’indicateur HTTPOnly ne sont pas accessibles à l’aide de scripts côté client. Cela signifie que si vous définissez un indicateur de HTTPOnly lors de la définition du FPID, vous devez utiliser un langage de script côté serveur pour lire la valeur du cookie à inclure dans le identityMap.

Si vous choisissez qu’Edge Network lise la valeur du cookie FPID, la définition de l’indicateur HTTPOnly garantit que la valeur n’est accessible par aucun script côté client, mais n’aura aucun impact négatif sur la capacité d’Edge Network à lire le cookie.

Secure secure

Les cookies définis avec l’attribut Secure ne sont envoyés au serveur qu’avec une requête chiffrée via le protocole HTTPS. L’utilisation de cet indicateur peut permettre de s’assurer que les personnes malveillantes ne peuvent pas accéder facilement à la valeur du cookie . Dans la mesure du possible, il est toujours préférable de définir l’indicateur de Secure.

SameSite same-site

L’attribut SameSite permet aux serveurs de déterminer si les cookies sont envoyés avec des requêtes intersites. L’attribut fournit une certaine protection contre les attaques multisites par falsification. Trois valeurs sont possibles : Strict, Lax et None. Consultez votre équipe interne pour déterminer le paramètre adapté à votre organisation.

Si aucun attribut SameSite n’est spécifié, le paramètre par défaut de certains navigateurs est désormais SameSite=Lax.

Hiérarchie des identifiants id-hierarchy

En présence d’un ECID et d’un FPID, le ECID a la priorité dans l’identification de l’utilisateur. Cela permet de s’assurer que lorsqu’un ECID existant est présent dans la boutique de cookies de navigateur, il reste l’identifiant principal et que le nombre de visiteurs existant ne risque pas d’être affecté. Pour les utilisateurs existants, le FPID ne deviendra pas l’identité principale tant que le ECID n’aura pas expiré ou n’aura pas été supprimé en raison d’une politique de navigateur ou d’un processus manuel.

Les identités sont hiérarchisées dans l’ordre suivant :

Migration vers des identifiants d’appareil propriétaires migrating-to-fpid

Si vous migrez vers des identifiants d’appareil propriétaires à partir d’une mise en œuvre précédente, il peut être difficile de visualiser à quoi pourrait ressembler la transition à un niveau inférieur.

Pour illustrer ce processus, prenons l’exemple d’un client qui a déjà visité votre site et de l’impact d’une migration FPID sur la manière dont ce client est identifié dans les solutions Adobe.

Utilisation d’identifiants d’appareil propriétaires (FPID) using-fpid

Les identifiants d’appareil propriétaires (FPIDs) effectuent le suivi des visiteurs à l’aide de cookies propriétaires. Les cookies propriétaires sont plus efficaces lorsqu’ils sont définis à l’aide d’un serveur qui utilise un enregistrement DNS A (pour IPv4) ou enregistrement AAAA (pour IPv6), par opposition à un CNAME DNS ou un code JavaScript.

Une fois qu’un cookie FPID est défini, sa valeur peut être récupérée et envoyée à Adobe au fur et à mesure de la collecte des données d’événement. Les FPIDs collectées sont utilisées pour générer des ECIDs, qui sont les identifiants principaux dans les applications Adobe Experience Cloud.

Vous pouvez utiliser FPIDs de deux manières :

Méthode 1 : configurer un CNAME pour vos appels Web SDK et définir un cookie d’ID propriétaire dans votre flux de données setting-cookie-datastreams

Pour définir un cookie FPID à partir de votre propre domaine, vous devez configurer votre propre CNAME (nom canonique) pour vos appels Web SDK, puis activer la fonctionnalité First Party ID Cookie dans la configuration de votre flux de données.

Étape 1. Configurez un CNAME pour votre domaine de déploiement Web SDK

Un enregistrement CNAME dans votre DNS vous permet de créer un alias d’un nom de domaine à un autre. Cela peut aider à faire apparaître les services tiers comme s’ils faisaient partie de votre propre domaine, faisant ainsi ressembler leurs cookies à des cookies propriétaires.

Exemple

Prenons l’exemple suivant : vous souhaitez implémenter Web SDK sur les mywebsite.com de votre site web. Le SDK Web envoie des données à Edge Network vers le domaine edge.adobedc.net.

Lorsque la collecte de données propriétaire est activée à l’aide d’un CNAME, tous les cookies de votre domaine sont envoyés sur les requêtes effectuées au point d’entrée de la collecte de données.

Pour utiliser cette fonctionnalité, vous devez définir le cookie FPID au niveau supérieur de votre domaine au lieu d’un sous-domaine spécifique. Si vous le définissez sur un sous-domaine, la valeur du cookie ne sera pas envoyée à Edge Network et la solution FPID ne fonctionnera pas comme prévu.

Étape 2. Activez la fonctionnalité ​​ Cookie interne d’identifiant ​​ pour votre flux de données

Après avoir configuré votre CNAME, vous devez activer l’option Cookie d’identifiant propriétaire pour votre flux de données. Ce paramètre indique à Edge Network de se référer à un cookie spécifié lors de la recherche d’un identifiant d’appareil interne, au lieu de rechercher cette valeur dans le mappage d’identité.

Consultez la documentation sur la configuration des trains de données pour savoir comment configurer votre train de données.

Consultez la documentation relative aux cookies propriétaires pour plus d’informations sur leur fonctionnement avec Adobe Experience Cloud.

Lors de l’activation de ce paramètre, vous devez indiquer le nom du cookie dans lequel le FPID doit être stocké.

Méthode 2 : utiliser des FPID dans identityMap identityMap

Au lieu de stocker le FPID dans votre propre cookie, vous pouvez envoyer le FPID à Edge Network par le biais du mappage d’identité.

Vous trouverez ci-dessous un exemple de la manière de définir un FPID dans le identityMap :

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

Comme pour les autres types d’identité, vous pouvez inclure le FPID avec d’autres identités dans identityMap. Voici un exemple des FPID inclus avec un CRM ID authentifié :

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

Si le FPID est contenu dans un cookie lu par Edge Network lorsque la collecte de données propriétaire est activée, vous ne devez capturer que les CRM ID authentifiés :

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

L’identityMap suivante entraînerait une réponse d’erreur de la part d’Edge Network, car il lui manque l’indicateur primary pour le FPID. Au moins un des identifiants présents dans identityMap doit être marqué comme primary.

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

Dans ce cas, la réponse d’erreur renvoyée par Edge Network est similaire à ce qui suit :

{
    "type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
    "status": 400,
    "title": "No primary identity set in request (event)",
    "detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
    "report": {
        "requestId": "{REQUEST_ID}",
        "configId": "{CONFIG_ID}",
        "orgId": "{ORG_ID}"
    }
}

FAQ faq

Vous trouverez ci-dessous une liste de réponses aux questions les plus fréquemment posées à propos des identifiants d’appareil propriétaires.

En quoi l’amorçage d’un ID diffère-t-il de la simple génération d’un ID ?

Le concept d’amorçage est unique dans la mesure où le FPID transmis à Adobe Experience Cloud est converti en ECID à l’aide d’un algorithme déterministe. Chaque fois que le même FPID est envoyé à Edge Network, le même ECID est ensemencé à partir du FPID.

Quand l’identifiant d’appareil interne doit-il être généré ?

Pour réduire le gonflement potentiel des visiteurs et visiteuses, le FPID doit être généré avant d’effectuer votre première requête à l’aide du SDK Web. Cependant, si vous ne pouvez pas le faire, une ECID sera toujours générée pour cet utilisateur et sera utilisée comme identifiant principal. Le FPID qui a été généré ne deviendra pas l’identifiant principal tant que le ECID n’est pas présent.

Quelles méthodes de collecte de données prennent en charge les identifiants d’appareils propriétaires ?

Actuellement, seul Web SDK prend en charge les identifiants d’appareil propriétaires.

Les identifiants d’appareils propriétaires sont-ils stockés sur des solutions Platform ou Experience Cloud ?

Une fois que le FPID a été utilisé pour amorcer un ECID, il est supprimé du identityMap et remplacé par le ECID qui a été généré. Le FPID n’est stocké dans aucune solution Adobe Experience Platform ou Experience Cloud.