Skip to main content
Kameleoon-Targeting-Bedingungen lösen 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 gewährleisten konsistentes Targeting und Experimentation. Die folgenden Abschnitte erläutern, 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 für das Targeting verwendet wird, etwa Conversion, Browser oder Custom Data.
  • Clientseitig: Datenverarbeitung für Standard-SDKs, die in einem Webbrowser oder einer mobilen App laufen.
  • Clientseitig (Cross-device): Datenverarbeitung für clientseitige Implementierungen, die ein konsistentes Besucherprofil über mehrere Geräte hinweg aufrechterhalten.
  • Serverseitig: Datenverarbeitung, wenn das SDK auf einem Backend-Server ausgeführt wird. Im Gegensatz zu clientseitigen SDKs löschen 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 unterstützen diese Bedingungen nicht, da kein Browser die Daten generiert. Das React-Native-SDK bietet dafür experimentelle Unterstützung. Serverseitige SDKs unterstützen diese Bedingungen: Sie erhalten die Daten über addData() oder rufen sie aus einer vorherigen Web-Sitzung mit getRemoteVisitorData() ab.

​
Anforderungen an die Datenerfassung

Das SDK benötigt 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 können. Web-only-Bedingungen stammen aus Browserdaten. Die meisten mobilen SDKs unterstützen sie deshalb nicht, serverseitige SDKs hingegen schon, über addData() oder getRemoteVisitorData(). Das React-Native-SDK ist die Ausnahme unter den mobilen SDKs: Es bietet experimentelle Unterstützung für diese Bedingungen.
  • * Automatische Datenerfassung funktioniert nicht in Single-Page Applications (SPAs). In einer SPA müssen Sie die Methode addData() manuell aufrufen.
  • ** Nicht unterstützt in den mobilen SDKs (Android, iOS oder Flutter). Das React-Native-SDK bietet experimentelle Unterstützung über addData().

​
getRemoteVisitorData() für historische Daten verwenden

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

​
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 müssen addData(), trackConversion() oder Auswertungsmethoden wie getVariation() verwenden, um diese Daten hinzuzufügen. Es ist keine Remote-Anfrage erforderlich.
  • Ja: Sie müssen getRemoteVisitorData() aufrufen. Diese Anforderung gilt für Daten, die auf dem Server generiert werden (wie „Likelihood to convert”) oder beim Vereinheitlichen von Sitzungen über mehrere Geräte hinweg, um Aktionen von einem vorherigen Gerät abzurufen.

​
Serverseitige SDKs

  • Nein (Automatisch): Gilt nur für „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 können die Daten direkt auf dem Server bereitstellen oder über eine Remote-Anfrage abrufen. Dieser Fall tritt ein, wenn ein clientseitiges SDK während des aktuellen Besuchs bereits Informationen gesammelt hat.
  • Ja: Sie müssen getRemoteVisitorData() aufrufen. Da serverseitige SDKs über begrenzten Datenspeicher verfügen, benötigen sie einen Remote-Aufruf, um historische Aktionen zu identifizieren, etwa frühere Besuche oder Exklusivität für ein Experiment.

​
Vorteile des Remote-Datenabrufs

Der Aufruf von getRemoteVisitorData() bietet die folgenden Vorteile:
  • Aktuelle Informationen: Entscheidungen verwenden Echtzeitdaten aus der Data API.
  • Geräteübergreifende Konsistenz: Greift auf Daten zu, die von anderen Geräten oder Sitzungen erfasst wurden.
  • Historischer Zugriff: Ruft früheres Benutzerverhalten ab, wie frühere URL-Besuche, selbst wenn der lokale SDK-Status gelöscht wurde.
Verwenden Sie den Parameter VisitorDataFiltersType, um die Anzahl der abzurufenden früheren Besuche anzugeben oder bestimmte Kriterienfilter anzuwenden.

​
Targeting-Einschränkungen am Edge

