Skip to main content
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, etwa Conversion, Browser oder 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.
  • Web-only: Eine Targeting-Bedingung, die auf Daten basiert, die nur ein Browser generiert, wie die Seiten-URL oder der Seitentitel. Web-SDKs sammeln diese Daten automatisch. Die Android-, iOS- und Flutter-SDKs unterstuetzen diese Bedingungen nicht, da kein Browser die Daten generiert. Das React-Native-SDK bietet dafuer experimentelle Unterstuetzung. Serverseitige SDKs unterstuetzen diese Bedingungen: Sie erhalten die Daten ueber addData() oder rufen sie aus einer vorherigen Web-Sitzung mit getRemoteVisitorData() ab.

​
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. Diese Anforderung 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. Dieser Fall tritt ein, 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.
„Web-only” kennzeichnet die Herkunft der Daten, nicht welche SDKs sie nutzen koennen. Web-only-Bedingungen stammen aus Browserdaten. Die meisten mobilen SDKs unterstuetzen sie deshalb nicht, serverseitige SDKs hingegen schon, ueber addData() oder getRemoteVisitorData(). Das React-Native-SDK ist die Ausnahme unter den mobilen SDKs: Es bietet experimentelle Unterstuetzung fuer diese Bedingungen.
* Nicht unterstuetzt in den Android-, iOS- oder Flutter-SDKs. Das React-Native-SDK bietet experimentelle Unterstuetzung ueber addData().

​
getRemoteVisitorData() fuer historische Daten verwenden

Die folgende Tabelle zeigt, wann ein Remote-Aufruf von getRemoteVisitorData() erforderlich ist, um historische Daten fuer Targeting-Entscheidungen abzurufen.

​
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 fruehere 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 (etwa 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.