Hi Tiziano
to start: just force hide the native GPE offers on the website via CSS:
.genesys-app:not(#genesys-messenger) {
display: none;
}
This will hide the native offers, but not the Messenger.
Then use the SDK commands to subscribe to the events.
Save the data you get from Journey.qualifiedContentOffer, you will need to refer to the
journeyContext.triggeringAction.id when you are sending back events to Genesys via Journey.recordActionStateChange.
Send a 'offered" event when displaying your custom Offer. (when hiding the native offers, sometimes this doesn't happen automatically).
Send "accepted" when the user clicks on the main CTA button.
Send "rejected" when the user closes the offer via a X button.
Also, final recommendation is to avoid using Webmessaging offers when implementing custom rendering. Just still use a content offer, and on the main CTA button implement a command to open the Webmessenger ( Genesys('command', 'Messenger.open') ) in addition to track the accepted status as above.
------------------------------
Michele Scala
Solutions Architect
------------------------------
Original Message:
Sent: 07-14-2025 12:20
From: Tiziano Perchinunno
Subject: Custom SDK Management of Proactive Engagement Actions
I have a question regarding advanced SDK implementation for proactive engagement.
I'm managing web messaging on my website through the Genesys Cloud SDK for precise control over widget behavior and user experience.
Is it possible to use the SDK to handle Proactive Engagement Actions in a completely custom manner? Specifically, I want to:
- Listen to proactive engagement events such as:
Journey.qualifiedWebMessagingOfferJourney.qualifiedContentOffer
- Implement custom handling for content offer and web messaging proposals
- Disable native behavior to prevent the default proactive engagement actions from triggering
I need to ensure that when these events fire, only my custom SDK-based implementation executes, while the native/default proactive engagement behavior is suppressed. This is crucial to prevent:
- Duplicate actions (both native and custom implementations firing simultaneously)
- Conflicting user experiences
- Multiple overlapping prompts or offers
Any code examples, documentation, or best practices would be greatly appreciated!
Regards
#WebMessaging
------------------------------
Tiziano Perchinunno
Principal Solution Architect
------------------------------