> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Kameleoon counts sessions and visitors

> Understand the difference between a session and a visitor in Kameleoon, and how Kameleoon identifies and tracks each across web and server-side experimentation.

## Visitors and sessions

In Kameleoon, a **visitor** is a unique person (or device), and a **session** is one continuous period of activity from that visitor. One visitor can have many sessions over time.

The distinction matters when you read experiment results: visitor counts tell you how many distinct people saw a variation, while session counts tell you how many times those people were active while the experiment was running.

## What counts as a session

Kameleoon uses a 30-minute inactivity window to define the boundary between sessions. When a visitor has no activity for more than 30 minutes, their next action starts a new session.

**Example:** A visitor views a product page at 10:00, then returns at 10:20 to view a second page—both actions belong to the same session. If the same visitor returns at 10:35 instead, that second visit starts a new session.

<Note>
  The default 30-minute session duration is configurable for server-side Feature Experimentation SDKs. Contact your Customer Success Manager or refer to the [technical considerations reference](/developer-docs/feature-experimentation/technical-reference/technical-considerations#server-side-sdks) for details.
</Note>

## How Kameleoon identifies visitors

### Web Experimentation

On web, Kameleoon identifies each visitor using a unique visitor code stored as a cookie in their browser. When a visitor arrives at your site:

* If the cookie already exists, Kameleoon recognizes them as a returning visitor and maintains continuity with their previous sessions.
* If no cookie exists, Kameleoon generates a new visitor code and stores it. The cookie remains active for 365 days.

### Feature Experimentation

For server-side SDK integrations, you pass the visitor identifier (such as a user ID or session token) directly when calling SDK methods. Kameleoon keeps visitor and session data in memory for the duration of the active session (30 minutes of inactivity by default).

The SDK automatically records and sends tracking data to Kameleoon when you use tracking-enabled SDK methods. Kameleoon batches data on a short, configurable interval, so you typically don't need to take manual action.

<Note>
  For a full breakdown of which SDK method calls trigger tracking requests, see the [Feature Experimentation SDK FAQ](/developer-docs/feature-experimentation/technical-reference/faq-global#when-does-the-sdk-send-a-tracking-request-for-analytics).
</Note>

## Hybrid experimentation

When you run experiments that span both web and server-side environments, Kameleoon can recognize the same visitor in both. The visitor code from the browser cookie is shared with the server-side SDK, so the same person is counted consistently regardless of which side of your application they interact with. See [Hybrid experimentation](/developer-docs/feature-experimentation/get-started/hybrid-experimentation) for setup details.

## Further reading

* [Data collection and reporting](/user-manual/experiment-analytics/analyze-results/data-and-metrics/data-collection-and-reporting)
* [How Kameleoon counts conversions](/user-manual/experiment-analytics/analyze-results/data-and-metrics/how-kameleoon-counts-conversions)
* [How Kameleoon tracks and counts unique users](/user-manual/account-and-team-management/organization-settings/how-kameleoon-tracks-and-counts-unique-users)