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. Below, we will explain how various targeting conditions are managed by our client-side and server-side SDKs, particularly concerning whether a remote request (getRemoteVisitorData()) is required to fetch data from our servers and make it available locally where the SDK runs. Understanding these distinctions will help you implement our SDKs effectively and ensure your experiments yield precise results by providing relevant data points for targeting decisions.
Key terminology
The table below summarizes how different targeting conditions interact with our 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 our 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 our SDK is implemented on your 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 the 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 you use Kameleoon in Hybrid mode) has already collected relevant information during the current visit. In this scenario, callinggetRemoteVisitorData()will make all information from the current visit available on the server; however, it’s worth noting that the data will arrive to our servers via a network request, so it will take some time to synchronize data between the client and server SDK. - 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, you must callgetRemoteVisitorData(), even if it isn’t required for the same data type in client-side SDKs. For example, let’s say we have a condition for the exclusivity of an experiment and in a visitor’s first session we receive a false result. We receive a false result because the user was evaluated for another experiment, thereby failing to fulfill the exclusivity condition. In a new session, if this data is not loaded via a remote request, the user’s value will be true, because at the time of evaluation, the server does not know the previous historical actions of the user. The same situation occurs with visited pages, added data, and visitor conversions. Therefore, in these cases, callinggetRemoteVisitorData()is strictly mandatory. However, if historical data is irrelevant, the remote call is optional and can be omitted.
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 |
| Conversion | No | Yes | 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 |
Benefits of calling getRemoteVisitorData()
Although it's not always required, there are several benefits of calling getRemoteVisitorData(). By fetching real-time data from the Data API, you can ensure that your 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 given 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, suppose a user visits a page and the SDK is configured to track visited pages' URLs. The data will be stored locally and on our servers. 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 SDK will not be able to use that data for targeting purposes anymore.
To ensure accurate targeting of a given visitor, calling getRemoteVisitorData() will load previously visited pages from our servers. This call will help maintain a consistent view of the user's 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 your targeting strategies. It is particularly useful when you want to use data that is only accessible on the client-side: datalayer variables, goals that only convert on the front-end, and exposure to web experiments and personalizations. Calling getRemoteVisitorData() allows you to access all data points that Kameleoon has automatically collected about the visitor on the current webpage.
For more information on hybrid experimentation, read our dedicated documentation.