FAQs: Web messaging

With the introduction of Digital User Tracking (formerly known as Journey Tracking), Genesys recommends configuring web tracking directly within your Messenger configuration. You can find these settings by navigating to Menu > Digital and Telephony > Message > Messenger Configuration > Digital User Tracking and enabling Messenger-specific settings. For more information about web tracking settings configuration, see Configure web tracking.

Previously, web tracking settings were managed globally under Menu > Orchestration > Predictive Engagement > Predictive Engagement Settings > Tracking Settings. These settings applied the same behavior across all Messenger deployments of your organization.

The latest Messenger-specific web tracking settings allow you to define and save tracking behaviors to an individual Messenger configuration. This gives you the flexibility to tailor tracking for each of your websites, ensuring Digital User Tracking aligns with the specific goals and data needs of each experience.

To learn more about the advantages of using Messenger-specific web tracking settings and how it compares to the legacy Predictive Engagement settings, refer to the web tracking comparison table.

No, configuring web tracking is optional. By default, Digital User Tracking applies the standard tracking behavior, that is, any visitor navigating your tracked website is recorded as a web visit, and each page they view and each URL change are logged as a page viewed event.

The web tracking settings allow you to refine this behavior and customize how tracking works on your website. You can use these settings to:

• Exclude specific visitors by filtering their IP addresses.
• Include or ignore certain parts of your website URLs, such as fragments or query parameters.
• Collect keywords searched by visitors.

To learn more about the use cases these settings address and how to adapt tracking behavior to your website’s needs, see Examples of adapting tracking settings by website.

Your existing Messenger configurations that rely on the global web tracking settings defined under Orchestration > Predictive Engagement > Predictive Engagement Settings > Tracking Settings will continue to function as before. This ensures that your current tracking implementations deployed to your websites via Messenger remain uninterrupted after the introduction of Messenger-specific web tracking settings.

To start defining tracking behaviors specific to a Messenger, you can edit your Messenger configuration to select the recommended Messenger-specific option in the Digital User Tracking configuration section. You can then define your desired web tracking settings and deploy your changes to apply them to your website. For more information about web tracking settings configuration in Messenger, see Configure web tracking.

Defining tracking behavior at the configuration level lets you tailor tracking to each Messenger deployment and adapt Digital User Tracking to the unique needs of your websites. For more information about migration steps and benefits, see the Migration guide.

The session persistence method set on your Messenger Configuration determines the behavior that occurs when your customer navigates across subdomains of your website and the same Messenger deployment is present.

Expand allCollapse all

Genesys Messenger runs in its own iframe and uses the Web Storage API to store internal vendor-specific identifiers in the browser’s localStorage, using Genesys Cloud as the origin for storage. Because of this, Messenger is not affected by browser deprecations of third-party cookies.

Messenger supports preview of file types only when it is supported by the browser. Each browser has its own set of file types that it can support rendering, so it can vary based on the browser and OS combination.

For example, .mp4 is a standard file type that is supported in all browsers whereas .mov is only supported in Safari and Firefox browsers in iOS. So Messenger uses a browser API to detect if it can support rendering and show preview. If not, it falls back to the download option where the user has to download the file and open in their native app to view. For information about file types preview, see Supported content profiles.

To migrate from co-browse for web chat to co-browse for web messaging, ensure that:

• Configure Messenger with co-browse for web messaging is enabled
• Your agents have the permission Conversation > Cobrowse > Add

When your customers use Messenger to initiate web messaging interactions, agents can propose a co-browse session directly within the conversation.

To migrate from the legacy co-browse for voice to the new co-browse for voice via Messenger, you must consider the timing of when to make the switch as the two versions of co-browse are not cross-compatible. As soon as your agents are assigned Conversation > CobrowseVoice > Add, the generated co-browse Meeting IDs will only work for the Messenger-based version. At the time you wish to switch from legacy to new co-browse, ensure that:

