Visitor data
The term "visitor data" refers to data about a visitor that isn’t directly related to Unblu but may be required by some other system. This could be something like information about where exactly a visitor started the conversation that’s needed by a backend system to decide how to proceed. Conversely, it might be the outcome of some interaction with a backend system that influences the frontend in some way.
Visitor data vs conversation metadata
At first glance, visitor data appears to have a similar purpose to conversation metadata. There is, however, an important difference between the two.
Conversation metadata is only available on the internal entry path, so it can include internal information. Visitor data, on the other hand, is transmitted to visitors' devices. It must therefore only contain information that may shared with other parties.
Working with visitor data
How you work with visitor data is entirely up to you, but experience has shown that some approaches are better than others.
While you can in principle write visitor data however best suits your needs, using a structured format such as JSON has significant long-term benefits and makes it easier to adapt to changing requirements.
Aim to structure your visitor data in such a way that different aspects of the data appear as separate (structured) values of your JSON object. Try to limit the piece of visitor data that different systems operate on to a single such value.
To illustrate these points, suppose your visitor data looks like this:
{
"crm_integration": {
"customer_segment": "corporate",
"talking_points": [
"loans", "forex", "export_finance"
],
"campaigns": [
"forex", "cash_mgmt"
]
},
"digital_signature": {
"digital_signature_waiver": true
}
}Your backend customer relationship management (CRM) software should only read and write information in the "crm_integration" object, and your digital signature management system should only read and write informaiton in the "digital_signature" object.
Based on the "campaigns", your client chats with one of your bots about cash management and arranges a meeting with one of your specialists on the topic. Your frontend therefore updates the visitor data:
{
"crm_integration": {
"customer_segment": "corporate",
"talking_points": [
"loans", "forex", "export_finance"
],
"campaigns": [
"forex", "cash_mgmt"
]
},
"digital_signature": {
"digital_signature_waiver": true
},
"campaign": {
"campaign_name": "cash_mgmt",
"completed": true,
"documents_signed": false,
"meeting_arranged": true
}
}Now your campaign tracking system logs the outcome of the campaign conversation and removes the "campaign" object. Your CRM updates the "crm_integration" object, removing the campaign it ran and adding information about the planned follow-up meeting. As a result, the client’s visitor data now looks like this:
{
"crm_integration": {
"customer_segment": "corporate",
"talking_points": [
"loans", "forex", "export_finance"
],
"campaigns": [
"forex"
],
"follow_up_meetings": [
"cash_mgmt"
]
},
"digital_signature": {
"digital_signature_waiver": true
},
}| Although systems should if possible only operate on a single value of the visitor data, when they do so, they must read and write the entire visitor data object. If they don’t, visitor data that’s relevant to other systems may be lost. |