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.
Ada uses several identifiers to represent different levels of user and conversation context.
conversation_idRepresents a single conversation thread. A new conversation_id is created when:
conversation_id is included in data exports.
chatter_idRepresents the browser or device session for Web Chat. A single chatter_id may map to several different conversation_id values. It appears in the Convos view under Meta variables.
end_user_idA 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 Convos view under Meta variables.
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.
Each identifier represents a different layer of identity:
end_user_id: The end user record created for a given interactionchatter_id: The session-level identity used during that interactionconversation_id: The specific conversation threadEach 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 your system tracks end users by its own stable identifier, the End Users API can associate that identifier with the Ada end user through the external_id field. This is supported for custom channel (Conversations API) integrations: set external_id at creation, and subsequent inbound interactions can look up the same end user by calling GET /v2/end-users/?external_id=<value> to retrieve the existing end_user_id and continue the conversation with a hydrated profile.
end_user_id and chatter_id are separate identifiers but always refer to the same individual.external_id field to recognize returning end users by your own identifier (for example a CRM contact ID) and reuse the same Ada end user across conversations. external_id is unique per AI Agent — one value maps to exactly one end user.chatter_id, while the End Users API references end_user_id).This ensures Ada can track each session independently while giving you flexibility to recognize returning end users at the application level. See Examples for how a custom channel integration can use external_id to recognize returning end users.
Web Chat includes configurable persistence settings that determine how returning visitors are recognized. Persistence is evaluated only when the chat widget loads or refreshes.
Conversations end automatically after long periods of inactivity:
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.
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.
chatter_idconversation_id resets based on session continuity and timeoutsWhen 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.
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.
chatter_id and end_user_id are assigned.conversation_id is created, but the same end_user_id continues.chatter_id and new conversation_id are created.conversation_id is created, but the same end_user_id is used.This pattern applies to custom channel integrations (Conversations API) only. Native chat, social, and voice channels do not support external_id at this time.
CRM_12345).GET /v2/end-users/?external_id=CRM_12345 — a 404 response indicates no Ada end user is mapped to that value yet.POST /v2/end-users/ with external_id: "CRM_12345" and any known profile fields (language, metadata). Ada creates the end user with 201 and stores the mapping.end_user_id.GET /v2/end-users/?external_id=CRM_12345 — this time a 200 response returns the existing end_user_id and profile data.end_user_id. Ada links both conversations to the same end user record.In this scenario, the integration uses its own identifier as the lookup key, and Ada maintains the link between that identifier and the end user across conversations. For the full pattern, see Identify end users with a stable external ID.
conversation_id and other identifiers.
Social messaging