Other features

Personalization data: Collection and use

Personalization in Ada is about using what you know about each user—not about the AI Agent’s personality. This topic explains how the AI Agent collects and uses information like a user’s name, plan, or region to decide what content they see and help the conversation feel more useful and relevant.

For example, your AI Agent can greet users by name as soon as they open the chat. This is possible when the user’s profile is enriched with data from your systems, using the End Users API, Email Conversations API, or Chat SDKs. Details like membership level or support plan can be added to the user profile, and Ada can use that information to show exclusive offers only to “Gold” members, provide priority support to users with a premium plan, or restrict access to certain Knowledge articles. This type of gating can be applied to Knowledge, Coaching, Actions, Processes, and Handoffs—ensuring everyone gets access to exactly what they need.

If you don’t have information up front, Ada can collect it during the conversation using Greetings. You can capture session-specific details—like an account number or recent order—and reuse them later in the same chat to personalize responses. You can also update persistent user profile data during the conversation by using a Request block to send information to the End Users API, making those updates immediately available for system-level rules and future sessions.

Personal data—such as a customer’s full name, email address, phone number, unique identifiers, and other details defined under privacy laws—is carefully protected. During an active contract, unmodified personal data is retained for up to two years to support service delivery and allow customers to review conversations. Customers may export this data if longer retention is needed, and redaction can be applied based on their settings. After a contract ends, data is retained for 90 days for retrieval, after which it is permanently deleted. Only anonymized data—where all personal identifiers are removed and individuals cannot be re-identified—is retained by Ada to improve its services. Robust safeguards, including a Zero Data Retention policy for LLM providers, help prevent unintended data storage. For more details, customers can contact the Trust Center, Privacy Team, DPO, or their account manager.

Once personalization data is collected, it’s applied at different stages of the conversation:

  • Before the AI Agent is invoked: System-level logic uses the data to gate access, control flow, or route users based on predefined rules.
  • Once the AI Agent is active: The data is passed as context and used at the AI Agent level during the model’s inference step—the point where it predicts the next response based on input and context—to generate personalized replies in real time.

This layered approach supports both deterministic control and dynamic, context-aware behavior within a single conversation.

Data sources

There are several ways to bring personalization data into Ada. The right approach depends on where your user data lives and when it’s available—either before the conversation starts or while it is underway. These methods are not mutually exclusive and can be used together to create a richer, more tailored experience.

End Users API

If your backend system already stores information about your users—such as names, locations, or subscription tiers—you can use the End Users API to sync that data into Ada.

For example, imagine a user logs into your app and begins a conversation with your AI Agent. Ada automatically creates a user profile at that moment and fires a webhook event notifying your system of the new profile. Your system can then send a PATCH request to the End Users API, updating the user’s profile with metadata.

For example:

"metadata": {
	"plan": "premium",
	"region": "EU",
}

These values are saved as variables in the user’s profile and are immediately available for the AI Agent to access, respond to, and adapt the conversation accordingly, or to determine content availability through rules in Knowledge, Coaching, Actions, Processes, and Handoffs.

This approach is ideal when you already have a reliable user identifier (like an email or internal ID) and want to enrich the profile. It also works across all supported channels.

Chat SDKs

For web or app-based chat experiences, personalization can be handled directly using the Chat SDKs.

Let’s say a user logs into your website and opens the Ada Chat. If their name, email, or customer ID is already available in your app, you can pass that data into the chat when it loads using metaFields. Alternatively, if the user logs in after the chat has already loaded—common in single-page applications—you can update their profile using setMetaFields. In both cases, this data is stored in the user’s profile as variables.

These values become available immediately and can be used to personalize replies (e.g., “Hi [name]”) or to determine content availability through rules in Knowledge, Coaching, Actions, Processes, and Handoffs. This method is limited to chat, but works well when the AI Agent already has access to user-specific data from the hosting site or app.

Email Conversations API

In asynchronous support workflows, Ada can receive personalization data as part of an inbound email conversation using the Email Conversations API.

Imagine a support request comes through a contact form. Your system forwards the request to Ada via a POST call to the Email Conversations API, including the user’s name, email address, and any relevant metadata—such as ticket_id or product_tier. When this call is received, Ada automatically creates a user profile, and the metadata is stored as variables.

Because this data is attached to the user profile up front, it can be used immediately in the conversation and for content gating, even before the user replies. Variables in the user’s profile are available right away for personalization or to determine content availability through rules in Knowledge, Coaching, Actions, Processes, and Handoffs. This method is specific to the Email channel but is highly effective when profile data is already known at the start.

AI Agent Greetings

When user data isn’t known ahead of time, you can collect it during the conversation—starting with a Greeting. For example, your AI Agent might open a chat by asking, “What’s your name?” or “What plan are you on?” using Capture blocks. These responses are saved as variables and can be reused later in the conversation for a more personalized experience.

In addition to collecting session-specific data, Ada also allows you to update a user’s persistent profile (profile.metadata) directly from the conversation. To do this, you can configure a Request block to send a PATCH request to the End Users API. The Request block must target the specific user’s endpoint URL (https://{bothandle}.ada.support/api/v2/end_users/{end_user_id}), with the end_user_id dynamically inserted. An Authorization header is required, passing the API key as a Token. In the body of the request, the payload must be structured under a profile object, containing the key-value pairs you want to update.

For example, if the user’s name and plan are captured during the conversation, the Request block could send the following:

{
  "profile": {
    "name": "Jane Doe",
    "plan": "premium"
  }
}

This approach allows you to immediately enrich the user’s profile with newly collected information, making it available for future personalization and access control.

Data-driven behavior

Ada supports two distinct layers of personalization: system-level and AI Agent-level. Both can be used to tailor the experience, but they operate differently and serve different purposes—especially when it comes to controlling access to resources.

System-level personalization

System-level personalization is deterministic and relies on variables stored in the user’s profile (profile.metadata) to evaluate availability rules. These rules are applied early—before the AI Agent selects content or executes a process—and are ideal for gating access to resources or targeting specific user segments based on known attributes.

This approach is used to control availability across key resources in Ada, including Knowledge, Coaching, Actions, Processes, and Handoffs.

For example, access to onboarding articles might be restricted to users on an enterprise plan, or a specific handoff could be limited to users in a certain region. Because these rules are based on profile-level variables, they are predictable and consistently applied. Variables used for system-level rules must be available to Ada at the start of the conversation. They can come from:

Variables collected dynamically during the conversation—such as those returned from an Action—cannot be used in system-level availability rules. System-level logic is evaluated before any Action runs, and these runtime values are not stored in profile.metadata.

AI Agent-level personalization

AI Agent-level personalization is dynamic. It allows the AI Agent to personalize its responses based on variables that are either:

  • Already present in the user’s profile (profile.metadata), or
  • Collected mid-conversation, through Capture blocks or Actions that fetch data from external systems

This layer doesn’t control access to content, but it allows the AI Agent to adapt the conversation in real time. For example, if the AI Agent fetches account status using an Action, it can adjust how it responds or what it says next based on that value.

Dynamic personalization enables the AI Agent to:

  • Reference user-specific details in its replies (e.g., name, plan, language)
  • Respond appropriately as new information becomes available

However, because the results of Actions are not stored in profile.metadata, they cannot be used to determine access to Knowledge, Coaching, Actions, Processes, and Handoffs.

Actions themselves can still be made conditionally available based on system-level variables. This means the decision to show or withhold an Action can rely on profile data—just not on any values returned from Actions during the session.