Zum Hauptinhalt springen
Benutzerdefinierte Daten sind eine der leistungsstärksten Funktionen in Kameleoon. Benutzerdefinierte Daten ermöglichen es, jeden Datentyp mit jedem Besucher zu verknüpfen, und werden für zwei Zwecke verwendet:
  1. Zur Generierung von Zielgruppensegmenten basierend auf Besucherdaten, einschließlich der Erstellung erweiterter Segmente für Experimente und Personalisierungen. Beispiele für benutzerdefinierte Daten sind Alter, frühere Käufe, aktueller Warenkorbbetrag und Lieblingskategorie. In der Regel sind benutzerdefinierte Daten eng mit den Besonderheiten eines Geschäfts verbunden. Wenn Sie zum Beispiel eine Marketplace-Website betreiben, können Sie benutzerdefinierte Daten erstellen, die angeben, ob ein Besucher hauptsächlich ein “Käufer” oder ein “Verkäufer” ist.
  2. Zur Bereitstellung erweiterter Analyseberichte durch die Aufschlüsselung von Ergebnissen nach benutzerdefinierten Daten sowie zum Filtern von Experiment- und Personalisierungsberichten mithilfe beliebiger gespeicherter Datenwerte.
Benutzerdefinierte Daten können von folgenden Typen sein: Single, List oder Counted List mit einem Zeichenketten-, Boolean- oder Zahlenformat und dem Geltungsbereich Seite, Besuch oder Besucher. Dieser Artikel dient als allgemeiner Leitfaden, um mehr über benutzerdefinierte Daten und deren effektive Nutzung zu erfahren. Wenn Sie an der Erstellung benutzerdefinierter Daten innerhalb der Kameleoon-Plattform interessiert sind, können Sie im folgenden Benutzerhandbuch nachschlagen.

​
Technischer Überblick

Sobald ein benutzerdefinierter Datenwert festgelegt ist, wird er lokal auf dem Server oder auf dem Gerät des Nutzers gespeichert, je nachdem, ob ein serverseitiges SDK oder ein clientseitiges SDK verwendet wird, einschließlich der Anwendungsdatei (engine.js), anstatt ihn von einem Remote-Kameleoon-Server abzurufen. Diese Speicherung bedeutet, dass Daten bei nachfolgenden Seitenaufrufen desselben Besuchs oder bei zukünftigen Besuchen abgerufen werden können. Wenn Kameleoon geladen wird, stehen alle geschriebenen benutzerdefinierten Daten automatisch für die spätere Verwendung zur Verfügung, entweder über die Activation API oder die SDKs.
Wenn Kameleoon Web Experimentation verwendet wird, ist die LocalStorage-Implementierung vereinheitlicht, was bedeutet, dass Benutzerreisen, die mehrere Subdomains umfassen, automatisch von Kameleoon verwaltet werden, sofern die Implementierungsrichtlinien für vereinheitlichte Sitzungsdaten über Subdomains hinweg befolgt werden. Kameleoon speichert und lädt auch benutzerdefinierte Daten und behandelt komplexe Probleme, wie z. B. den gleichzeitigen Zugriff von mehreren Tabs auf derselben Website.
Jeder für benutzerdefinierte Daten festgelegte Wert kann auch im Rahmen des Standard-Tracking-Prozesses an die Kameleoon-Datenerfassungsserver gesendet werden, was drei Zwecken dient:
  1. Die Daten stehen für Reporting-Zwecke zur Verfügung und können verwendet werden, um Besuchs- oder Besucherdaten nach bestimmten Attributen zu filtern oder aufzuschlüsseln (z. B. Anzahl der Besuche oder Besucher pro Profiltyp) oder um Daten zu analysieren (z. B. Konversionen nach Zahlungsart). Das Verknüpfen benutzerdefinierter Daten mit einem Ziel als Metadaten ist erforderlich, um Konversionsdaten basierend auf dem Metadatenwert zu filtern oder aufzuschlüsseln.
