Conversation identifiers and persistence

Ada assigns identifiers to help track users and Conversations across Channels. These identifiers determine when a conversation begins and ends, how messages are grouped, and whether a returning user is recognized or treated as new. Persistence settings, user behavior, and channel differences all influence how these identifiers change over time.

This topic explains how conversation and user identifiers relate to each other, how they are assigned, and how persistence governs session continuity across Chat, Email, Social, and Voice interactions. It also includes examples that illustrate how identifiers behave in different scenarios.

To learn how variables are stored and reused during conversations, see this section.

Conversation and user identifiers

Ada uses several identifiers to represent different levels of user and conversation context.

`conversation_id`

Represents a single conversation thread. A new conversation_id is created when:

a new Web Chat session begins
a previous conversation times out
the user manually ends chat (depending on persistence)
an email reply arrives outside the continuation window
a social platform creates a new messaging thread
a call begins in a voice channel

conversation_id is included in data exports.

`chatter_id`

Represents the browser or device session for Web Chat. A single chatter_id may map to several different conversation_id values. It appears in the Conversations view under Meta variables.

`end_user_id`

A persistent identifier that represents a user across multiple conversations and channels. It remains stable if the user can be recognized based on persistence rules or channel metadata. This identifier also appears in the Conversations view under Meta variables.

Sunshine Conversations identifiers

For social channels integrated through Sunshine Conversations, your AI Agent may receive external identifiers from the messaging platform. These can include:

sunshine_user_id: The user identifier provided by the external platform.
sunshine_conversation_id: The thread or conversation identifier provided by the external platform.

These values appear when Sunshine Conversations is enabled. They reflect identifiers used by the external platform and can help correlate your Agent’s conversations with activity occurring on that platform.

How identifiers relate

Each identifier represents a different layer of identity:

end_user_id: The end user record created for a given interaction
chatter_id: The session-level identity used during that interaction
conversation_id: The specific conversation thread

Each end_user_id corresponds to exactly one chatter_id, and Ada treats them as a 1:1 representation of the same underlying user.

However, when you use the End Users API, your system can link or unify multiple end users. For example, if the same person starts conversations from different devices or at different times, Ada will create new chatter_id/end_user_id pairs for each session. Your system can then recognize them as the same person—such as matching based on email—and merge them by assigning a shared external_id.

What that means

Inside Ada: end_user_id and chatter_id are separate identifiers but always refer to the same individual.
Inside your system: You may choose to link multiple Ada users together under one customer profile by setting the same external_id.
They are not interchangeable and appear in different contexts (e.g., embed exposes chatter_id, while the End Users API references end_user_id).

This ensures Ada can track each session independently while giving you flexibility to unify identities at the application level. The example below shows how multiple sessions from the same person can be unified in your system using the End Users API.

Persistence and session continuity

Web Chat includes configurable persistence settings that determine how returning visitors are recognized. Persistence is evaluated only when the chat widget loads or refreshes.

Effects of persistence

Persistence setting	Action	Result	Notes
Forget After Tab Close	Close and reopen tab	New `conversation_id`, new `chatter_id`, new `end_user_id`	Each tab is treated as its own session
Forget After Reload	Refresh the page	New `conversation_id`, new `chatter_id`, new `end_user_id`
Forget After `X` time	Refresh after `X` time	New `conversation_id`, new `chatter_id`, new `end_user_id`	Users are not forced out mid-session
Any Forget setting	User ends chat	New `conversation_id`, same `chatter_id`, same `end_user_id`	Variable reuse depends on session continuity
Never Forget	24 hours pass with no user action	New `conversation_id`, same `chatter_id`, same `end_user_id`
Any	Cookies cleared	New `conversation_id`, new `chatter_id`, new `end_user_id`	Clearing storage resets identity
Any	Email or ticket handoff	New `conversation_id`, same `chatter_id`, same `end_user_id`
Embed:`reset()`	`reset()` triggered	New `chatter_id`, new `end_user_id`	Assigned even during an active conversation
Embed: `deleteHistory()`	`deleteHistory()` then refresh	New `chatter_id`, new `end_user_id`
Embed: `privateMode`	Refresh in `privateMode`	New `conversation_id`, new `chatter_id`, new `end_user_id`	Equivalent to Forget After Reload

Conversation timeouts

Conversations end automatically after long periods of inactivity:

Web Chat and most messaging channels: about 24 hours
Email: about 72 hours

After timeout, the next message creates a new conversation_id.

Ada also generates a new chatter_id/end_user_id pair for the session. If you want to link session-level identities across devices or time, you can do so using the End Users API. See How identifiers relate for a full explanation of how these values work together.

Cross-channel behavior

Identifiers and session continuity behave differently depending on the Channel where the conversation occurs. Each channel has its own rules for how users are recognized, how conversations are grouped, and when new sessions begin. The sections below outline how identity and conversation behavior work across channels.

Web Chat

Persistence determines session continuity
Refreshing, closing tabs, and clearing cookies affect chatter_id
conversation_id resets based on session continuity and timeouts

Email

Identity is based on email address
Time windows determine conversation grouping

Voice

Identity is determined by caller phone number
Each call typically creates a new conversation

Shared devices

When multiple users share a device, identity should be reset to avoid cross-user data exposure. In Web Chat implementations using the Chat SDK (embed), call reset() on logout to generate a new chatter_id and ensure variables and prior conversation context are not reused.

Examples

Use these examples to see how conversation identifiers and persistence behave in real situations. Each scenario highlights how user actions, browser behavior, or channel rules influence whether Ada creates a new conversation or reuses an existing identity.

Returning user in Web Chat with 'Never Forget'

End user starts chatting with the AI Agent.
chatter_id and end_user_id are assigned.
End user returns later in the same browser.
A new conversation_id is created, but the same end_user_id continues.
Persisted variables associated with identity may still be available.

Page refresh with 'Forget After Reload'

End user begins a Web Chat session.
They refresh the page.
A new chatter_id and new conversation_id are created.
The user appears as new.

Email reply outside continuation window

End user emails your support address.
Ada responds, creating a conversation.
User replies after several days.
A new conversation_id is created, but the same end_user_id is used.

Shared device logout

Person A interacts with the AI Agent through Web Chat.
They log out of your application.
reset() is called.
Person B logs in.
A new chatter_id ensures their sessions remain distinct.

Using the End Users API to unify identities

An end user chats from their laptop. Ada creates chatter_1/end_user_id_1 and starts conversation_id_1.
The same user chats a week later from their phone. Ada creates chatter_2/end_user_id_2 and starts conversation_id_2.
Your webhook receives both end-user-created events.
Your system notices both records share the same email (e.g., john@example.com) and determines they represent the same customer.
You assign both Ada profiles the same external_id (e.g., CRM_12345), effectively merging those records in your system.

In this scenario, Ada keeps separate session identifiers, but your system unifies them under one end-user record using external_id.