Feature Flags und Experimente, die am Edge ausgewertet werden, haben nur Zugriff auf die Besucherdaten, die Ihre Integration dem Edge-Worker zur Verfügung stellt. Eine Edge-Anfrage verhält sich wie eine serverseitige SDK-Auswertung für eine brandneue Besuchersitzung: Der Edge-Worker hat keine garantierte Erinnerung an eine vorherige Anfrage dieses Besuchers, sodass die meisten Targeting-Bedingungen keine Daten zur Auswertung haben, sofern Sie diese nicht explizit bereitstellen. Wie Sie Besucherdaten in den Edge-Worker bringen, damit er Targeting-Bedingungen auswerten kann, wird im Folgenden beschrieben. Das Zurücksenden der resultierenden Flag- und Variationsentscheidungen an Ihren Ursprungsserver ist ein separates Anliegen, das nicht durch den hier beschriebenen addData()- und Cookie-Mechanismus abgedeckt wird. Edge-Frameworks bieten unterschiedliche Mechanismen dafür; lesen Sie die Dokumentation Ihres eigenen Frameworks.

​
Woher die Besucherdaten am Edge stammen

Je nach Edge-Framework sind einige Browser- und Gerätedaten, etwa User-Agent und Geolokalisierung, direkt aus der eingehenden Anfrage über die plattformeigenen Request-Context-APIs verfügbar. Überprüfen Sie die Dokumentation Ihres Frameworks, um zu erfahren, was es offenlegt. Jede andere Targeting-Bedingung, einschließlich Custom Data und Besucherverlauf, hat keinen Weg in den Worker, sofern Ihre Integration sie nicht explizit bereitstellt. Unabhängig davon, woher die Daten stammen, ist Ihre Integration dafür verantwortlich, die Daten auszulesen und addData() damit aufzurufen, bevor Sie ein Feature Flag oder Experiment auswerten. Kameleoon sammelt keine dieser Daten am Edge in Ihrem Auftrag, auch nicht die Daten, die ein Framework auf der Anfrage selbst offenlegt.

​
getRemoteVisitorData() am Edge

getRemoteVisitorData() funktioniert am Edge genauso wie in jeder serverseitigen Auswertung, ist jedoch für die meisten Edge-Anwendungsfälle nicht praktikabel:
  • Latenz: Ein Aufruf von getRemoteVisitorData() dauert in der Regel 100-200 ms, um historische Besucherdaten aus der Data API abzurufen. Die Auswertung von Flags und Variationen selbst wird normalerweise in Millisekunden abgeschlossen, sodass das Hinzufügen eines Remote-Datenabrufs zu jeder Anfrage die Latenz weit über das hinaus treibt, was die meisten Edge-Anwendungsfälle anstreben.
  • Kein dauerhafter gemeinsamer Speicher: Eine Edge-Plattform kann eine Worker-Instanz jederzeit zerstören und neu erstellen. Das Zwischenspeichern eines getRemoteVisitorData()-Ergebnisses über mehrere Anfragen hinweg ist daher nicht zuverlässig, sofern Ihr Framework keinen dauerhaften, anfragenübergreifenden Speicher dafür bietet.
Wie diese Methode außerhalb des Edge funktioniert, erfahren Sie unter getRemoteVisitorData() für historische Daten verwenden. Stellen Sie für die meisten Edge-Anwendungsfälle stattdessen die von Ihren Targeting-Bedingungen benötigten Besucherdaten über addData() bereit, mit dem unten beschriebenen Ansatz.

​
Besucherdaten an den Edge-Worker übergeben

Da das Edge-SDK Besucherdaten weder selbst abrufen noch speichern kann, ist Ihre Integration dafür verantwortlich, diese Daten zum Zeitpunkt der Anfrage bereitzustellen:
  1. Erfassen Sie die Besucherattribute upstream, zum Beispiel bei einem früheren Seitenaufruf oder einem clientseitigen SDK-Aufruf.
  2. Übergeben Sie die Attribute an die Edge-Anfrage, üblicherweise als Cookies, da ein Edge-Worker Cookies aus der eingehenden Anfrage lesen kann, ohne einen externen Aufruf durchzuführen.
  3. Lesen Sie im Edge-Worker die Attribute aus und rufen Sie addData() damit auf, bevor Sie ein Feature Flag oder Experiment auswerten.