Wenn benutzerdefinierte Daten als Ziel-Metadaten festgelegt werden, verwendet Kameleoon automatisch den zuletzt verfolgten Wert der benutzerdefinierten Daten im Reporting für jede Zielkonversion. Sie können den Wert der benutzerdefinierten Daten manuell festlegen, indem Sie den Parameter metadata der Methode processConversion der Activation API oder die Methode trackConversion des SDK verwenden.
  1. Die Daten können als Eingabe für Machine-Learning-Algorithmen für KI-Predictive Targeting und Contextual-Bandit-Experimente verwendet werden.
  2. Die Daten werden auf Backend-Servern gespeichert und können über die Data API abgerufen werden.
Die neueste Version (2.3) der Intelligent Tracking Prevention (ITP)-Beschränkungen in Safari-Browsern löscht den LocalStorage nach sieben Tagen, was bedeutet, dass bei einem wiederkehrenden Besucher, der nach sieben Tagen zurückkehrt, zusätzliche Synchronisations-Serveranfragen zum Abrufen des Inhalts benutzerdefinierter Daten in Safari nicht vermieden werden können. Kameleoon optimiert diese Anfragen jedoch und führt sie nur bei Bedarf durch (z. B. wenn der Siebentageszeitraum verstrichen ist). Weitere Informationen zur Lösung finden Sie im Artikel ITP-Management.

​
Grundlegende technische Konzepte: Geltungsbereich benutzerdefinierter Daten

Der Geltungsbereich benutzerdefinierter Daten ist entscheidend, da er bestimmt, wie sich der Wert beim Targeting verhält und wie er im Reporting gespeichert und angezeigt wird. Die Konfiguration benutzerdefinierter Daten hängt von Ihrem Implementierungstyp ab: Web Experimentation oder Feature Experimentation (SDKs) – und davon, wie und wann Sie die benutzerdefinierten Daten verwenden möchten.

​
Geltungsbereich für das Targeting

Wie sich benutzerdefinierte Daten beim Targeting verhalten, unterscheidet sich erheblich zwischen Web Experimentation und Feature Experimentation.

​
Web Experimentation (engine.js)

Bei Web Experimentation wird das Targeting typischerweise einmal auf der Seite basierend auf dem Wert der benutzerdefinierten Daten ausgewertet. Es wird nicht erneut ausgewertet, wenn sich der Wert der benutzerdefinierten Daten auf derselben Seite ändert. Der Geltungsbereich der benutzerdefinierten Daten bestimmt deren Lebensdauer für das Targeting:
  • Seite: Der Wert der benutzerdefinierten Daten wird nach jedem Seitenaufruf zurückgesetzt.
    • Anwendungsfall: Nutzer ansprechen, die einen bestimmten Seitentyp durchsuchen (oder sich auf einem solchen befinden) (z. B. Produktseiten).
  • Besuch: Der Wert der benutzerdefinierten Daten wird nach jedem Besuch zurückgesetzt. Die benutzerdefinierten Daten behalten ihren letzten Wert, wenn ein Nutzer innerhalb desselben Besuchs von Seite zu Seite navigiert.
    • Anwendungsfall: Einen Besucher ansprechen, der sich während seines aktuellen Besuchs für einen Newsletter angemeldet hat.
  • Besucher: Der Wert der benutzerdefinierten Daten wird nicht zurückgesetzt. Er behält seinen letzten Wert über mehrere Besuche desselben Besuchers hinweg.
    • Anwendungsfall: Einen Besucher ansprechen, der in der Vergangenheit dreimal Käufe auf der Website getätigt hat.
