Single Customer View - Contact Merging/Identity Management

Web Messaging
1

Hello,

I am having some trouble with associating a Predictive Engagement session to an external contact. My problem is I am seeing "Unknown" in the live PE View even after I have associated the messaging conversation to an external contact, and cannot figure out how I can associate the PE session to the contact properly.

Here is my setup:

I am using a web messaging widget, configured with the Predictive Engagement piece turned on. I am able to confirm that this is working, because I can see in my Predictive Engagement "LIVE" view. However, all of my active sessions are showing up as unknown. See below:

image
image865×61 3.92 KB

I am using /api/v2/externalcontacts/conversations/{conversationId} in my messaging flow to associate the interaction to my external contact. This works great as well - I am taking the messaging session ID, the media type and the conversation ID to do this. However, it does NOT change the session association, in the PE Live view to my External Contact that I've associated the conversation with. This kind of makes sense, because I'm telling the system "associate" the messaging session to that contact.

But it also DOESN'T make sense because the participant that owns the messaging session that I am using when i associate the conversation to the external contact has the following attributes attached to it:

"journeyContext": {
"customer": {
"id": "c3e2f3c5-f182-4ea6-af9f-41ccb08fcb8e",
"idType": "cookie"
},
"customerSession": {
"id": "9061fb16-a231-4568-a147-82ac4f3d1c21",
"type": "web"
}

So, I would expect that when I associate the conversation to the external contact, the system also reads "oh hey, this journeySession is also associated to this external Contact. But, this is not the case.

I also tried using the new "Merge" API (/api/v2/externalcontacts/merge/contacts) to merge the ephemeral contact to my curated contact, and when I use this endpoint, I am able to see the external contact associated with the session in the PE Live view. However, this has it's own challenges - there is a limit to the amount of merges I can do (25).
image

Does anyone have any tips or comments on how I can associate a live PE session with an external contact? I feel like I need a PATCH /api/v2/journey/sessions/{sessionId} endpoint where I can update the externalContact on the session itself.

2

Hi, thanks for raising this. Question, just to confirm: how are you capturing the end-user's Name ("John Wick")? Are you updating External Contacts via Data Actions / API from within your Inbound Message Flow?

3

Hi Angelo,

Thanks for sending back so quickly! I am capturing a phone number, which is the identifier i am using to look up the external contact in my inbound flow. In order to get this to work i am collecting the phone number, using the native search toolstep to find my "curated" contact that I want to merge the ephemeral with, finding the ephemeral contact ID through the API and then merging, all through the API.

image
image516×637 28.4 KB

This solves my problem, because it updates the PE Live View, and also the remote name problem when it comes into the agent (i.e it no longer shows as "no name"). However, I run into the limit of the mergeSet on the canonical record. Which, the only work around is to blow away the External Contact and start fresh.

I could not find a different way to associate the PE session to the External Contact. How would you recommend I do this?

1 Like
4

Hi, Angelo.

Any thoughts on this?

5

We are reviewing this internally, thanks for the patience.

6

Thank you, Angelo!

7

Hello,

First, let me address the specific behavior you are seeing.

When you relink a web messaging conversation to a different contact, the web browsing session from which the conversation started is not automatically relinked to the new contact. It remains linked to the original, ephemeral contact. There is no way to re-associate the web session to a different external contact at this time. We recognize that this is not ideal and are considering how we might improve the situation.

Now, I will dig into how the platform expects you to handle your situation.

In your situation, when you open a browser and browse your website, that creates a web session and associates it to an ephemeral contact because there is no other information available at session-start time other than a cookieId/web-client-id. When you start a web messaging conversation, it gets associated to that same ephemeral contact.

If the purpose of your flow is to look up a contact that already exists that matches the customer on the other end of this web messaging conversation, then when it finds a match, it should merge the ephemeral contact on that conversation with the curated contact that it found. The purpose of merging is to state that two contacts represent the same person. Merging two contacts will join their journeys together (web sessions and conversations) for display in the Genesys Cloud UI. Since these two contacts now represent the same person, the name you see on the web browsing session presented in the Live Now UI updates a well.

If the flow does not find a matching curated contact, it could choose to promote the contact on the web messaging interaction to add it to your curated set. Then an agent could collect information about the customer and enrich the contact while handling the interaction. Alternatively, you could let the agent decide whether to promote the contact or not.

The relink API operation is only meant for situations where the contact chosen automatically by the system is the wrong one (example: the system chose Alice but this is really Bob). If the system created a new contact because it did not know enough to locate a pre-existing one at the time it resolved the identity, then you should use the merge operation instead.

And yes, as you mentioned, there is currently a limit of 25 merge operations on a single contact. Will that be enough for your normal uses cases or do you expect to exceed that regularly?

For reference, the API endpoints for the operations I described above are:

You can find more info on the contact types, lifecycle, and merging here: https://developer.genesys.cloud/commdigital/externalcontacts/contact-merges

I hope that helps. Please let us know if you have any more questions.

Andy

8

Hi Andy,

Really appreciate the thorough reply. It is unfortunate news that there is no way to re-associate the web session to a different external contact at this time. Would love to hear how you plan to accomplish this. The one thing that is confusing about your reply is that when I use the associate conversation to external contact endpoint, it actually replaces the external contact ID in the conversation detail, so I figured it actually was linking the session to the external contact I specify. But, now I know it's not, so that's helpful.

This issue is really a symptom of 2 underlying problems with Web Messaging, in my opinion: Identification and History. With any other asynchronous channel, there is an upfront process to identify who the person is. With SMS or WhatsApp, it's a cellphone number. Facebook, a profile, etc.

With Web Messaging, the process to identify who this person is, is browser based via local storage. This of course introduces the biggest problem with web messaging, which is that other people could potentially view your conversation history.. and they can do this because the conversation itself is not linked to a person it is linked to a browser. Thus, if I as a husband was buying a gift for my wife on a Target.com for example, and had to chat with an agent regarding my gift.. If I close my browser and my wife logs in to Target.com to buy some groceries, she could still see the conversation history! This scenario is not one in which authenticated web messaging has any part in, so that's not a solution.

On top of the issue of not being able to properly identify someone, another core problem with web messaging is that we cannot control the guest session, thus the history that the client sees in their web messaging interface. This causes a TON of security and privacy issues for people accessing browsers through shared devices. I know there's an idea out there to address this, but it is a huge detractor for GC. We should be able to in our web messaging widget configuration, control how long that history is stored (or even make it disappear on disconnect).

On the merge approach, I think it would make sense to have the merged contacts (ancestor contacts is what I believe they become) expire after a certain period. There's no reason we need to store these forever (at least not that I can think of). Also, the limit of 25 seems low. For our enterprise customers, where people are frequently going to a website and initiating a single chat message to get 1 response, then closing out.. These people could be doing that from multiple computers (home, work, phone) over the course of a year. On top of that, some consumers really only use an incognito browser, and thus every time they would chat with our company that would create a new contact.. We'd run into the limit pretty quickly, I think with both scenarios.

At the end of the day, we need to be able to easily identify who someone is, understand that in Genesys Cloud and control from a privacy perspective, the information that they see in the web messaging client. We can't do either of these today, which causes issues with implementing web messaging.

1 Like
9

Hi Andy,

I did want to follow up on your question of whether or not the limit of 25 is suitable for my needs. It is not at this time - we are demo'ing web messaging/predictive engagement many times throughout a day and will exceed this limit by the end of a week. All of our web messaging sessions for our demos are started in an incognition browser window, due to the fact that we want to hide the guest session history. Therefore, because we are constantly creating guest sessions we will run into the limit of 25 very quickly.

Can this limit be extended? And if so, is there an upper limit on this feature in general?

10

Hi @Andrew_Johnson - Just following up on the limit for the External Contact Merge set. Any thoughts on being able to expand the mergeSet from 52 (the current limit of the array)?

11

Hello,

The current limit on the mergeSet size is 52. This allows 25 merges to happen. We are considering the future of this limit but do not have anything to share at this time.

In the meantime, we are keeping a close eye on whether any customers actually run into this limit in production.

As for your demos, probably the easiest thing to do to get around the problem is to delete your curated contacts on a regular basis and start fresh.

Thank you for your detailed feedback -- it was very helpful!

Andrew

12

Hi. You are raising several valid points related to Web Messaging improvements, and we are planning to address them in, some work is already in-progress. The use-case for shared-devices will be addressed by new feature for end-user to explicitly "clear" the messages on for current Guest session, and we're actively working on it. The shared device scenario reminds me of similar behavior you may experience with most popular online retailers: if you make an online purchase, it is extremely likely that the next person using your computer will be able to access your account and purchase history from that device, by simply re-opening the retailer website, and that's based on how website is designed, to reduce friction. The user in that case (either original user or next user) can decide to explicitly "exit" the session, and start a new one. For the highest level of privacy, authentication is still necessary: that applies to online banking, insurance and healthcare (and public messaging apps).

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.