> ## 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. # Target users with native segmentation criteria > Trigger feature flags based on specific criteria and manage visitor data across SDK environments. Kameleoon targeting conditions trigger feature flags based on specific criteria. To use these conditions effectively, set their values with the `addData()` method. In some scenarios, call `getRemoteVisitorData()` to retrieve historical visitor data. This combination creates highly targeted and personalized experiences. ## Manage data in Kameleoon SDKs Accurate data ensures consistent targeting and experimentation. The following sections explain how client-side and server-side SDKs manage targeting conditions and specify when to use `getRemoteVisitorData()` to fetch data from the server. ### Key terminology * **Targeting condition**: The specific user or session attribute used for targeting (e.g., Conversion, Browser, Custom Data). * **Client-side**: Data handling for standard SDKs operating in a web browser or mobile app. * **Client-side (Cross-device)**: Data handling for client-side implementations that maintain a consistent visitor profile across multiple devices. * **Server-side**: Data handling when the SDK runs on a backend server. Unlike client-side SDKs, server-side SDKs typically delete visitor information after a session ends. ### Data handling definitions #### Client-side SDKs * **No (Automatic)**: The SDK collects this data automatically. It requires no remote requests or explicit `addData()` calls. * **No**: The SDK does not collect this data automatically. You must use `addData()`, `trackConversion()`, or evaluation methods like `getVariation()` to add this data. It does not require a remote request. * **Yes**: You must call `getRemoteVisitorData()`. This applies to data generated on the server (like "Likelihood to convert") or when unifying sessions across multiple devices to retrieve actions from a previous device. #### Server-side SDKs * **Not supported**: The server-side SDK does not support this condition. * **No (Automatic)**: Applies only to "SDK Type." The SDK collects this automatically. * **No**: Use `addData()` or `trackConversion()` to provide this data. It does not require a remote request. * **No/Yes**: You can provide data directly on the server or obtain it via a remote request. This occurs if a client-side SDK has already collected information during the current visit. * **Yes**: You must call `getRemoteVisitorData()`. Because server-side SDKs have [limited data storage](../technical-reference/technical-considerations#data-storage), they require a remote call to identify historical actions, such as previous visits or exclusivity for an experiment. ## Data collection requirements The SDK requires specific visitor data to evaluate targeting conditions. The table below identifies which criteria the SDK handles automatically and which require an explicit method call. | Targeting condition | Actions (Web) | Actions (Mobile) | Actions (Server-side) | | :------------------------- | :----------------------------------------------------------------- | :----------------------------------------------------------------- | :----------------------------------------------------------------- | | **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)** | Auto-added / `addData()` | Not supported | `addData()` / `getRemoteVisitorData()` | | **Device** | Auto-added / `addData()` | Auto-added / `addData()` | `addData()` / `getRemoteVisitorData()` | | **Conversion** | `addData()` / `getRemoteVisitorData()` | `addData()` / `getRemoteVisitorData()` | `addData()` / `getRemoteVisitorData()` | | **Custom data** | `addData()` / `getRemoteVisitorData()` | `addData()` / `getRemoteVisitorData()` | `addData()` / `getRemoteVisitorData()` | | **Page title (web-only)** | Auto-added / `addData()` | Not supported | `addData()` / `getRemoteVisitorData()` | | **Operating system** | Auto-added / `addData()` | Auto-added | `addData()` / `getRemoteVisitorData()` | | **IP geolocation** | `addData()` | `addData()` | `addData()` / `getRemoteVisitorData()` | | **SDK type** | Auto-added | Auto-added | Auto-added | | **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()` | ## Use getRemoteVisitorData() for historical data The following table outlines when a remote call to `getRemoteVisitorData()` is required to retrieve historical data for targeting decisions. | Targeting condition | Client-side | Client-side (Cross-device) | Server-side | | :------------------------- | :------------- | :------------------------- | :------------- | | **Exclusive feature flag** | No | Yes | Yes | | **Custom data** | No | Yes | Yes | | **Page URL (web-only)** | No (Automatic) | No (Automatic) | No/Yes | | **IP geolocation** | No | No | No/Yes | | **SDK type** | No (Automatic) | No (Automatic) | No (Automatic) | | **Time since first visit** | No (Automatic) | Yes | Yes | | **Total number of visits** | No (Automatic) | Yes | Yes | | **Likelihood to convert** | Yes | Yes | Yes | ### Benefits of remote data retrieval Calling `getRemoteVisitorData()` provides the following advantages: * **Up-to-date information**: Decisions use real-time data from the Data API. * **Cross-device consistency**: Accesses data collected from other devices or sessions. * **Historical access**: Retrieves previous user behavior, such as past URL visits, even if the local SDK state has cleared. Use the `VisitorDataFiltersType` parameter to specify the number of past visits to retrieve or to apply specific criteria filters. ## Hybrid Experimentation mode Hybrid Experimentation combines the SDK with the Kameleoon JavaScript snippet to enable advanced targeting. For more details, see the [Hybrid Experimentation](../get-started/hybrid-experimentation) guide. **Benefits:** * Streamlines the implementation process. * Accesses engine-collected client-side data (e.g., datalayer variables, front-end goals) directly at the SDK level. **Requirement:** * Implement both the SDK and the Kameleoon JavaScript tag. ## Calling `getRemoteVisitorData()` in this mode provides access to all data points automatically collected by the Kameleoon engine on the webpage.