Kameleoon targeting conditions trigger feature flags based on specific criteria. To use these conditions effectively, set their values with theDocumentation Index
Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
Use this file to discover all available pages before exploring further.
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 usegetRemoteVisitorData() 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 likegetVariation()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()ortrackConversion()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, 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 togetRemoteVisitorData() 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
CallinggetRemoteVisitorData() 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 guide. Benefits:- Streamlines the implementation process.
- Accesses engine-collected client-side data (e.g., datalayer variables, front-end goals) directly at the SDK level.
- Implement both the SDK and the Kameleoon JavaScript tag.