Kameleoon-Targeting-Bedingungen loesen Feature Flags basierend auf bestimmten Kriterien aus. Um diese Bedingungen effektiv zu nutzen, setzen Sie ihre Werte mit der Methode addData(). In einigen Szenarien rufen Sie getRemoteVisitorData() auf, um historische Besucherdaten abzurufen. Diese Kombination erzeugt hochgradig zielgerichtete und personalisierte Erfahrungen.
Daten in Kameleoon-SDKs verwalten
Genaue Daten gewaehrleisten konsistentes Targeting und Experimentation. Die folgenden Abschnitte erlaeutern, wie clientseitige und serverseitige SDKs Targeting-Bedingungen verwalten und wann getRemoteVisitorData() verwendet werden sollte, um Daten vom Server abzurufen.
Wichtige Terminologie
- Targeting-Bedingung: Das spezifische Benutzer- oder Sitzungsattribut, das fuer das Targeting verwendet wird (z. B. Conversion, Browser, Custom Data).
- Clientseitig: Datenverarbeitung fuer Standard-SDKs, die in einem Webbrowser oder einer mobilen App laufen.
- Clientseitig (Cross-device): Datenverarbeitung fuer clientseitige Implementierungen, die ein konsistentes Besucherprofil ueber mehrere Geraete hinweg aufrechterhalten.
- Serverseitig: Datenverarbeitung, wenn das SDK auf einem Backend-Server ausgefuehrt wird. Im Gegensatz zu clientseitigen SDKs loeschen serverseitige SDKs Besucherinformationen normalerweise nach Ende einer Sitzung.
Definitionen der Datenverarbeitung
Clientseitige SDKs
- Nein (Automatisch): Das SDK sammelt diese Daten automatisch. Es sind keine Remote-Anfragen oder expliziten
addData()-Aufrufe erforderlich.
- Nein: Das SDK sammelt diese Daten nicht automatisch. Sie muessen
addData(), trackConversion() oder Auswertungsmethoden wie getVariation() verwenden, um diese Daten hinzuzufuegen. Es ist keine Remote-Anfrage erforderlich.
- Ja: Sie muessen
getRemoteVisitorData() aufrufen. Dies gilt fuer Daten, die auf dem Server generiert werden (wie “Likelihood to convert”), oder beim Vereinheitlichen von Sitzungen ueber mehrere Geraete hinweg, um Aktionen von einem vorherigen Geraet abzurufen.
Serverseitige SDKs
- Nicht unterstuetzt: Das serverseitige SDK unterstuetzt diese Bedingung nicht.
- Nein (Automatisch): Gilt nur fuer “SDK Type”. Das SDK sammelt dies automatisch.
- Nein: Verwenden Sie
addData() oder trackConversion(), um diese Daten bereitzustellen. Es ist keine Remote-Anfrage erforderlich.
- Nein/Ja: Sie koennen die Daten direkt auf dem Server bereitstellen oder ueber eine Remote-Anfrage abrufen. Dies geschieht, wenn ein clientseitiges SDK waehrend des aktuellen Besuchs bereits Informationen gesammelt hat.
- Ja: Sie muessen
getRemoteVisitorData() aufrufen. Da serverseitige SDKs ueber begrenzten Datenspeicher verfuegen, benoetigen sie einen Remote-Aufruf, um historische Aktionen zu identifizieren, etwa frueheren Besuche oder Exklusivitaet fuer ein Experiment.
Anforderungen an die Datenerfassung
Das SDK benoetigt bestimmte Besucherdaten, um Targeting-Bedingungen auszuwerten. Die folgende Tabelle zeigt, welche Kriterien das SDK automatisch verarbeitet und welche einen expliziten Methodenaufruf erfordern.
| Targeting-Bedingung | Aktionen (Web) | Aktionen (Mobile) | Aktionen (Serverseitig) |
|---|
| Exclusive feature flag | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Target feature flag | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Browser (web-only) | Automatisch hinzugefuegt / addData() | Nicht unterstuetzt | addData() / getRemoteVisitorData() |
| Device | Automatisch hinzugefuegt / addData() | Automatisch hinzugefuegt / addData() | addData() / getRemoteVisitorData() |
| Conversion | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Custom data | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Page title (web-only) | Automatisch hinzugefuegt / addData() | Nicht unterstuetzt | addData() / getRemoteVisitorData() |
| Operating system | Automatisch hinzugefuegt / addData() | Automatisch hinzugefuegt | addData() / getRemoteVisitorData() |
| IP geolocation | addData() | addData() | addData() / getRemoteVisitorData() |
| SDK type | Automatisch hinzugefuegt | Automatisch hinzugefuegt | Automatisch hinzugefuegt |
| Visitor code | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | KameleoonClientFactory.create() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Segment | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Likelihood to convert | getRemoteVisitorData() | getRemoteVisitorData() | getRemoteVisitorData() |
getRemoteVisitorData() fuer historische Daten verwenden
Die folgende Tabelle zeigt, wann ein Remote-Aufruf von getRemoteVisitorData() erforderlich ist, um historische Daten fuer Targeting-Entscheidungen abzurufen.
| Targeting-Bedingung | Clientseitig | Clientseitig (Cross-device) | Serverseitig |
|---|
| Exclusive feature flag | Nein | Ja | Ja |
| Custom data | Nein | Ja | Ja |
| Page URL (web-only) | Nein (Automatisch) | Nein (Automatisch) | Nein/Ja |
| IP geolocation | Nein | Nein | Nein/Ja |
| SDK type | Nein (Automatisch) | Nein (Automatisch) | Nein (Automatisch) |
| Time since first visit | Nein (Automatisch) | Ja | Ja |
| Total number of visits | Nein (Automatisch) | Ja | Ja |
| Likelihood to convert | Ja | Ja | Ja |
Vorteile des Remote-Datenabrufs
Der Aufruf von getRemoteVisitorData() bietet die folgenden Vorteile:
- Aktuelle Informationen: Entscheidungen verwenden Echtzeitdaten aus der Data API.
- Geraeteuebergreifende Konsistenz: Greift auf Daten zu, die von anderen Geraeten oder Sitzungen erfasst wurden.
- Historischer Zugriff: Ruft frueheres Benutzerverhalten ab, wie z. B. frueheren URL-Besuche, selbst wenn der lokale SDK-Status geloescht wurde.
Verwenden Sie den Parameter VisitorDataFiltersType, um die Anzahl der abzurufenden frueheren Besuche anzugeben oder bestimmte Kriterienfilter anzuwenden.
Hybrid-Experimentation-Modus
Hybride Experimentation kombiniert das SDK mit dem Kameleoon-JavaScript-Snippet, um erweitertes Targeting zu ermoeglichen. Weitere Details finden Sie im Leitfaden Hybrid Experimentation.
Vorteile:
- Vereinfacht den Implementierungsprozess.
- Greift auf von der Engine erfasste clientseitige Daten (z. B. Datalayer-Variablen, Frontend-Ziele) direkt auf SDK-Ebene zu.
Voraussetzung:
- Implementieren Sie sowohl das SDK als auch das Kameleoon-JavaScript-Tag.
Der Aufruf von getRemoteVisitorData() in diesem Modus bietet Zugriff auf alle Datenpunkte, die von der Kameleoon-Engine auf der Webseite automatisch erfasst werden.
