Skip to main content
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, such as conversion, browser, or 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.
  • Web-only: A targeting condition based on data that only a browser generates, such as the page URL or page title. Web SDKs collect this data automatically. The Android, iOS, and Flutter SDKs don’t support these conditions because no browser generates the data. The React Native SDK has experimental support for them. Server-side SDKs do support these conditions: they receive the data through addData() or retrieve it from a prior web session with getRemoteVisitorData().

​
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 requirement 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 scenario 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.
“Web-only” labels the origin of the data, not which SDKs can use it. Web-only conditions come from browser data, so most mobile SDKs don’t support them, but server-side SDKs do, through addData() or getRemoteVisitorData(). The React Native SDK is the exception among mobile SDKs: it has experimental support for these conditions.
* Not supported in the Android, iOS, or Flutter SDKs. The React Native SDK has experimental support through addData().

​
Use getRemoteVisitorData() for historical data

The following table outlines when a remote call to getRemoteVisitorData() is required to retrieve historical data for targeting decisions.

​
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 guide. Benefits:
  • Streamlines the implementation process.
  • Accesses engine-collected client-side data, such as datalayer variables and 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.