Wenn das Risiko besteht, dass ein Wert benutzerdefinierter Daten nach der Initialisierung von Kameleoon und der zugehörigen ersten Targeting-Ausführung erhalten werden könnte, setzen Sie den Geltungsbereich auf PAGE. Wenn der Geltungsbereich nicht auf PAGE gesetzt ist, kann der aktuelle Wert der benutzerdefinierten Daten “zu spät” sein und Targeting-Probleme verursachen, insbesondere bei der Durchführung eines Experiments, das Besucher ansprechen soll, die nach dem Durchsuchen einer Kategorieseite zu einer Produktseite wechseln und nach nur wenigen Sekunden einen neuen Wert erhalten. Mit einem Geltungsbereich PAGE tritt dieses Problem nicht auf.

​
Feature Experimentation (SDKs)

Mit SDKs für Feature Experimentation gibt es kein Konzept einer “Seite” in Bezug auf den Geltungsbereich. Werte benutzerdefinierter Daten werden explizit zum Zeitpunkt der Auswertung übergeben. Hier definiert der Geltungsbereich in erster Linie, wie die benutzerdefinierten Daten auf den Servern von Kameleoon gespeichert werden und welcher Wert automatisch abgerufen wird (z. B. mithilfe von getRemoteVisitorData()). Standardmäßig ruft die API nur Werte mit dem Geltungsbereich VISITOR ab. Diese Werte werden dem Besucher zugeordnet und während der Auswertung verwendet.

​
Reporting und Anzeige benutzerdefinierter Daten

Wie benutzerdefinierte Daten in Ihren Berichten angezeigt werden, hängt auch von Ihrem Experimentationstyp, dem Typ und Geltungsbereich der benutzerdefinierten Daten und davon ab, ob der optionale Parameter overwrite mit setCustomData() verwendet wurde.

​
Standardlogik (wenn der overwrite-Parameter false oder weggelassen ist)

Für Web Experimentation (Ergebnisseite)
Auf der Ergebnisseite für Web Experimentation können alle Typen benutzerdefinierter Daten mehrere Werte auf derselben Seite und während desselben Besuchs haben. Die folgenden Regeln gelten für die Anzeige dieser Werte:
  • Typ Single & Geltungsbereich Seite: Alle während eines Besuchs festgelegten Werte werden auf der Ergebnisseite angezeigt, um Besuche aufzuschlüsseln. Wenn ein Wert einmal oder mehrmals festgelegt wird, ergibt dies dieselbe Anzeige (z. B. wird der Besuch mit diesem Wert markiert).
    • Anwendungsfall: Besuche nach den Kategorien der angezeigten Seiten aufschlüsseln.
  • Typ Single & Geltungsbereich Besuch: Die Ergebnisseite zeigt nur den letzten Wert an, der während des Besuchs festgelegt wurde, um Besuche aufzuschlüsseln.
    • Anwendungsfall: Besuche nach Art der Benutzermitgliedschaft aufschlüsseln.
  • Typ Single & Geltungsbereich Besucher: Wenn Sie die Besucheransicht auf der Ergebnisseite verwenden und nach benutzerdefinierten Daten aufschlüsseln, zeigt Kameleoon alle Werte an, die für diese benutzerdefinierten Daten für den Besucher empfangen wurden, was alle früheren Besuche abdeckt, die dem Experiment ausgesetzt oder von ihm beeinflusst wurden, innerhalb des ausgewählten Zeitrahmens.
    • Anwendungsfall: Besucher nach der Anzahl der Käufe aufschlüsseln, die sie über alle Besuche hinweg auf der Website getätigt haben.
  • Alle Kombinationen für Typen/Geltungsbereiche (list, countList/page, visit, visitor): Alle während des Besuchs zugewiesenen Werte werden auf der Ergebnisseite für eine detaillierte Aufschlüsselung der Besuche angezeigt. Wenn einem Besuch ein Wert zugewiesen wird, sei es einmal oder wiederholt, wird er konsistent angezeigt und kennzeichnet den Besuch mit diesem Wert.
    • Anwendungsfall: Besuche nach allen Newslettern aufschlüsseln, für die sich ein Nutzer angemeldet hat, den angeklickten Navigationsmenü-Links oder den auf einer Kategorieseite ausgewählten Filtern.
