Engagement attributes (EAs) passed by the brand can include important information that the agent should consider in real time, while engaging with customers. Unauthenticated EAs give brands the ability to provide agents with real-time information about the visitor in order to improve their efficiency and service quality in messaging conversations as well as in chat. For example, they can provide agents with an order ID for when visitors inquire about the terms and conditions of their order, or provide agents with customer information during a conversation with a registered visitor.
This feature will display unauthenticated EAs passed in a messaging conversation within the Agent Workspace. Any EAs passed 12 hours before the conversation has started, and 12 hours after a conversation has ended, will be attributed to the conversation.
EAs will be presented in the Agent Workspace in several areas:
-
Consumer Info widget - each EA will be presented in its own section, much like for chat conversations today. They will be available in both Open Conversations and All Conversations, as well as in the Conversation History widget.
-
All Conversations view - users will be able to search unauthenticated EAs in the All Conversations table, as part of the EAs search.
The table below explains which EAs should be collected and presented in LE UI.
| Category | Engagement Attribute | Description | When is it sent? | How many times is it expected to be sent |
|---|---|---|---|---|
| Visitor Info | Marketing source | Used to obtain information about the marketing source of the visitors, e.g. which channel or campaign drove visitors to the website | Usually, when the page loads. | This information should be sent per session |
| Customer info | Used to collect information about a registered visitor and their unique identifier. | When information about the visitor is available. The data can come from different sources and may be passed asynchronously. | This information should be sent per session. Expected to be sent once per session, but usually, as data comes from different sources, will be sent more than once. | |
| Personal info | Used to collect personal information about visitors | When information about the visitor is available. The data can come from different sources and may be passed asynchronously. | This information should be sent per session and not per page. Expected to be sent once per session, but usually, as data comes from different sources, will be sent more than once. | |
| Ecommerce Info | Cart update | Used to get the status of the visitor’s shopping cart. | When the visitor’s shopping cart is updated. | This information usually will be sent more than once per session. |
| Viewed product | Used to track a product or service that interests visitors. Each product is described by Name, Category, SKU, stock status and quantity in stock | When a visitor views a product. | This information will usually be sent more than once per session. | |
| Transaction | Used to track any money transaction including the items themselves and their details. | Upon a transaction. | This information usually will be sent once per session, depending on tracked transactions. | |
| Visitor Journey | Lead | Tracking lead information will understand what visitors are interested in and where they are in the funnel. Tracking the value of the lead will appear in revenue reports, in order to measure the monetary value of campaigns. | Upon a lead generation. | This information usually will be sent once per session, depending on generated leads. |
| Service activity | Used to measure service activities, for example, ordering a checkbook, submitting an application, or requesting a mortgage. | Upon a service activity | This information usually won’t be sent more than a few times per session, depending on the service activities. | |
| Visitor error | Used to collect information about errors that visitors experience. All errors are aggregated in a list during the session until resolved. | Upon a visitor encountering an error. | This information usually won’t be sent more than a few times per session, depending on the number of tracked errors the visitor encounter. | |
| Section | Section Engagement Attributes allow to describe specific webpages by embedding code on the webpage. Use sections to determine the appropriate Location for engaging with visitors, or to display where those visitors are browsing. | Upon page load | This information is expected to be sent once per page and thus multiple per session. | |
| Searched content | Getting information about content searched by visitors on the website. For example: searching for FAQs about how to reset password. | Not documented | Not documented |
Note: If you pass the customerId parameter of the Customer Info SDE, Conversational Cloud will treat the conversation as authenticated. Since Messaging conversations are unauthenticated in the context of SDEs, do not pass this parameter. If you do, our server will look for other prerequisites of authenticated conversations and the call will fail.
Monitored Data
The following monitored data will be added to the Consumer Info widget under Consumer Info section (same as in chat)
-
Country
-
City
-
ISP
-
Organization
-
Referrer (start page)
-
IP Address (don't forget to take IP masking into consideration)
The monitored data will be collected from the first session. Geo location will be collected from when the conversation first originated, and will not update if the user changes their location during an open conversation.
Both unauthenticated EAs and monitored data will be available to view in the Agent Widget SDK, and through the Messaging Interactions API.
Limitations
-
EAs submitted more than 12 hours before conversation started will not be displayed
-
EAs submitted more than 12 hours after conversation ended will not be displayed
-
This includes resuming a conversation — if resume was done in the 12 hour time frame from conversation close time, the relevant EAs will be shown
-
Unauthenticated conversations started from different browsers will be treated as separate conversations and will have their own EAs
-
In an authenticated messaging flow, consumer info EAs must be sent after the login process in order to create a correlation of the user between devices and browsers
-
EAs submitted in a messaging conversation will be available for search in All Conversations up two hours later. EAs may appear before, but might not be the most current ones. Avg. estimated time for final EAs to appear would be ~30 min.
Submitting EAs
In Messaging, the EAs are cross-device and linked to a specific conversation. There is no need to report the EAs separately on each page anew but only once per conversation. It is highly recommended to report the EAs at the beginning of the engagement with the consumer (as soon as the info exists, report on it). EAs can be submitted from multiple sources such as the Monitoring API, or through more Traditional Channels.
In case there is any additional information about the user during the interaction, you may send the same EAs again in order to update the existing data with the new information.
Availablity of EAs
-
All Reported EAs within 12 hours before the Conversation started, while the conversation is open, and 12 hours after the conversation has closed will be available.
-
EAs will be reported with the specific consumer ID or EAs will be assigned to the "visitor" (in web messaging) that started the conversation.
-
EAs will be available through API calls in a matter of seconds.
-
EAs will be searchable in the UI up to 2 hours since they were received.
Sending an EA multiple times during a session
Consider the following implementation on a customer page:
| Page | property1 Value | property2 Value | property3 Value |
|---|---|---|---|
| Page A | a1 | a2 | [Not supplied] |
| Page B | b1 | [Not supplied] | b3 |
A visitor has been to page A, then moved to page B. How will the Engagement attributes be saved? The behavior depends on the Engagement Attribute (EA) type. Note that, unlike the best practices defined for chat, the only two behaviors we used in Messaging is Append and Replace. Which EA should use which behavior in Messaging is covered in the table below.
| Behavior | Behavior description | Engagement attributes | Example Output |
|---|---|---|---|
| Append New Item | Appends new item each time EA is sent | Viewed Product (prodView) Visitor Error (error) Transaction (purchase) Lead Searched Content |
Product 1: property1: a1 property2: a2 Product 2: property1: b1 property3: b3 |
| Replace Item | Updates existing info, does not maintain previous values of attributes that were not supplied in latest update | Cart update, Personal Info (personal) Customer Info (ctmrinfo) Marketing Info (mrktInfo) Service Activity (service) |
Cart: property1: b1 property3: b3 |
- Note: As opposed to Chat, updated behavior does not apply to the data, and replace behavior will be used instead. It's recommended to always pass the full data in the engagement attribute.
Limitation
- In authenticated messaging flow, consumer info EAs must be sent after the login process in order to create a correlation of the user between devices and browsers