When creating custom metrics it is useful to understand our Logical Model. Logical Model is designed to be easy to understand without reading too much of a documentation.
Engagements
Engagements data set is the core of our Logical Model. When building metrics you should consider what engagements you want to include in your metrics. The following simple example counts all items in the Engagements data set:
SELECT COUNT(Engagement)The above metric is technically correct. However it is extremely unlikely it would be useful for any business need. Engagements data set contains a lot of items you might want to exclude from counting depending on your use case.
Engagement Type
IN most cases you will be filtering for a specific type of an Engagements. Otherwise you will often count apples and oranges. Different types of Engagements have a very different meaning described in detail in this dedicated article.
SELECT COUNT(Engagements)
WHERE Type = "Agent"The above metric counts only Engagements where an Agent was engaged in a Conversation with a customer.
Engagements that have Type equal to "Technical" are in the data set to ensure that the Logical Model behaves as expected for some use cases and you should always exclude them when creating metrics.
Engagement Status
In many cases you will be reporting on completed Engagements.
SELECT COUNT(Engagements)
WHERE Type = "Agent" AND Status = "Completed"The above metric counts only Engagements where an Agent was engaged in a Conversation with a Customer and the Engagement is over which means the agent is not longer engaged with the customer and the wrap up is over if there was any.
Engagements that are reported as in progress were in progress when the data was loaded. At the time when you report of them they may already be completed.
Conversations
Conversations add extra complexity to analytics. Conversation is a set of Engagements. Engagements that belong to the same Conversation have the same Conversation attribute value. There is not a separate Data Set that would represent the conversations themselves. Because metrics are working on the granular Engagement level you have to consider how filters, segmentations and aggregations actually work.
| Conversation | Engagement | Direction | Queue |
|---|---|---|---|
| Co1 | En1 | Inbound | Queue A |
| Co1 | En2 | Inbound | Queue A |
| Co1 | En3 | Inbound | Queue B |
When you do simple report on the Engagements data set above with metrics counting Conversations and metric counting Engagements you will get different results.
| Queue | SELECT COUNT(Engagement) | SELECT COUNT(Conversation) |
|---|---|---|
| Queue A | 2 | 1 |
| Queue B | 1 | 1 |
| Sum | 3 | 2 |
| Rollup | 3 | 1 |
The second column counting Engagements is easy to understand. We have in total 3 engagements (3 rows in the table) with IDs En1, En2 and En3. Two of the Engagements are in Queue A and one Engagement is in Queue B. Both Sum and Rollup rows show that there are in total 3 Engagements as expected.
The third columns counting Conversations is slightly more complex. There is only 1 Conversation with ID Co1 in the data set. The Conversation goes through multiple queues. It appears twice (in Engagements En1 and En2) in the Queue A and once in the Queue B (Engagement En3).
Start Time and End Time
Salted CX enables you to report either based on time when an Engagement started or when the Engagement ended.
Start Time is available for every Engagement. Thus Start Time enables you to report on Engagements that are were in progress during the last data load. Start Time is great to understand when customers started to reach you which is great to
End Time is available only after an Engagement is completed. It does not have to be available for engagements.
Internal Conversations
Internal conversations require extra attention to interpret them properly. Our Logical Model enables only one agent to be associated with an engagement. This is to ensure the data are easy to use for reporting. In internal conversations agents talk to other agents.
In internal conversations the agent starting the conversation is represented by Customer data set item with Type = Agent . The receiving agents who handle the conversation are stored in regular Agent data set items.
Agents
Salted CX represents even bots and other services as agents. If you want to focus specifically on people use Agent ⏵ Type attribute in filters.
Technical Items in Data Sets
Each data set and each entity contain one item that as its primary identifier equal to 00000000-0000-0000-0000-000000000000. These items are there for technical purposes that maintains referential integrity. All other values facts, attributes and labels for these items are empty.
No Many-to-Many Relationships
Logical Model intentionally does not support many-to-many relationships. This is motivated by performance considerations and also the simplicity of reporting and writing metrics. Many-to-many relationships make easpecially attribution of any metrics very difficult.