Für Feature Experimentation (SDKs)
Bei Feature Experimentation funktioniert das Reporting benutzerdefinierter Daten aufgrund der Natur der SDK-Umgebungen, die typischerweise kein “Seiten”-Konzept wie Webbrowser haben, anders.
  • Der Geltungsbereich Seite gilt nicht für Reporting-Zwecke bei Feature Experimentation, da SDKs häufig in serverseitigen oder mobilen Umgebungen laufen, in denen ein eindeutiges “Seitenladen”-Ereignis, das eine Datenrücksetzung auslösen würde, von Natur aus nicht existiert.
  • Für alle benutzerdefinierten Daten behält und meldet Kameleoon nur den letzten Wert, der während eines Besuchs empfangen wurde. Dieser Ansatz ist effizient und relevant für Umgebungen, in denen der jüngste Zustand der Attribute eines Nutzers innerhalb einer kontinuierlichen Sitzung im Allgemeinen das ist, was für Funktionsentscheidungen wichtig ist.
  • Die Geltungsbereiche Besuch und Besucher verhalten sich beim Reporting wie erwartet und ermöglichen Aufschlüsselungen nach dem letzten Wert innerhalb eines Besuchs bzw. über mehrere Besuche eines Besuchers hinweg.

​
Überschreiben des Standardverhaltens mit dem overwrite-Parameter

Mit dem Parameter overwrite (optional boolean) der Methode setCustomData() können Sie explizit steuern, wie Werte benutzerdefinierter Daten gespeichert werden und folglich, wie sie in Berichten angezeigt werden.
  • Wenn overwrite true ist: Der neue Wert, der an setCustomData() übergeben wird, ersetzt immer alle vorhandenen Werte für diesen Schlüssel benutzerdefinierter Daten innerhalb der aktuellen Sitzung/des aktuellen Besuchs, unabhängig von seinem Typ (Single, List, Count List) oder Geltungsbereich (Page, Visit, Visitor), was bedeutet, dass nur der zuletzt gesetzte Wert für Targeting und Reporting verfügbar ist.
  • Wenn overwrite false ist oder weggelassen wird: Es gilt die in den obigen Abschnitten beschriebene Standardlogik.
Sie können benutzerdefinierte Daten als Metadaten beim Einrichten eines Ziels verwenden, sodass der Wert der benutzerdefinierten Daten zu Reporting- und Analysezwecken an jede Konversion angehängt werden kann. Weitere Informationen zur Erstellung eines Ziels finden Sie im Artikel Ein neues Ziel erstellen.Standardmäßig sind benutzerdefinierte Daten Attribute, die sich auf Nutzer beziehen; wenn Sie jedoch benutzerdefinierte Daten als Eigenschaften einer Konversion verwenden möchten, können Sie Metadaten nutzen.

​
Abrufmethoden

Kameleoon bietet verschiedene Integrationen out of the box, die im Folgenden beschrieben werden.

​
Datenschichten

Diese Methoden rufen den Wert der benutzerdefinierten Daten aus einer angegebenen Variablen in der Datenschicht für Google Tag Manager, Tealium oder Commander’s Act ab. Geben Sie den Namen der Variablen in der Datenschicht an, und Kameleoon vervollständigt die Integration automatisch, sobald die Datenschicht auf der Seite geladen wird.
Kameleoon unterstützt mehrere Hierarchieebenen und Array-Variablen in der Datenschicht. Sie können beispielsweise einen Wert aus product.category.name, cart["amount"] oder purchases[3] abrufen.
Kameleoon kann den Wert der benutzerdefinierten Daten erst festlegen, nachdem die Datenschicht auf Ihrer Seite verfügbar ist, was mehrere Sekunden dauern kann (abhängig davon, wann Sie Ihren Tag-Manager laden). Wenn Sie die benutzerdefinierten Daten als Targeting-Bedingung in einem A/B-Test verwenden, kann ein spürbarer Flicker-Effekt auftreten.

