Identifiants d’appareil propriétaires dans le SDK Web
Le SDK Web de Adobe Experience Platform affecte des Adobe Experience Cloud IDs (ECID) aux visiteurs du site Web à l’aide de cookies afin d’effectuer le suivi du comportement des utilisateurs. Pour tenir compte des restrictions du navigateur sur la durée de vie des cookies, vous pouvez choisir de définir et de gérer vos propres identifiants d’appareil à la place. Ils sont appelés identifiants d’appareil propriétaires (FPIDs
).
Vous pouvez utiliser des identifiants d’appareil propriétaires ou des cookies tiers, mais vous ne pouvez pas utiliser les deux fonctionnalités simultanément.
Ce document explique comment configurer des identifiants d’appareil propriétaires pour votre mise en oeuvre de SDK Web.
Conditions préalables
Ce guide suppose que vous connaissez le fonctionnement des données d’identité pour le SDK Web Platform, y compris le rôle des ECID et identityMap
. Pour plus d’informations, consultez la présentation de données d’identité dans le SDK Web .
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 A DNS (pour IPv4) ou un enregistrement AAAA (pour IPv6), par opposition à un code DNS CNAME ou JavaScript.
Une fois qu’un cookie FPID est défini, sa valeur peut être récupérée et envoyée à l’Adobe lorsque les données d’événement sont collectées. Les FPIDs collectés sont utilisés comme graines pour générer ECIDs, qui restent les identifiants principaux dans les applications Adobe Experience Cloud.
Pour envoyer un FPID pour un visiteur de site web à l’Edge Network, vous devez inclure le FPID dans le identityMap
de ce visiteur. Pour plus d’informations, reportez-vous à la section plus bas de ce document sur à l’aide de FPID dans identityMap
.
Exigences de mise en forme des identifiants de périphérique propriétaires formatting-requirements
L’Edge Network accepte uniquement les IDs conformes au format UUIDv4. Les identifiants d’appareil qui ne sont pas au format UUIDv4 seront rejetés.
La génération d’un UUID va presque toujours générer un identifiant unique et aléatoire, avec une probabilité de collision négligeable. UUIDv4 ne peut pas être envoyé à l’aide d’adresses IP ou d’autres informations d’identification personnelles (PII). UUIDs sont omniprésents et des bibliothèques sont disponibles pour pratiquement tous les langages de programmation pour les générer.
Définition d’un cookie d’identifiant propriétaire dans l’interface utilisateur des flux de données setting-cookie-datastreams
Vous pouvez spécifier un nom de cookie dans l’interface utilisateur des flux de données, où FPID peut résider, plutôt que d’avoir à lire la valeur du cookie et à inclure le FPID dans la carte d’identité.
Pour plus d’informations sur la configuration d’un flux de données, consultez la documentation sur les jeux de données .
Lors de la configuration de votre flux de données, activez l’option Cookie d’identifiant propriétaire . Ce paramètre indique à l’Edge Network de se référer à un cookie spécifié lors de la recherche d’un identifiant d’appareil propriétaire, plutôt que de rechercher cette valeur dans la carte d’identité.
Consultez la documentation sur les cookies propriétaires pour plus d’informations sur leur utilisation avec Adobe Experience Cloud.
Lorsque vous activez ce paramètre, vous devez indiquer le nom du cookie dans lequel l’ID doit être stocké.
Lorsque vous utilisez des identifiants propriétaires, vous ne pouvez pas effectuer de synchronisation d’identifiants tiers. Les synchronisations des identifiants tiers dépendent du service Visitor ID et du UUID
généré par ce service. Lors de l’utilisation de la fonctionnalité d’identifiant propriétaire, ECID est généré sans l’utilisation du service Visitor ID, ce qui rend impossible la synchronisation d’identifiants tiers.
Lorsque vous utilisez des identifiants propriétaires, les fonctionnalités Audience Manager ciblées pour l’activation dans les plateformes partenaires ne sont pas prises en charge, étant donné que les synchronisations des identifiants partenaires d’Audience Manager sont principalement basées sur UUIDs
ou DIDs
. Le ECID dérivé d’un identifiant propriétaire n’est pas lié à un UUID
, ce qui le rend inadressable.
Définition d’un cookie à l’aide de votre propre serveur set-cookie-server
Lorsque vous définissez un cookie à l’aide d’un serveur que vous détenez, vous pouvez utiliser différentes méthodes pour empêcher que le cookie ne soit limité en raison des stratégies de navigateur :
- Génération de cookies à l’aide de langages de script côté serveur
- Définir des cookies en réponse à une requête d’API envoyée à un sous-domaine ou à un autre point de terminaison du site
- Générer des cookies à l’aide d’un CMS
- Générer des cookies à l’aide d’un CDN
document.cookie
de JavaScript ne seront presque jamais protégés des stratégies de navigateur qui limitent les durées des cookies.Quand définir le cookie when-to-set-cookie
Le cookie FPID doit idéalement être défini avant d’adresser toute requête à l’Edge Network. Cependant, dans les scénarios où cela n’est pas possible, un ECID est toujours généré à l’aide de méthodes existantes et agit comme identifiant principal tant que le cookie existe.
En supposant que ECID soit finalement affecté par une stratégie de suppression du navigateur, mais que FPID ne l’soit pas, FPID deviendra l’identifiant principal lors de la prochaine visite et sera utilisé pour amorcer le ECID à chaque visite ultérieure.
Définition de l’expiration du cookie set-expiration
La définition de l’expiration d’un cookie doit être soigneusement étudiée lorsque vous implémentez la fonctionnalité FPID. Lorsque vous décidez de cela, vous devez tenir compte des pays ou des régions dans lesquels votre organisation opère, ainsi que des lois et politiques dans chacune de ces régions.
Dans le cadre de cette décision, vous souhaiterez peut-être adopter une stratégie de définition des cookies à l’échelle de l’entreprise ou une stratégie qui varie selon les utilisateurs dans chaque région où vous opérez.
Quel que soit le paramètre choisi 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 sur le site se produit.
Impact des indicateurs de cookie cookie-flag-impact
Différents indicateurs de cookie affectent le traitement des cookies dans différents navigateurs :
HTTPOnly
http-only
Les cookies définis à l’aide de l’indicateur HTTPOnly
ne sont pas accessibles à l’aide de scripts côté client. Cela signifie que si vous définissez un indicateur HTTPOnly
lors de la définition de FPID, vous devez utiliser un langage de script côté serveur pour lire la valeur du cookie à inclure dans identityMap
.
Si vous choisissez que l’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é de l’Edge Network à lire le cookie.
HTTPOnly
n’a aucun impact sur les stratégies de cookies qui peuvent restreindre la durée de vie des cookies. Cependant, il reste quelque chose à prendre en compte lorsque vous définissez et lisez la valeur de FPID.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 permet de s’assurer que les attaquants du milieu ne peuvent pas facilement accéder à la valeur du cookie. Lorsque cela est possible, il est toujours préférable de définir l’indicateur Secure
.
SameSite
same-site
L’attribut SameSite
permet aux serveurs de déterminer si des cookies sont envoyés avec des requêtes intersites. L’attribut offre une certaine protection contre les attaques par falsification intersites. Il existe trois valeurs possibles : Strict
, Lax
et None
. Consultez votre équipe interne pour déterminer quel paramètre convient à votre entreprise.
Si aucun attribut SameSite
n’est spécifié, le paramètre par défaut de certains navigateurs est désormais SameSite=Lax
.
Utilisation des FPID dans identityMap
identityMap
Vous trouverez ci-dessous un exemple de la manière dont vous définiriez 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 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 en cours de lecture par l’Edge Network lorsque la collecte de données propriétaires est activée, vous devez capturer uniquement les CRM ID authentifiés :
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
Les identityMap
suivants provoqueraient une réponse d’erreur de l’Edge Network, car l’indicateur primary
est manquant pour l’élément 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 l’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}"
}
}
Définition d’un FPID sur votre propre domaine setting-fpid-domain
Outre la définition de FPID dans la carte des identités, vous pouvez définir le cookie FPID sur votre propre domaine, si une collecte de données propriétaires CNAME est configurée.
Lorsque la collecte de données propriétaires est activée à l’aide d’un CNAME, tous les cookies de votre domaine sont envoyés sur les demandes effectuées au point de terminaison de la collecte de données.
Tous les cookies non pertinents aux fins de collecte de données d’Adobe sont ignorés. Pour FPID, vous pouvez spécifier le nom du cookie FPID dans la configuration du flux de données. Lorsque vous procédez de la sorte, l’Edge Network lit le contenu du cookie FPID au lieu de rechercher le FPID dans la carte d’identité.
Pour utiliser cette fonctionnalité, vous devez définir le FPID au niveau supérieur de votre domaine au lieu d’un sous-domaine spécifique. Si vous la définissez sur un sous-domaine, la valeur du cookie ne sera pas envoyée à l’Edge Network et la solution FPID ne fonctionnera pas comme prévu.
Hiérarchie des identifiants id-hierarchy
En présence d’un ECID et d’un FPID, la priorité ECID est donnée à l’identification de l’utilisateur. Ainsi, lorsqu’un ECID existant est présent dans le magasin de cookies du navigateur, il reste l’identifiant principal et le nombre de visiteurs existants ne risque pas d’être affecté. Pour les utilisateurs existants, FPID ne deviendra l’identité principale que lorsque ECID expirera ou sera supprimé en raison d’une stratégie de navigateur ou d’un processus manuel.
Les identités sont classées par priorité dans l’ordre suivant :
- ECID inclus dans le
identityMap
- ECID stocké dans un cookie
- FPID inclus dans le
identityMap
- FPID stocké dans un cookie
Migration vers des identifiants d’appareil propriétaires migrating-to-fpid
Si vous effectuez une migration vers des identifiants d’appareil propriétaires à partir d’une mise en oeuvre précédente, il peut s’avérer difficile de visualiser à quoi pourrait ressembler la transition à un faible niveau.
Pour illustrer ce processus, imaginez un scénario impliquant un client qui a déjà visité votre site et quel impact une migration FPID aurait sur la manière dont ce client est identifié dans les solutions Adobe.
ECID
est toujours prioritaire par rapport à FPID
.FAQ faq
Vous trouverez ci-dessous une liste de réponses aux questions fréquentes sur les identifiants d’appareils propriétaires.
En quoi l’envoi d’un identifiant diffère-t-il de la simple génération d’un identifiant ?
Le concept d’ensemencement 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é à l'Edge Network, le même ECID est envoyé à partir du FPID.
Quand l’identifiant d’appareil propriétaire doit-il être généré ?
Pour réduire l’inflation potentielle des visiteurs, FPID doit être généré avant d’effectuer votre première requête à l’aide du SDK Web. Cependant, si vous ne parvenez pas à le faire, un ECID sera toujours généré pour cet utilisateur et sera utilisé comme identifiant principal. Le FPID généré ne deviendra pas l’identifiant principal tant que ECID n’est pas présent.
Quelles méthodes de collecte de données prennent en charge les identifiants d’appareil propriétaires ?
Actuellement, seul le SDK Web prend en charge les identifiants d’appareil propriétaires.
Les identifiants d’appareil propriétaires sont-ils stockés sur une plateforme ou une solution Experience Cloud ?
Une fois que FPID a été utilisé pour amorcer un ECID, il est déposé à partir de identityMap
et remplacé par le ECID généré. FPID n’est stocké dans aucune solution Adobe Experience Platform ou Experience Cloud.