Technical considerations
Feature flags configuration and bucketing
When you update a feature flag configuration or turn the feature flag on or off, our SDKs can obtain the updated configuration from our Cloudflare Content Delivery Network (CDN) using either polling or streaming. Polling is the default option while streaming is a premium option.
Our SDKs are designed to comply with a zero latency policy. This means that the SDK doesn't require additional remote server calls to activate and bucket users in a feature flag. Even the fastest remote server call would add a minimum of 20 ms of latency to your application and depending on a number of factors, this delay can increase to hundreds of milliseconds, or even completely block the loading of your web application for the end user. To prevent this added latency, Kameleoon SDKs assign visitors to experiments locally.
For client-side SDKs, which run on the user's device, your app must fetch the active feature flag configurations at the start of the session. This requires a remote call with an associated callback, which means your application code that uses SDK can't run experiments or apply feature flags before this callback finishes executing.
Polling (default)
In this mode, the SDK sends a request to our CDN at regular intervals (by default, every 60 minutes) to retrieve most recent configuration. You can set a custom interval in the SDK configuration (using the refresh_interval_minute (refresh_interval) parameter).
When intervals are moderately spaced, updating the configuration consumes very little memory and network resources.
Streaming (premium option)
The real-time streaming mode allows the SDK to automatically apply the new configuration without any delay. When streaming is enabled, the Kameleoon SDK is notified of any changes to the configuration in real time, thanks to server-sent events (SSE).
Main benefits:
- Update your configuration immediately (no waiting for the next polling cycle).
- Use less network traffic than polling at short intervals. Streaming does not send periodic requests. It opens the connection once and keeps it permanently open and remain ready to receive data.
Availability:
- This is a premium option that you must subscribe to. To activate real-time streaming on your Kameleoon account, contact your Customer Success Manager or email support@kameleoon.com.
- The PHP SDK does not support streaming due to technical constraints. The PHP SDK currently can't listen for configuration updates in a non-blocking way because the PHP SDK does not persist between requests. Each request creates a new SDK instance that destroys itself as soon as it receives a response.
- The real-time streaming mode is currently not compatible with serverless edge compute platforms.
- For other languagues, see the SDK compatibility matrix for the minimum supported version in your preferred language.
Data storage
Our SDKs manage custom visitor data locally on your server or on the user's device instead of fetching it from a remote Kameleoon server. This is achieved by storing visitor data in memory (RAM or Local Storage), organized as a map with unique visitorCodes as keys. For example, when you use the addData() method, the data is automatically stored in memory on the server or user device.
All data collected by the SDK is stored in memory for the duration of a session, which defaults to 30 minutes. You can customize the session duration to align with your server session duration by adjusting the value of the session_duration parameter in the SDK configuration. Keep in mind that extending the session duration requires the SDK to allocate more memory to store the increased visitor data.
The session_duration parameter only manages data storage in local memory. Kameleoon reports the analytics based on a visit or a visitor. Every time the same visitor views your website, a new visit is created by Kameleoon and ends after 30 minutes of inactivity (such as page views, scrolls, clicks, and so on).
At any time, you can use the getRemoteVisitorData() method to retrieve all custom data collected during the previous visit by the current visitor. Importantly, the getRemoteVisitorData() method automatically associates the latest custom data entry for the visitor, eliminating the need to call addData() afterwards.
For server-side SDKs, it is important to be aware that visitor data will be lost if you restart your application server because it is stored in RAM. In most cases, this is not a problem since important custom data is usually retrieved from a persistent database and then assigned to the current visitor. You can use the getRemoteVisitorData() method to retrieve all custom data collected during the previous visit by the current visitor.
Kameleoon stores the data in the following storage types or locations, depending on the SDK you're using:
- iOS:
UserDefaults - Android:
SharedPreferences - JavaScript / TypeScript:
LocalStorage - NodeJS:
Server memory - React-Native:
MMKV Storage
Domain list
The Kameleoon SDKs require access to a set of URIs that provide specific services to the SDK. If you are restricting access and need to explicitly whitelist domains, make sure that our SDKs can reach the following domains:
| URI | Used by |
|---|---|
https://<sitecode>.kameleoon.io/sdk-config | Configuration file |
https://client-config.kameleoon.com/mobile | Configuration file |
https://events.kameleoon.com:8110/sse | Real-time streaming |
https://api.kameleoon.com/oauth/token | Authentication |
https://data.kameleoon.io | Tracking |
Note: The domain for your Kameleoon scripts may vary from one project to another. Your projects may be hosted on either kameleoon.eu or kameleoon.io depending on their creation date. Make sure you use the domain displayed in your project in the Kameleoon App.