​
Activation API

Verwenden Sie die Activation API, um Werte benutzerdefinierter Daten im Browser (clientseitige Umgebung) festzulegen. Suchen Sie ein bestimmtes DOM-Element auf der Seite und verwenden Sie dessen Inhalt als Wert der benutzerdefinierten Daten. Rufen Sie beispielsweise den aktuellen Warenkorbbetrag ab, wenn er auf der Webseite angezeigt wird, und füllen Sie die entsprechenden benutzerdefinierten Daten entsprechend aus.
Die Methode setCustomData() der Activation API enthält einen Parameter namens overwriteIfCollection. Weitere Details zu dieser Methode finden Sie in der Dokumentation der Activation API.
Die Methode Kameleoon.API.Data.setCustomData() überschreibt immer vorherige vorhandene Werte für die benutzerdefinierten Daten, außer wenn der Typ List oder Counted List ist und das dritte Argument false lautet; in diesem Fall fügt sie der vorhandenen Liste etwas hinzu.

​
Benutzerdefinierter JavaScript-Code

Mit dieser Option können Sie ad-hoc benutzerdefinierten JavaScript-Code schreiben. Die wichtigste Regel beim Festlegen benutzerdefinierter Daten lautet, dass Ihr Code ein Objekt mit zwei Schlüsseln zurückgeben sollte: value mit dem Wert, den Sie für diese benutzerdefinierten Daten bereitstellen möchten, und (optional) override mit einem booleschen Wert (standardmäßig false). Wenn noch kein Wert verfügbar ist, aber später auf der Seite ermittelt wird, geben Sie keinen Wert zurück (das Zurückgeben von null oder undefined ist ebenfalls akzeptabel). Das System führt den Code erneut aus (alle 100 ms für die ersten drei Sekunden nach dem ersten Aufruf, danach alle drei Sekunden). Per Konvention setzt die Rückgabe von {"value": null} die benutzerdefinierten Daten nicht, stoppt aber die regelmäßige Ausführung. Die erste Ausführung erfolgt, bevor das Targeting-System von Kameleoon ausgelöst wird, und bietet die Möglichkeit, benutzerdefinierte Daten einzurichten, bevor das Targeting ausgeführt wird.
Vermeiden Sie diese Abrufmethode nach Möglichkeit. Schreiben Sie JavaScript-Code an einem anderen Ort, z. B. im Tag-Manager, in einer externen Skriptdatei oder als Inline-Skript-Code im HTML-Code, und verwenden Sie dann die Abrufmethode der Activation API, um die benutzerdefinierten Daten festzulegen.

​
SDK-Methode

Für Feature Experimentation (SDKs) werden Werte benutzerdefinierter Daten ausschließlich über SDK-Methoden erfasst und an Kameleoon gesendet, was bedeutet, dass sie explizit über die SDK-Integration übergeben werden (z. B. mithilfe von Methoden wie addData() oder setCustomData(), je nach spezifischem SDK). Weitere Details zur Verwendung benutzerdefinierter Daten in SDKs finden Sie im Artikel Nutzung des Besuchsverlaufs.

​
Data API / Server-zu-Server-Integration

Wenn Sie eine Server-zu-Server-Integration einrichten möchten, ist die Data API der empfohlene Ansatz. Die Verwendung der Data API beinhaltet die Implementierung eines REST-Aufrufs an die Kameleoon-Server, wobei der Name und Wert der benutzerdefinierten Daten sowie der visitorCode angegeben werden.

​
Erweiterte Optionen

​
Diese Daten nur lokal für Targeting-Zwecke verwenden

