Mit diesen Konfigurationen können verschiedene Instanzen des ID-Dienst-Codes, die in einem iFrame und auf der übergeordneten Seite implementiert sind, miteinander kommunizieren. Sie sollen dabei helfen, Probleme in zwei konkreten Nutzungsszenarios zu lösen, in denen Sie die übergeordnete Seite/Domain verwalten oder auch nicht und bei denen ID-Dienstcode im iFrame einer von Ihnen verwalteten Domain geladen wird. Sie sind in Version 2.2 (oder höher) des VisitorAPI.js-Codes verfügbar.
Inhalt:
Beide Konfigurationselemente sind erforderlich, wenn Sie diesen Code verwenden.
Konfigurationssyntax | Beschreibung |
---|---|
whitelistParentDomain: " Domänenname der übergeordneten Seite " |
Akzeptiert einen einzelnen Domänennamen, der als Zeichenfolge übergeben wird. |
whitelistIframeDomains: [ "iFrame Domain", "iFrame Domain", "iFrame Domain" ] |
Akzeptiert einen oder mehrere iFrame-Domänennamen, die als Array übergeben werden. |
Der konfigurierte ID-Dienstcode sollte in etwa wie im folgenden Beispiel aussehen.
//Instantiate Visitor
var visitor = Visitor.getInstance("Insert Experience Cloud Organization ID here",{
...
//Add parent page domain name and iFrame domain names
whitelistParentDomain: "parentpageA.com",
whitelistIframeDomains: ["iFrameDomain1.com","iFrameDomain2.com"],
...
}
);
Diese Konfigurationen helfen, das Problem zu lösen, ein ID-Dienst-Cookie zu setzen und eine Besucher-ID zuzuweisen, wenn Browser Drittanbieter-Cookies blockieren und eine der folgenden Bedingungen zutrifft:
Sie können diese Konfigurationen auch implementieren, wenn Sie Videos in einem iFrame mit Video Heartbeat bereitstellen. Zur ordnungsgemäßen Funktionsweise benötigt Video Heartbeat eine vom ID-Dienst bereitgestellte ID (die MID).
Nutzungsszenario 1: Der Browser blockiert Drittanbieter-Cookies und der ID-Dienst wird auf der iFrame- und der übergeordneten Seite implementiert
Nutzungsszenario | Beschreibung |
---|---|
Bedingungen |
Dieses Nutzungsszenario schließt die folgenden Bedingungen ein:
|
Ergebnisse |
Unter diesen Bedingungen gilt für den ID-Dienst:
|
Lösung |
Ändern Sie die Funktion Visitor.getInstance des ID-Diensts im iFrame mit diesen Whitelist-Konfigurationen. Geben Sie die übergeordneten und untergeordneten Domänen im Code an. Mit diesen Konfigurationen kann der ID-Dienst-Code im iFrame den ID-Dienst-Code auf der übergeordneten Seite auf eine Besucher-ID überprüfen. Wenn der ID-Dienst-Code im iFrame keine Antwort von der übergeordneten Seite erhält, generieren diese Konfigurationen eine lokale Besucher-ID. |
Nutzungsszenario 2: Anfordern einer ID aus einem iFrame, der in eine übergeordnete Seite eingebettet ist, die Sie nicht steuern und die den ID-Dienst nicht verwendet
Nutzungsszenario | Beschreibung |
---|---|
Bedingungen |
Dieses Nutzungsszenario schließt die folgenden Bedingungen ein:
|
Ergebnisse |
Unter diesen Bedingungen gilt für den ID-Dienst:
|
Lösung |
Ändern Sie die Funktion Visitor.getInstance des ID-Diensts im iFrame mit diesen Whitelist-Konfigurationen. Geben Sie die übergeordneten und untergeordneten Domänen im Code an. Mit diesen Konfigurationen kann der ID-Dienst-Code im iFrame den ID-Dienst-Code auf der übergeordneten Seite auf eine Besucher-ID überprüfen. Wenn der ID-Dienst-Code im iFrame keine Antwort von der übergeordneten Seite erhält, generieren diese Konfigurationen eine lokale Besucher-ID. |
Sie können diese Konfigurationen aus folgenden Gründen sicher implementieren:
Der ID-Dienst unterstützt einen begrenzte Anzahl an öffentlichen API-Methoden, wenn Sie diese Whitelist-Konfigurationen implementieren. Die unterstützten Methoden variieren je nach den oben beschriebenen Nutzungsszenarios.
Anwendungsfall | Unterstützte Methoden |
---|---|
1. Fall |
|
2. Fall |
|