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

# Session Management Overview

> Manage conversation sessions and user tracking in your Rasa Assistant.

<Info>
  **New in 3.16.0**

  Rasa Pro 3.16 introduces session management capabilities including tracking end users across multiple conversations through the `user_id` field,
  explicit session lifecycle events, per-session identity via `session_id`, and a proactive inactivity timer with configurable persistence.
</Info>

Rasa provides comprehensive session management capabilities that allow you to:

* Track individual conversations through unique `sender_id` identifiers.
* Associate multiple conversations with a single end user using `user_id`.
* Retrieve and analyze user behavior across different conversations.
* Manage session lifecycle and state persistence.
* Identify sessions uniquely with an automatically generated `session_id`.
* Configure inactivity timeouts that fire proactively and persist across server restarts.

## Key Concepts

**What is a conversation?**
A conversation is a contained stream of events between a user and the agent (messages, actions, slot updates, flow steps, etc.). It can be paused, resumed, and optionally ended permanently. Once ended with a `SessionEnded` event, it cannot be reopened.

**What is a session?**
A session is a bounded slice of a conversation — usually one continuous interaction window (like a single chat visit). A conversation can contain multiple sessions over its lifetime.

**What is the difference between a new session and a new conversation?**
A new conversation is a user-facing concept — it's what users expect when they click "New chat" or "Start over": a fresh thread in the UI with no previous context.

A new session is a Rasa system concept — it's how Rasa separates interaction windows for the same user (for example after a timeout). A new session may reset the assistant's state depending on your configuration, but it still belongs to the same end user.

In practice: "new conversation" is the experience you design, while "new session" is the boundary Rasa uses under the hood. They often map 1:1 but don't have to.

## Understanding Session Identifiers

Rasa uses three types of identifiers to manage conversations:

### Conversation ID (`sender_id`)

The `sender_id` uniquely identifies a single conversation. Each conversation between a user and your assistant has its own `sender_id`, which remains constant throughout that specific conversation.

### User ID (`user_id`)

The `user_id` associates multiple conversations with a single end user. This enables you to:

* Track user behavior across different conversations.
* Retrieve conversation history for a specific user.
* Analyze patterns and preferences across a user's interactions.

The `user_id` is optional and must be provided by your client application.

### Session ID (`session_id`)

Every session has a unique `session_id` (UUID v4) that is automatically generated and stamped on every event's metadata for the lifetime of that session.

Unlike `sender_id` and `user_id`, `session_id` requires no configuration — it is automatic.

## Session Lifecycle

A conversation session begins when:

1. A `SessionStarted` event is triggered (either automatically or manually).
2. A message is received from a user with a new `sender_id`.
3. A `UserUttered` or `ConversationResumed` event is received on an inactive tracker.

A conversation session ends when:

1. A session timer fires due to inactivity and a `ConversationInactive` event is emitted.
2. A `SessionEnded` event is emitted.

Each conversation is stored independently in the tracker store, identified by its unique `sender_id`. Multiple conversations can be associated with the same `user_id`.

## Backward Compatibility

1. Existing conversations without `user_id` continue to work seamlessly:

* Trackers without `user_id` will have `user_id=None`.
* Migration of existing data is not required, but recommended if you want to retrieve conversation trackers by user\_id for past conversations prior to the upgrade.
* All tracker stores support both conversations with and without `user_id`.

2. Existing conversations with events that do not have `session_id` in their metadata continue to work seamlessly:

* Old events will not have `session_id` in their metadata.
* New events will have `session_id` in their metadata, and the tracker will have a `current_session_id` field that reflects the active session.
* Existing trackers will have a mix of events with and without `session_id`.

3. If you have a custom tracker store implementation, take a look at the [Rasa Pro Migration Guide](/docs/reference/changelogs/rasa-pro-migration-guide#support-for-user_id-in-dialoguestatetracker) for details on what changes are required to adopt the new session management feature.


## Related topics

- [PII Management Overview](/docs/reference/config/pii-management/overview.md)
- [Overview](/docs/reference/config/agents/overview-agents.md)
- [Policy Overview](/docs/reference/config/policies/overview.md)
- [Configuring PII Management](/docs/reference/config/pii-management/configuring-pii-management.md)
- [PII Management Prerequisites](/docs/reference/config/pii-management/prerequisites.md)