Skip to main content
Kameleoon separates two distinct operations: data collection and data reporting. Data collection is near-instant. Reporting is visitor or visit-based and is not a real-time view. Understanding the distinction prevents a common mistake: using the Results page as a QA tool. The Results page shows analyzed visit and visitor data, along with conversions for the goals that measure an experiment or personalization campaign’s performance, not a live feed of incoming events. Use Live events to confirm that tracking is working.

​
How Kameleoon collects data

The collection method depends on your implementation type.

​
Web Experimentation

For web implementations, Kameleoon collects data through the engine.js script running in the visitor’s browser. When a visitor loads a page, the engine:
  1. Initializes the visitor and evaluates which experiments and personalizations apply.
  2. Assigns the visitor to a variation.
  3. Sends tracking events (such as page views, experiment exposures, scroll activity, and goal conversions) to the Kameleoon Data API.
The engine batches outgoing requests and processes the queue approximately every 500 ms. On page unload, the engine forces immediate transmission so it doesn’t lose in-flight events.
The browser caches engine.js. When you start an experiment or add a goal in the Kameleoon app, new visitors and returning visitors whose cached engine.js has expired get the update right away. Returning visitors with a still-valid cached version don’t get the update until their browser fetches the new configuration.To QA a change, load the page in an incognito or private window, or force a hard refresh, so your browser doesn’t serve a cached version of engine.js. See Will Kameleoon’s script (engine.js) slow down my website? for cache duration details.

​
SDK implementations

For server-side and mobile implementations, Kameleoon collects data through SDK tracking calls. The SDK evaluates flags locally and sends tracking requests to the Data API in batches. The default flush interval is 1 second. You can also trigger an immediate flush with the flush method.

​
Warehouse and offline conversions

If you import conversions from a data warehouse, Kameleoon accepts events through the Data API. A successful API response confirms that Kameleoon received the payload, not that the events are visible in reporting yet. Warehouse-pulled conversions go through an additional processing step before they appear in results. See Warehouse-delayed conversions for details.

​
Data processing and reporting latency

Two separate timings determine when data becomes available. Events appear in Live events almost immediately after the tracking call fires. They do not appear on the Results page until Kameleoon has processed the completed visit.

​
What “ended visit” means

The Results page reports on visits, not individual events. A visit ends when Kameleoon receives no new activity from the visitor for 30 minutes. Closing a browser tab often causes a visit to end, but closing the tab is not the formal condition. A visit ends based on inactivity, not browser state. Practical implication: If you trigger a goal conversion and then immediately check the Results page, the visit is likely still active and the conversion does not appear yet. Wait until the visit ends, or use Live events to confirm the event fired in real time.

​
Use Live events for QA, not the Results page

Live events is the correct tool for real-time QA. The Results page is for analyzed, visit-based outcomes after experiments have run.

​
Warehouse-delayed conversions

Conversions imported from a data warehouse follow a different processing timeline than web or SDK events. After Kameleoon accepts the payload through the Data API, a separate process merges those events into experiment reporting. Kameleoon doesn’t guarantee same-day visibility for warehouse-imported conversions. Contact your Customer Success Manager for details on expected reporting timelines for your warehouse integration.

​
Further reading