Sessions and conversations

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.

01 Rows in your file, any order

• conv-1001DM34137KMX1703240331000
• conv-1002Do you deliver on Sundays?1703241102000
• conv-1001My order never arrived1703240320000
• conv-1001Sorry about that. Can you share the order number?1703240325000
• conv-1002Yes, from 9am in most areas.1703241109000

›

02 Grouped by session, sorted by time

conv-1001 My order never arrivedSorry about that. Can you share the order number?DM34137KMX

conv-1002 Do you deliver on Sundays?Yes, from 9am in most areas.

›

03 One row of Dimensions per session

sessionreasonresolved

conv-1001deliveryfalse

conv-1002delivery_hourstrue

Dimension names and values are examples.

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 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.

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 sessionIds rather than Dimension rows.