whitelistParentDomain et whitelistIframeDomains whitelistparentdomain-and-whitelistiframedomains
Ces configurations permettent aux différentes instances du code du service d’identification des visiteurs implémentées dans un iFrame et sur la page parente de communiquer entre elles. Ils sont conçus pour aider à résoudre des problèmes avec 2 cas d’utilisation spécifiques où vous pouvez contrôler ou non la page/le domaine parent et où vous avez un chargement de code du service d’identification des visiteurs dans l’iFrame d’un domaine que vous contrôlez. Ils sont disponibles dans la version 2.2 du code VisitorAPI.js ou une version ultérieure.
Contenu :
Syntaxe section-f645198bbaba4fba8961acb6e88d1470
Les deux éléments de configuration sont requis lorsque vous utilisez ce code.
Exemple de code section-09d0049fe88a473baa69d404c50bf8ae
Le Visitor ID Service code que vous avez configuré pourrait ressembler à cet exemple.
//Instantiate Visitor
var visitor = Visitor.getInstance("INSERT-IMS-ORG-ID-HERE",{
...
//Add parent page domain name and iFrame domain names
whitelistParentDomain: "parentpageA.com",
whitelistIframeDomains: ["iFrameDomain1.com","iFrameDomain2.com"],
...
}
);
Cas d’utilisation section-fc2eeb93546b406fae3b102dbcd11de7
Ces configurations permettent de résoudre le problème de définition d’un cookie du service d’identification des visiteurs et d’attribution d’un identifiant visiteur lorsque les navigateurs bloquent les cookies tiers et si l’une de ces conditions s’applique :
- Vous contrôlez ou ne contrôlez pas la page/domaine parent.
- Le code du service d’identification des visiteurs n’est pas installé sur la page parente, mais est implémenté dans un iFrame.
Cas d’utilisation 1 : le navigateur bloque les cookies tiers et le service d’identification des visiteurs est implémenté sur l’iFrame et la page parente
Cet exemple d’utilisation comprend les conditions suivantes :
- L’entreprise A met en œuvre le service d’identification des visiteurs sur sa page d’accueil.
- L’entreprise A met en œuvre le service d’identifiant visiteur dans iFrame sur sa page d’accueil.
- L’entreprise A possède la page parente et l’iFrame et a mis en œuvre le service d’identification des visiteurs aux deux endroits.
- Un client charge la page parente dans un navigateur qui bloque les cookies tiers.
Compte tenu de ces conditions, le service d’identification des visiteurs :
- Fonctionne correctement sur la page parente. Il demande et définit le cookie AMCV et affecte un ID unique au visiteur du site.
- Ne fonctionne pas dans l’iFrame. En effet, le navigateur considère l’iFrame comme un domaine tiers et empêche le service d’identification des visiteurs de définir le cookie AMCV.
Modifiez le service d’identification des visiteurs la fonction Visitor.getInstance dans l’iFrame avec ces configurations de liste autorisée. Spécifiez les domaines parent et enfant dans le code. Ces configurations permettent au code du service d’identification des visiteurs dans l’iFrame de rechercher un identifiant visiteur dans le code du service sur la page parente.
Si le code du service d’identification des visiteurs dans l’iFrame ne reçoit pas de page parente de réponse, ces configurations génèrent un identifiant visiteur local.
Cas d’utilisation 2 : demande d’un identifiant à partir d’un iFrame incorporé dans une page parente que vous ne contrôlez pas ou qui n’utilise pas le service d’identification des visiteurs
Cet exemple d’utilisation comprend les conditions suivantes :
- L’entreprise A n’utilise pas le service d’identification des visiteurs.
- La Société A charge un iFrame sur la page. Cet iFrame appartient à la Société B et est chargé dans un domaine distinct de la Société A.
- Le navigateur bloque les cookies tiers.
Compte tenu de ces conditions, le service d’identification des visiteurs :
- Ne fonctionne pas dans l’iFrame. En effet, le navigateur considère l’iFrame comme un domaine tiers et empêche le service d’identification des visiteurs de définir le cookie AMCV.
- Impossible d’obtenir un ID de visiteur à partir de la page parente, car la Société A n’utilise pas ce service.
Modifiez le service d’identification des visiteurs la fonction Visitor.getInstance dans l’iFrame avec ces configurations de liste autorisée. Spécifiez les domaines parent et enfant dans le code. Ces configurations permettent au code du service d’identification des visiteurs dans l’iFrame de rechercher un identifiant visiteur dans le code du service sur la page parente.
Si le code du service d’identification des visiteurs dans l’iFrame ne reçoit pas de page parente de réponse, ces configurations génèrent un identifiant visiteur local.
Sécurité des configurations section-2b1ce31fab034e1ca0f6b1c3cc57a6e2
Vous pouvez mettre en œuvre ces configurations en toute sécurité car :
- Le service d’identification des visiteurs implémenté sur le domaine parent et le domaine iFrame doivent utiliser le même ID d’organisation IMS. Ces configurations de liste blanche ne fonctionnent pas lorsque les ID d’organisation IMS sur le parent ou dans l’iFrame sont différents.
- Ces configurations communiquent uniquement avec le domaine et les iFrames spécifiés dans le code.
- La communication entre l’iFrame et la page parente suit un format spécifique. Si le service d’identification des visiteurs sur la page parente ne reçoit pas une demande au format attendu, ce processus de partage échoue.
Méthodes API visiteur prises en charge section-30c6a9f4dcdc4265a1149260b97cc057
Le service d’identification des visiteurs prend en charge un ensemble limité de méthodes d’API publiques lorsque vous implémentez ces configurations de liste autorisée. Les méthodes prises en charge varient en fonction des scénarios d’utilisation décrits ci-dessus.
- getMarketingCloudID
- getAudienceManagerLocationHint
- getAudienceManagerBlob
- getSupplementalDataID
- getCustomerIDs
- getSupplementalDataID
- getMarketingCloudVisitorID