Target users with native segmentation criteria
Kameleoon’s targeting conditions allow you to trigger feature flags based on specific criteria. To effectively use these conditions, you’ll need to set their values using the addData() method and, in some cases, call getRemoteVisitorData() to retrieve historical data. This combination helps you create highly targeted and personalized experiences for your users.
Handling data in Kameleoon SDKs
Accurate data is crucial for consistent targeting and experimentation within your application. Accurate data is crucial for consistent targeting and experimentation within an application. The following table explains how various targeting conditions are managed by client-side and server-side SDKs, particularly concerning whether a remote request (getRemoteVisitorData()) is required to fetch data from the server and make it available locally where the SDK runs. Understanding these distinctions helps with effective SDK implementation and ensures precise results by providing relevant data points for targeting decisions.
Key terminology
The table below summarizes how different targeting conditions interact with Kameleoon SDKs. The columns represent the specific targeting condition and SDK environment, while the cells indicate whether calling getRemoteVisitorData() is required to retrieve the relevant data type.
- Targeting condition: Refers to the specific user or session attribute being tracked or used for targeting (Conversion, Browser, Custom Data, for example).
- Client-side: Describes data handling for standard client-side SDKs, typically operating within a user’s web browser or mobile app.
- Client-side (Cross-device): Explains data handling for client-side implementations that aim to maintain a consistent visitor profile across multiple devices or sessions, which may necessitate remote calls for historical data.
- Server-side: Pertains to data handling when the SDK is implemented on a backend server. One of the main differences between a client-side and server-side SDK is that the server cannot store information about all visitors indefinitely; it has a visitor session after which all information is deleted.
The values within the table cells have specific meanings regarding data retrieval for Kameleoon SDKs, varying by SDK type:
Client-side SDK data handling
- No (Automatic): Signifies that the data is automatically collected by the SDK itself and does not require a remote request to
getRemoteVisitorData()or explicitaddData()calls from your application. The SDK gathers this information directly from the environment. For instance, client-side web SDKs automatically gather information about visited pages. Data types marked No (Automatic) are considered completely clear conditions without any hidden details. - No: Indicates that the data is not collected automatically. You must use
addData(),trackConversion(), or evaluation methods (getVariation(), for example) to add this data to the visitor. For example, adding a conversion, custom data, geolocation, or experiments allocation. This data does not require a remote request fromgetRemoteVisitorData(). - Yes: Calling
getRemoteVisitorData()is mandatory. A call togetRemoveVisitorData()is used for targeting conditions, the data for which is generated on the server and can change depending on various conditions, requiring this new data to be loaded (for example, the “Likelihood to convert” condition). Additionally, when the user has sessions across multiple devices, a call togetRemoteVisitorData()is mandatory for some conditions. For example, if a user was evaluated on one device and then logs in from another, all the user’s actions from the first device (like added conversions, custom data, or past visits) must be loaded so as not to violate the targeting conditions.
Server-side SDK data handling
- Not supported: Indicates that the condition isn’t supported by the server-side SDK.
- No (Automatic): For server-side SDKs, this applies only to the “SDK Type” data. This data is automatically collected and does not require a remote request or explicit
addData()calls. - No: Indicates that the data is not collected automatically, and you must use
addData()ortrackConversion()to add this data to the visitor. For example, adding a conversion, custom data, or geolocation. This data does not require a remote request fromgetRemoteVisitorData(). - No/Yes: Means that data can be added directly on the server side—for example, device or browser information—or obtained via a remote request. No/Yes instances occur when a client-side SDK (including Kameleoon Web Application
engine.jsif Kameleoon is used in Hybrid mode) has already collected relevant information during the current visit. In this scenario, callinggetRemoteVisitorData()makes all information from the current visit available on the server; however, it’s worth noting that data arrives to the servers via a network request, so synchronization between the client and server SDK requires time. - Yes: Calling
getRemoteVisitorData()is mandatory. Unlike client-side SDKs with persistent memories, server-side SDKs have a short time interval when the server memory stores information about a visitor. Therefore, in the case of server-side SDKs,getRemoteVisitorData()must be called, even if it isn’t required for the same data type in client-side SDKs. For example, in an exclusivity condition for an experiment where a visitor’s first session returns a false result (because the user was evaluated for another experiment), failing to load this data via a remote request in a new session would result in a true value, because the server does not know the previous historical actions of the user. The same situation occurs with visited pages, added data, and visitor conversions. In these cases, callinggetRemoteVisitorData()is mandatory. However, if historical data is irrelevant, the remote call is optional and can be omitted.
To evaluate targeting conditions correctly across web, mobile, and server-side platforms, the SDK requires specific visitor data. While the SDKs automatically capture some of this data, other conditions require manually passing information.
The table below identifies which targeting criteria are handled automatically and which require an explicit method call, like addData().
| 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, but overridable by addData() | Not supported | addData() / getRemoteVisitorData() |
| Device | Auto-added, but overridable by addData() | Auto-added, but overridable by addData() | addData() / getRemoteVisitorData() |
| Conversion | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Custom data | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Page title (web-only) | Auto-added, but overridable by addData() | Not supported | addData() / getRemoteVisitorData() |
| Operating system | Auto-added, but overridable by addData() | Auto-added | addData() / getRemoteVisitorData() |
| IP geolocation | addData() | addData() | addData() / getRemoteVisitorData() |
| Previous page (web-only) | Auto-added, but overridable by addData() | Not supported | addData() / getRemoteVisitorData() |
| Number of page views (web-only) | Auto-added, but overridable by addData() | Not supported | addData() / getRemoteVisitorData() |
| SDK type | Auto-added | Auto-added | Auto-added |
| Visitor code | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | KameleoonClientFactory.create() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Browser cookie (web-only) | addData() | Not supported | addData() |
| Segment | addData() / isFeatureActive() / getVariation(s) / getRemoteVisitorData() | addData() / isFeatureActive() / getVariation(s) / getRemoteVisitorData() | addData() / isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| App version | addData() | Auto-added | Support for addData() is currently limited to Node.js. |
| Time since first visit | Auto-calculated | Auto-calculated | getRemoteVisitorData() |
| Time since last visit | Auto-calculated | Auto-calculated | getRemoteVisitorData() |
| Number of visits today | Auto-calculated | Auto-calculated | getRemoteVisitorData() |
| Total number of visits | Auto-calculated | Auto-calculated | getRemoteVisitorData() |
| New or returning visitors | Auto-calculated | Auto-calculated | getRemoteVisitorData() |
| Likelihood to convert | getRemoteVisitorData() | getRemoteVisitorData() | getRemoteVisitorData() |
When is getRemoteVisitorData() required?
The following table outlines when a remote call to getRemoteVisitorData() is required to retrieve historical data for proper targeting decisions.
| Targeting condition | Client-side | Client-side (Cross-device) | Server-side |
|---|---|---|---|
| Exclusive feature flag | No | Yes | Yes |
| Target feature flag | No | Yes | Yes |
| Browser (web-only) | No (Automatic) | No (Automatic) | No/Yes |
| Device | No (Automatic) | No (Automatic) | No/Yes |
| Custom data | No | Yes | Yes |
| Page title (web-only) | No (Automatic) | No (Automatic) | No/Yes |
| Page URL (web-only) | No (Automatic) | No (Automatic) | No/Yes |
| Operating system | No (Automatic) | No (Automatic) | No/Yes |
| IP geolocation | No | No | No/Yes |
| Previous page (web-only) | No (Automatic) | Yes | Yes |
| Number of page views (web-only) | No (Automatic) | Yes | Yes |
| SDK type | No (Automatic) | No (Automatic) | No (Automatic) |
| Visitor code | No | No | No |
| Browser cookie (web-only) | No | No | No |
| Segment | No | No | No |
| App version | No (Automatic) | No (Automatic) | Not supported |
| Time since first visit | No (Automatic) | Yes | Yes |
| Time since last visit | No (Automatic) | Yes | Yes |
| Number of visits today | No (Automatic) | Yes | Yes |
| Total number of visits | No (Automatic) | Yes | Yes |
| New or returning visitors | No (Automatic) | Yes | Yes |
| Likelihood to convert | Yes | Yes | Yes |
Although it is not always required, calling getRemoteVisitorData() provides several benefits. By fetching real-time data from the Data API, targeting decisions are based on the most up-to-date information. Calling getRemoteVisitorData() allows for more precise targeting and consistent data across all devices used by a user.
Using getRemoteVisitorData() can significantly expand the range of data available for evaluation, especially when:
- You want to include data collected from other devices.
- You're using Kameleoon in Hybrid mode.
- You need to access a user's historical data, such as previous visits to a specific URL.
For example, if a user visits a page and the SDK tracks the URL, the data is stored locally and on the server. However, as all data collected by the SDK is stored in memory for the duration of a session (which defaults to 30 minutes, read more here), the SDK's local state might be cleared, and the data may no longer be available for targeting.
To ensure accurate targeting of a visitor, calling getRemoteVisitorData() loads previously visited pages from the server. This call helps maintain a consistent view of user behavior, even if the SDK's local state has been cleared.
To retrieve past visit history using getRemoteVisitorData(), use the VisitorDataFiltersType parameter. This parameter lets you specify the number of past visits to retrieve and apply filters based on specific criteria.
Hybrid Experimentation mode
Hybrid Experimentation is a comprehensive approach that combines the SDK and Kameleoon JavaScript snippet to enable advanced user targeting.
Benefits:
- Streamlined implementation process.
- Ability to access engine-collected client-side data directly at the SDK level.
Requirement:
- Implementation of both the SDK and Kameleoon JavaScript tag.
The ability to access engine-collected client-side data at the SDK level provides greater flexibility and control over targeting strategies. It is particularly useful for using data accessible only on the client-side: datalayer variables, goals that only convert on the front-end, and exposure to web experiments and personalizations. Calling getRemoteVisitorData() allows access to all data points that Kameleoon has automatically collected about the visitor on the webpage.
For more information on hybrid experimentation, read the dedicated documentation.