# Sessions and conversations

> How Dimension Labs groups messages into the conversations it enriches, by sessionId, and what that means for your ids.

## A conversation is the unit of enrichment

A conversation is one chat, ticket, call, review or survey response. Its messages share a `sessionId`. Dimension Labs doesn't read rows one at a time. It gathers every message with the same `sessionId`, sorts them by timestamp, and reads the whole conversation at once, customer and agent or bot turns together. It then writes **one set of Dimensions per conversation**.


So:

- The order of rows in your file doesn't matter. Timestamps decide the order.
- A Dimension can use context from anywhere in the conversation: the question a customer answered, or what the bot said just before the customer asked for a human.
- Counting Dimension rows counts conversations, not messages. Counting rows in `transcripts` counts messages.

## sessionId and conversationId

| | `sessionId` | `conversationId` |
|---|---|---|
| What it groups | The messages that are enriched together as one conversation | Every message in a thread, across all participants |
| Use it for | Defining what gets enriched together | Keeping a thread together when the sender changes, for example when a human agent takes over from a bot |

In most data they're the same value. Neither may contain a colon, and neither should be an email address, phone number or name.

When a human agent takes over from a bot in the same chat, keep one `sessionId` and one `conversationId` for the whole chat, the handover included, so it is enriched as one conversation.

## The userId rule

- **Bot conversations:** use the end user's id on every row, including the bot's replies. Mark direction with `incoming`.
- **Conversations with people** (live chat, tickets, calls): the end user's id on every row works the same way, and is what the [toolkit](/transform/toolkit) writes by default. If you want each agent counted as their own user, they can keep their own ids; `conversationId` holds the thread together.
- **No user id at all:** copy the `sessionId` into `userId`.
- **Never personal data:** use your tool's internal ids, not email addresses, phone numbers or names. To link to another system by email, use the same hash of the email on both sides.

## Long-running threads

A thread that stays open over several days, such as an email case, can be split into time segments that are enriched separately under the same `sessionId`, each with its own start time. A survey that arrives days after a support case is a common example. If you see more Dimension rows than conversations, this is the usual reason; see [Numbers look wrong](/troubleshooting/numbers-look-wrong).

:::note
Even with a `sessionId`, a long thread may be split by inactivity or by calendar day; the exact rule isn't published yet. Give every conversation its own explicit `sessionId` (the ticket, chat, call or response id), and when you count conversations, count distinct `sessionId`s rather than Dimension rows.
:::