FAQs: Web messaging

The Blocked Actions report lists the reasons for the qualified action not being offered. Next to each reason the action is blocked, the following details appear:

• Sessions – The number of sessions during which the action is blocked. If an action is blocked multiple times during a single session, the session number is retained at one.
• Count – The number of times an action is blocked. For example, if an action was blocked 30 times during a single session, the count number is 30.

When Genesys Predictive Engagement presents a proactive offer to a visitor, that offer can be an invitation to start a messaging conversation with a live agent assigned to the queue to which the action map routes. Multiple action maps can route to the same target queue.

• Genesys Predictive Engagement can offer web and mobile messaging offers and content offers.
• Multiple action maps can route to the same target queue.
• Genesys Predictive Engagement does not use workforce management (WFM) or Workforce Engagement Management (WEM) data to power the service level throttling / “Route to agent if available” feature. For Genesys Cloud CX customers, Genesys Predictive Engagement uses the real-time presence status of agents that the analytics APIs provide. The status is available for all Genesys Cloud CX customers and the WFM or WEM features do not impact it directly.

Genesys Predictive Engagement allows messaging offers when the following criteria are met:

• Action map conditions are met.
• Agents are on queue.
• Offer is within scheduled hours.

When you create an action map, you specify the conditions, or triggers, that qualify for a visitor. A visitor cannot qualify for the same action map multiple times in a single session. If multiple action maps qualify, the priority of each action map determines which one Genesys Predictive Engagement offers to the visitor. For more information, see Prioritize an action map.

1. Genesys Predictive Engagement applies URL conditions after qualification. Consider removing URL conditions or changing to a more restrictive operator, such as “contains all.”
2. If agents belong to multiple queues, it can impact their availability and Genesys Predictive Engagement’s ability to offer a chat.
3. When setting page URL conditions in your segment, ensure that you are not targeting visitors who are about to leave the site. Try adjusting the targeting to a step earlier in their journey. Consider this recommendation when setting page URL conditions in action maps also.
4. Conflicting action maps may prevent offers from occurring as Genesys Predictive Engagement only offers one action map per action type, once per page.

The user interface for Predictive Engagement features is currently localized in the following languages:

• Dutch
• French
• German
• Italian
• Japanese
• Korean
• Portuguese
• Spanish
• Swedish

Genesys Predictive Engagement does not support co-browse or screenshare capabilities of Genesys Cloud CX. If a visitor accepts a proactive messaging offer through Genesys Predictive Engagement, an agent cannot escalate the chat to a co-browse or a screenshare session. 

Yes. You can set up action maps using app events and visitor attributes specific to device types to create qualifying conditions, such as the device used, web browser and operating system. For more information, see Visitor attributes.

You can designate IP addresses for which digital user tracking should not record any events for each Messenger Configuration. 

For more information, see Exclude IP addresses.

An app visit starts from the moment a visitor executes a tracked interaction on a mobile application, such as viewing a specific screen. Similar to a Web visit, the app visit continues as the visitor keeps interacting with the tracked mobile application and ends after 30 minutes of inactivity.

Genesys Predictive Engagement is available on mobile applications.

You can define action maps in Genesys Cloud to configure Genesys Predictive Engagement to proactively present personalized content offers or to invite mobile visitors to start a mobile messaging conversation.

The Journey Orchestration API must be implemented in a mobile application to present the relevant actions as soon as a mobile visitor matches the conditions defined in an action map.

For more information, see Journey Orchestration.

A web visit starts from the moment a visitor lands on a website and provides consent for tracking. The web visit continues while the visitor browses the website and lasts until the visitor is inactive for 30 minutes. If the visitor resumes browsing after 30 minutes, digital user tracking records that activity as part of a new web visit.

Genesys Predictive Engagement is a cloud-based customer engagement solution that offer personalized and proactive engagement with online visitors, based on user characteristics or behaviors on websites and mobile apps, to help them desired outcomes at the right moment. 

For example, too often visitors abandon carts, customers remain frustrated on mobile apps, or prospects leave websites without finding what they need. These scenarios lead to missed leads, lost revenue, and increased calls to the contact center. Through user behavior data collected by digital user tracking, Genesys Predictive Engagement allows you to present the right offer to high-value customers and prospects, whether it’s relevant contextual content or a messaging conversation to connect with a sales representative.

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.