I’m designing a Web Messaging experience for a client who has their main site on brand.com and their support portal on help.brand.com. We want the messaging conversation to be persistent as the customer moves between these two domains.
However, we’re seeing that whenever a customer clicks a link to move from the main site to the help portal, the messenger widget reloads and generates a completely new conversation ID. It seems the guest token (stored in localStorage) isn’t being shared across the subdomains.
Is there a way to configure the Genesys Messenger snippet to use a shared cookie or some other method to maintain the session identity across subdomains of the same parent?
I’ve dealt with this in our chatbot integrations. By default, the Genesys Messenger stores the _gc_guest_token in localStorage, which is strictly scoped to the exact domain (including subdomains). This means brand.com and help.brand.com can’t see each other’s storage.
You can’t force the widget to use a cookie for the token (the platform doesn’t support it for security reasons), but you can use the Messenger Transport SDK to manually pass the token in the URL as a query parameter during the transition, and then re-initialize the widget on the new domain using that token. It’s a bit of extra JS, but it’s the only way to bridge the storage gap.
Exactly! If you don’t want to mess with the Transport SDK, some people use a ‘PostMessage’ bridge between an iframe on the two domains to sync the localStorage, but that’s very brittle.
From a gamification perspective, we track session length, and these ‘Breaks’ in the conversation really mess up our engagement metrics. If the session splits, it looks like two short interactions instead of one high-value one. Definitely try the token-passing method in the URL.
One thing to check is your ‘Allowed Domains’ list in the Messenger Deployment. If you haven’t added BOTH brand.com and help.brand.com (or just *.brand.com), the widget might be failing to initialize on one of the sites, which could also explain the ‘New’ session behavior.
Also, keep in mind that if the customer has ‘Third-Party Cookies’ or ‘Site Data’ blocked in their browser, even the URL token passing might fail if the widget tries to write back to the new domain’s storage.