Skip to main content

Handling SDK implementation across a mobile app, server, and web app

This article explains how to coordinate Kameleoon SDKs across your website, mobile app, and backend server. It focuses on maintaining a unified visitor identity and ensuring consistent experiment handling and data flow across all platforms.

Use this guide when your project implements multiple Kameleoon SDKs:

  • The JavaScript SDK or engine.js for web environments.
  • The mobile SDK for Android or iOS apps.
  • Server-side SDKs for backend integrations and decision logic.

Architecture overview​

A typical multi-environment setup includes:

  • A website that uses the JavaScript or engine.js to run client-side experiments and personalization campaigns.
  • A mobile app that uses a mobile SDK to display variations and track conversions.
  • A backend server that uses a server-side SDK to make centralized variation decisions or synchronize visitor data.

Data and visitor code flow​

  • The visitor code identifies users consistently across all environments.
  • The server-side SDK coordinates variation decisions when needed.
  • Each SDK sends analytics and tracking data directly to the Kameleoon platform.

Visitor code and cross-device management​

Generate and share visitor codes​

Each unique visitor must have one consistent visitor code across all platforms. This code lets Kameleoon unify experiment decisions and tracking.

A typical cross-platform flow looks like this:

  1. The visitor code is generated by the engine, web SDK, server-side SDK, or mobile application.
  2. When the user logs in on a new platform, your backend retrieves the existing visitor code.
  3. That visitor code is passed to the mobile SDK, server-side SDK, and web SDK so all platforms evaluate the same user consistently.

Synchronize visitor codes​

  • Store the visitor code securely in your backend or user database, linked to the user ID.
  • When a user logs in on another platform:
    • The mobile app requests the visitor code from your backend.
    • The server-side SDK uses the same visitor code for all variation and tracking calls.
    • The web SDK sets the visitor code using the JavaScript API, for example:
kameleoon.API.Visitor.setVisitorCode(visitorCode);
note

The web SDK and server-side SDK communicate automatically via the kameleoonVisitorCode cookie. You do not need to perform additional steps to link these two.

Best practices​

  • Use one visitor code per user by mapping your existing user identifier (such as userId) to a single Kameleoon visitor code across all platforms.
  • Keep your backend as the source of truth for visitors codes.
  • Prevent your SDKs from overwriting existing visitor codes for known users.

This approach ensures every user action, conversion, and variation decision links to the same visitor in Kameleoon.

Experiment handling across environments​

Experiments that span multiple environments (such as mobile and backend) require you to coordinate decisions and variation display carefully.

Example scenario​

You want to run an experiment where:

  • The mobile app displays the variation.
  • The backend server determines which variation to show.

Implementation options​

Option 1: Server-side decision logic​
  1. The mobile app sends the visitor code to your backend.
  2. The server-side SDK calls getVariation() (or equivalent) to retrieve the assigned variation.
  3. The backend returns the variation ID or name to the mobile app.
  4. The mobile app displays the variation and tracks exposure.
  5. Both the mobile and server SDKs use the same visitor code for tracking events.

Advantages:

  • Centralizes variation logic and ensures consistent decisions.
  • Supports experiments that affect backend logic and UI elements.
Option 2: Client-side (mobile) decision logic​
  1. The mobile SDK retrieves the variation assignment using the visitor code.
  2. The mobile app applies the variation locally and tracks exposure directly.
  3. (Optional) If your backend also participates in tracking or validation, the server-side SDK can reuse the same visitor code to ensure consistent reporting across environments.

Advantages:

  • Provides a synchronous, zero-latency decision (no waiting for a server response).
  • Reduces latency by avoiding a server round trip.
  • Works best for UI-focused experiments that don't depend on backend logic.

Choose the right setup​

Use caseDecision layerVisitor code sourceNotes
Mobile UI experimentMobile SDKBackend (shared visitor code)Handles variation locally
Backend or API-driven experimentServer-side SDKApp or websiteCentralized decision logic
Cross-device consistencyAnyBackendEnsures unified tracking

Example: Pass visitor code between layers​

// Web (JavaScript)
const visitorCode = kameleoon.API.Visitor.code;
fetch("/api/syncVisitor", {
  method: "POST",
  body: JSON.stringify({ visitorCode }),
});
// Mobile (iOS)
let kameleoonClient = try KameleoonClientFactory.create(siteCode: siteCode, visitorCode: visitorCodeFromBackend)
let variation = try kameleoonClient.getVariation(featureKey: featureKey)
# Server-side (Python)
client = KameleoonClientFactory.create(SITE_CODE, config)
variation = client.get_variation(visitor_code, feature_key)

To handle SDK implementation across your website, mobile app, and backend effectively:

  • Use a single visitor code per user across all platforms.
  • Let your backend manage and distribute visitor codes.
  • Decide where to handle variation logic—on the server for centralized experiments or client-side for app-driven ones.
  • Track all user activity using the same visitor code to maintain consistent, cross-device data in Kameleoon.