Die Aktivierung dieser Option ermöglicht es, den Wert der benutzerdefinierten Daten lokal auf dem Gerät des Nutzers oder auf dem Server zu speichern, wenn eines der serverseitigen SDKs verwendet wird. Da diese Daten nicht auf Kameleoon-Servern gespeichert werden, können sie nicht für Analysen im Reporting verwendet werden. Diese Funktion kann aus Datenschutz- oder rechtlichen Gründen von Vorteil sein. Einige Kunden verlangen möglicherweise, dass sensible Daten nicht außerhalb ihrer Systeme gespeichert werden, möchten aber dennoch das Besuchererlebnis basierend auf diesen Daten personalisieren.

​
Diese benutzerdefinierten Daten als Eingabe für KI-Predictive Targeting verwenden

Die Aktivierung dieser Option ermöglicht es Machine-Learning-Algorithmen, diese benutzerdefinierten Daten als Eingabe zu verwenden. Diese Funktion ist nur mit einem Abonnement des KI-Predictive-Targeting-Zusatzmoduls verfügbar.

​
Diese benutzerdefinierten Daten als eindeutigen Identifikator für die geräteübergreifende Verlaufsabgleichung verwenden

Bei Aktivierung behandelt Kameleoon diese benutzerdefinierten Daten als eindeutigen Identifikator für Ihre Besucher, der verwendet wird, um mehrere Kameleoon-Besuche einem eindeutigen Nutzer für geräteübergreifende Experimente zuzuordnen. Erfahren Sie mehr über diese Funktion im Artikel Geräteübergreifende Experimente.

​
Verwendung benutzerdefinierter Daten

​
Targeting-Bedingung für Segmente

Der Kameleoon-Segment-Builder fügt automatisch Targeting-Bedingungen für alle von Ihnen definierten benutzerdefinierten Daten hinzu. Der Prozess ist automatisch, und wenn der Wert der benutzerdefinierten Daten Ihrer Bedingung entspricht, wird dieser bestimmte Besucher in das Segment aufgenommen.

​
Über die Activation API

Sie können den aktuellen Wert benutzerdefinierter Daten über Kameleoon.API.CurrentVisit.customData (Geltungsbereiche PAGE oder VISIT) oder Kameleoon.API.Visitor.customData (Geltungsbereich VISITOR) abrufen.

​
Über die SDKs

Die Methode getRemoteVisitorData() ruft alle benutzerdefinierten Daten ab, die während des vorherigen Besuchs des aktuellen Besuchers erfasst wurden. Weitere Details finden Sie im Artikel Nutzung des Besuchsverlaufs.

​
Analytische Zwecke

Alle benutzerdefinierten Daten (außer denen, die als nur lokal markiert sind) können als Filter oder als Aufschlüsselungsoption auf den Ergebnisseiten von Experimenten oder Personalisierungen verwendet werden. Diese Informationen sind auch in den vom Rohdaten-Exporttool erstellten Berichten verfügbar, und es können komplexe Abfragen einschließlich benutzerdefinierter Daten durchgeführt werden (mit einem dedizierten Kameleoon-Datencluster). Für eine Aufschlüsselung mit benutzerdefinierten Daten vom Typ String enthalten die Ergebnisse bis zu 50 der am häufigsten verwendeten Werte für diese Daten. Für eine Aufschlüsselung mit benutzerdefinierten Daten vom Typ Number werden die Ergebnisse ebenfalls mit maximal 50 möglichen Werten aufgeschlüsselt. Bei numerischen benutzerdefinierten Daten ist diese Grenze nicht immer sinnvoll. Wenn benutzerdefinierte Daten als Metadaten mit einem Ziel verknüpft sind, sind die Werte derzeit nur über einen Rohdatenexport zugänglich. Ein Update der Reporting-Seite – voraussichtlich später im 2. Quartal – wird die Verwendung von Metadaten als Filter direkt in den Ergebnissen ermöglichen.

​
Erweiterte Einstellungen

