> ## Documentation Index > Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt > Use this file to discover all available pages before exploring further. # Benutzer mit nativen Segmentierungskriterien ansprechen > Loesen Sie Feature Flags basierend auf bestimmten Kriterien aus und verwalten Sie Besucherdaten ueber SDK-Umgebungen hinweg. 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](../technical-reference/technical-considerations#datenspeicherung) 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](../get-started/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.