• Your agents have the new permission Conversation > CobrowseVoice > Add.
• Your website provides a way for customers to enter Meeting IDs for the Messenger-based co-browse, not the legacy co-browse deployment. Meeting IDs generated while using Conversation > CobrowseVoice > Add will not be recognized by the legacy co-browse deployment.

Cross sub-domain browsing can be achieved via your session persistence method, assuming both pages contain your Messenger Deployment. Cross domain scenarios are not included and are currently unsupported by Messenger.

Yes, co-browse relies on the Messenger snippet to continue the session when you navigate across pages.

When you enable Humanize your Conversation for your Messenger configuration, Messenger displays a participant name and avatar next to each message that you send.

Any message that an automated reply or bot flow sends on behalf of your brand appears with the bot name and bot avatar that you specified in your Messenger configuration. If you do not define a bot name, no bot name appears. If you do not define a custom bot avatar, Messenger uses the default bot avatar.

When an agent sends a message, Messenger displays the name and avatar as follows:

• If the agent has an alias and image defined, these are used. For more information, see Add an agent alias and image.
• If the agent has an alias defined but does not have an image defined, a generated avatar with their first initial is displayed.
• If the agent does not have an alias or image defined, the agent fallback avatar is used. 
• If the agent does not have an alias defined, no name is displayed.

No, the messaging threading timeline does not affect Web Messaging Guest session duration. Threading timeline is limited to the internal conversation model. If threading timeline is set to zero, then the internal conversation is ended when the agent disconnects. If the end-user sends a new message over the same Guest session that will generate a brand new conversation ID, which in turn would trigger new flow execution and new transcript for Agent, while the end-user’s experience is not affected. End-user can continue the existing conversation, as long as the Guest session has not expired. For more information, see Messaging threadline timeline. 

Currently, this session duration is not configurable, and is hardcoded at 72 hours. 

After 72 hours of message inactivity, the Guest session expires, and client cannot obtain a valid JWT to access messages via History API. On the client side, however, there is no command or event that can trigger this. Once Guest session expires, the native Messenger generates new a Guest Token, which is used to start a new session.

End-user can access messages over the last 15 days. Messages remain as transcripts and are attached to conversation for 60 days. For more information on storing these transcripts and retaining policies, see Create recording policy.

Web Messaging will expose previous messages from the current conversation over a sliding window of past 15 days, as long as there are ongoing messages exchanged within past 72 hours. Messages will be accessible and visible for up to 15 days from the time they have been sent or received.

Yes, brands can define and send custom attributes (participant data) on any message during a web messaging conversation. This can be helpful to leverage during routing or to present additional information to the agent during the conversation. For more information on how this is done, see the Messenger Example or Guest API Example.

The client messaging app generates the unique Guest token required by Web Messaging APIs, which is a unique string that uses a UUID. Web messaging does not enforce any strict rules nor applies any checks.  To ensure guest token is unique, we recommend using a 32 hexadecimal digits Universally Unique Identifier (UUID).  Web messaging API does not enforce any specific check on the format and the token cannot exceed 2048 characters.

Messenger will display the up-to-date conversation in up to three separate browser tabs or windows without the need to refresh. If a fourth Messenger instance is opened, then the oldest instance would be minimized automatically. Upon expanding the minimized Messenger, the conversation would immediately reflect the latest messages.

The Messenger deployment snippet loads the Predictive Engagement snippet automatically, if Predictive Engagement is enabled in the associated Messenger configuration. In this case, you do not need the separate Predictive Engagement tracking snippet on your website.

Messenger enables web messaging by providing a predefined messenger window that customers use to interact with bots and agents. Messenger limits an inbound message to 4096 characters and image attachments to sizes not larger than 10MB.

Web messaging requires an inbound message flow and changes to your website to deploy the new messenger. Web chat inbound chat flows cannot be used for web messaging. You must be manually re-create them as inbound message flows. For your migration path, plan to set up the new messenger and web messaging channel, and add it to your website. Test it in parallel with the existing web chat functionality. Provide Genesys with your feedback on functionality you would like to see added before you migrate from web chat to web messaging. For more information, see Web chat to web messaging migration and impact.