Cookies haben ein praktisches Größenlimit von etwa 4 KB. Reservieren Sie dieses Budget für die Besucherattribute, die Ihre Targeting-Bedingungen tatsächlich benötigen.

​
Einschränkungen variieren je nach Edge-Framework und Plan

Die Fähigkeiten von Edge-Frameworks ändern sich im Laufe der Zeit und können von Ihrem spezifischen Plan bei einem Anbieter abhängen, nicht nur davon, welchen Anbieter Sie nutzen. Die Unterstützung externer Anfragen, anfragenübergreifender gemeinsamer Speicher und die Abrechnung der Rechenzeit variieren zwischen den Frameworks und können sich zwischen Plan-Stufen oder bei einer Aktualisierung des Angebots durch einen Anbieter ändern. Überprüfen Sie die aktuelle Dokumentation Ihres Frameworks und die Plan-Details Ihres Kontos, bevor Sie sich auf eine bestimmte Fähigkeit wie einen externen Aufruf oder anfragenübergreifendes Caching verlassen. Die von Kameleoon derzeit unterstützten Frameworks finden Sie unter Serverless edge compute starter kits.

​
Hybrid-Experimentation-Modus

Hybrid Experimentation kombiniert das SDK mit dem Kameleoon-JavaScript-Snippet, um erweitertes Targeting zu ermöglichen. Weitere Details finden Sie im Leitfaden Hybrid Experimentation. Vorteile:
  • Vereinfacht den Implementierungsprozess.
  • Greift auf von der Engine erfasste clientseitige Daten, wie Datalayer-Variablen und Front-end-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.

​
FAQ

Ja, die Daten sind sofort für das Targeting verfügbar. Bei serverbasierten SDKs stehen die Daten während der Besuchersitzung zur Verfügung, bei clientbasierten SDKs (mobil und Web) während der eingestellten Lebensdauer.
Wenn Sie ein serverbasiertes SDK verwenden, speichert es die Daten während der Sitzung eines Besuchers. Sie müssen die Daten nicht bei jeder Anfrage laden, solange die Sitzung des Besuchers nicht abgelaufen ist. In mobilen SDKs werden Daten unbegrenzt gespeichert (oder gemäß Ihren Einstellungen).Wenn die Besuchersitzung nicht mehr aktiv ist oder wenn der Besucher im clientseitigen SDK zwischen Geräten wechselt, rufen Sie die Methode getRemoteVisitorData mit den passenden Parametern auf, um die an die Data API gesendeten Daten abzurufen. Nach dem Laden nimmt das SDK die Daten in das Targeting des Besuchers auf.
Ein Edge-Worker hat keine garantierte Erinnerung an frühere Anfragen eines Besuchers. Deshalb verhält er sich wie ein serverseitiges SDK, das bei jeder Anfrage eine völlig neue Besuchersitzung auswertet. Die meisten Targeting-Bedingungen haben keine Daten zur Auswertung, sofern Ihre Integration diese Daten nicht explizit bereitstellt. Typischerweise geschieht das, indem Sie die Daten aus einem Cookie lesen und addData() aufrufen, bevor das Feature Flag ausgewertet wird.getRemoteVisitorData() funktioniert am Edge. Wegen der Latenz (typischerweise 100-200 ms) und des fehlenden dauerhaften Speichers über Anfragen hinweg auf den meisten Edge-Plattformen ist die Methode für die meisten Edge-Anwendungsfälle jedoch unpraktisch.Die vollständige Erklärung mit einem Codebeispiel finden Sie unter Targeting-Einschränkungen am Edge. Die unterstützten Frameworks sind im Artikel Serverless Edge Compute Starter Kits beschrieben.