​
Eine benutzerdefinierte Auswahlboxkomponente für die mit diesen benutzerdefinierten Daten verbundene Targeting-Bedingung implementieren

Diese Funktion vereinfacht die Auswahl von Werten benutzerdefinierter Daten in Targeting-Bedingungen, indem sie in einer Auswahlbox statt in einem einfachen Textfeld dargestellt werden, was es Endbenutzern viel einfacher macht, den geeigneten Wert für das Targeting auszuwählen. Es sind zwei wichtige Punkte zu beachten:
  • Rohwerte können mit beschreibenden Labels verknüpft werden.
  • Die Labels und Werte werden dynamisch abgerufen, wenn die Targeting-Bedingungs-Oberfläche angezeigt wird.
Diese Funktion ist besonders nützlich für die Integration mit Drittanbieter-Datenquellen wie DMPs oder CRMs. Wenn die benutzerdefinierten Daten beispielsweise ein externes Segment aus einer DMP darstellen, kann der Nutzer “Treue Kunden” anstelle der internen ID auswählen, die in der Regel eine komplexe Zeichenfolge wie “8ney4225y65a” ist. Die Liste der in der DMP definierten Segmente ist auf der Kameleoon-Oberfläche immer aktuell, sodass diese Funktion die Synchronisierung automatisch handhabt.
Die mit benutzerdefinierten Daten verknüpften Labels sind nur für Nutzer sichtbar, die Zugriff auf die Kameleoon-Plattform haben. Sie sind nicht in der JavaScript-Anwendungsdatei enthalten, sodass Website-Besucher sie nicht sehen können. Der Prozess ist vor dem Nutzer verborgen.
Um diese Funktion für bestimmte benutzerdefinierte Daten zu implementieren, müssen Sie JavaScript-Code bereitstellen, der synchron ein Array von Objekten zurückgibt, die die möglichen Werte zusammen mit ihren Labels darstellen. Das Array muss die folgenden Anforderungen erfüllen:
  • Alle Elemente im Array sollten JavaScript-Objekte sein.
  • Diese Objekte sollten zwei Schlüssel haben: einen Schlüssel value (mit dem tatsächlich möglichen Wert für die benutzerdefinierten Daten) und einen Schlüssel label (mit der textlichen Beschreibung dieses bestimmten Wertes).
  • Der Inhaltstyp für den Schlüssel value sollte dem tatsächlichen Typ der benutzerdefinierten Daten entsprechen. Für den Schlüssel label sollten Sie eine Zeichenkette als Inhalt angeben.
Im Codebeispiel unten sehen Sie ein Beispiel dafür, wie diese Funktion in der Praxis verwendet werden kann. In diesem Beispiel wird ein Remote-Aufruf an einen Drittanbieter-Server (in der Regel eine DMP oder eine ähnliche Plattform) durchgeführt, der die Liste der auf der Plattform definierten verfügbaren Segmente bereitstellt. Es ist wichtig zu beachten, dass dieser Code nur zum Erstellen der Auswahlschnittstelle für den Kameleoon-Endbenutzer verwendet wird. 
var xhr = new XMLHttpRequest();
xhr.open("GET", "https://third-party.dmp.com/get-segments?login=XXXX@XXXX.com&password=XXXX", false);

var segments = [];
xhr.onreadystatechange = function() {

    if (this.readyState === XMLHttpRequest.DONE && this.status === 200) {
        var data = JSON.parse(xhr.response);
        data.map(function (segment) {
          if (segment.segment_uuid && segment.name !== "undefined") {
            segments.push({"label": segment.name, "value": segment.segment_uuid});
          }
        });
    }
}

xhr.send();
return segments;
Stellen Sie sicher, dass der Code synchron ausgeführt wird und seinen Wert mit blockierendem Verhalten zurückgibt. Vermeiden Sie asynchrone Remote-Server-Aufrufe, da dies zu Fehlfunktionen der Funktion führen kann.