Target users with native segmentation criteria

​

Manage data in Kameleoon SDKs

​

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 collection requirements

​

Use getRemoteVisitorData() for historical data

​

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

• 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.

​

Benefits of remote data retrieval

• 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.

​

Edge targeting constraints

​

Where visitor data comes from at the edge

​

getRemoteVisitorData() at the edge

• Latency: A call to getRemoteVisitorData() typically takes 100-200 ms to fetch historical visitor data from the Data API. Flag and variation evaluation itself normally completes in milliseconds, so adding a remote data fetch to every request pushes latency well outside what most edge use cases target.
• No durable shared memory: An edge platform can destroy and recreate a worker instance at any time, so caching a getRemoteVisitorData() result across requests isn’t reliable unless your framework offers durable, cross-request memory to store it in.

​

Pass visitor data into the edge worker

1. Collect the visitor attributes upstream, for example during an earlier page load or client-side SDK call.
2. Pass the attributes into the edge request, typically as cookies, since an edge worker can read cookies from the incoming request without making an external call.
3. In the edge worker, read the attributes and call addData() with them before evaluating any feature flag or experiment.

import { CustomData } from '@kameleoon/nodejs-sdk';

// Inside the edge worker, before evaluating any feature flag
const visitorCode = getCookie(request, 'kameleoonVisitorCode');
const plan = getCookie(request, 'customerPlan');

const customData = new CustomData(1, plan);
client.addData(visitorCode, customData);

const variation = client.getVariation({ visitorCode, featureKey: 'my_feature_key' });

​

Constraints vary by edge framework and plan

​

Hybrid Experimentation mode

• Streamlines the implementation process.
• Accesses engine-collected client-side data, such as datalayer variables and front-end goals, directly at the SDK level.

• Implement both the SDK and the Kameleoon JavaScript tag.