Configure Server-triggered Messages

Configure your campaign to send server-triggered In-App or On-Site messages

If you use server events to trigger your In-App or On-site campaigns, the messages sent to your users will be queued and only delivered after they open your application or website.

Server events can include any backend events that are triggered from integrations or through external API using the hit event method. For more information on how to configure events using APIs, see event methods.

After your user receives the message, a delivery receipt is logged in the Analytics tab within the campaign. You can also enable automatic polling of queued server events, allowing you to display server-triggered messages to your users in real-time.

Server-triggered messages target individual user profiles rather than specific devices or browsers. If a campaign is sent to a user with multiple associated devices, the message only appears on the first device they open. After this, the message does not appear on other devices or browser sessions unless they re-enter the campaign.

📘

Sending In-App and On-Site Messages Together

Server event-triggered In-App and On-site messages are sent and tracked separately. If your campaign contains both In-App and On-site messages, your users will receive the In-App message on their application and the On-site message when they open your website.

Displaying Multiple Server-triggered Messages

There may be instances where multiple server-triggered campaigns are sent to your user while they are offline, but are displayed after they open the website or application. The layout of these messages differ based on the message type and environment:

Android and iOS

  • Modals and banner in-app messages are displayed one after another, after each message is closed.
  • Inline content messages are displayed according to your configurations.

Web

  • Alert style on-site campaigns are displayed immediately one on top of another.
  • If the user receives multiple pop-up style on-site campaigns, only the last one is displayed.
  • Inline content messages are displayed according to your configurations.

Prerequisites for using Server-triggered Messages

Update the Xtremepush SDK

To enable automatic polling of server-triggered messages, update the Xtremepush SDK to the following versions or above:

Configure Polling for Server-triggered Messages

The polling configuration for your campaigns must be done individually for each application or website that your campaign is running on. To configure the polling settings, perform the following steps:

  1. From the Settings tab, go to Apps & Sites.
  2. Open the application or website you want to enable server-triggered messages for, and then open the In-App or On-Site settings.
  3. Configure server polling settings:
  • If you want to enable automatic polling for server events, turn on the Automatic Polling toggle.

🚧

Set Polling Interval

To set the polling interval and the duration of each polling request in seconds, contact Xtremepush support. See Contact Us for details on contacting Xtremepush Support.

  • Older versions of the Xtremepush SDK do not support automatic polling, but you can still trigger in-app messages from the server and display them when users take specific actions in the app. To do this, specify one or more events as triggers under Trigger Events to display queued campaign messages.

Manual Polling of Server Events

If you prefer more control over when queued in-app messages appear during the app's lifecycle, leave the Start automatically toggle off and use SDK methods to enable manual polling of server events.

This approach is useful if you want to delay in-app messages until the user completes authentication or prevent interruptions on specific screens within your application.

  • Start Polling:
mPushConnector.startInappPoll(context)
XPush.startInappPoll()
 [XPush startInappPoll];
xtremepush(‘inapp’, ‘poll.start’)
  • Stop Polling:
mPushConnector.startInappPoll(context)
XPush.stoptInappPoll()
[XPush stopInappPoll];
xtremepush(‘inapp’, ‘poll.stop’)

In-app Polling Lifecycle

With automatic polling enabled, the first polling request is issued when your user opens the app or visits the web page. When automatic polling is disabled, the first polling request is issued when the startInappPoll method is called.

The next polling request is issued after the configured polling interval in the respective app or site.

Polling is paused when:

  • The tab in the browser is deactivated
  • The application goes into background mode

Polling is resumed when:

  • The tab in the browser is activated
  • The application goes back into foreground mode