Contact usRequest a demo

Configuring visitor presence initialization

When a visitor to your website accesses a page that includes the Unblu snippet, they download JavaScript from the Unblu Collaboration Server.

The JavaScript polls the server to check whether there is anything to inform the visitor of, such as unread messages in existing conversations. This initial polling continues until there’s something to inform the visitor about. When that occurs, or when the visitor opens the Floating Visitor UI by clicking the launcher button, Unblu creates a visitor session.

The visitor session is used to retrieve and display a visitor’s conversation overview as well as new messages and any incoming calls they may receive. It’s also used to determine and convey a visitor’s online state.

Once a visitor session has been established, polling for new messages and the like takes place within the context of the visitor session. Furthermore, Unblu actively invalidates the back/forward cache so it doesn’t end up in an invalid state because of visitors navigating back and forwards.

Drawbacks of the default initialization strategy

The initialization strategy outlined above has an impact on both the amount of network traffic and the number of database transactions.

  • Initial polling takes place every 5 seconds. This results in many small requests, which increases network traffic.

    It also leads to extra read and write transactions on the database, because the timestamp of the polling request is compared with that of the most recent record and stored itself.

  • Once a visitor session is established, this leads to additional write transactions on the database to update the timestamp. These updates also occur every few seconds.

Alternative initialization strategies

In some scenarios, you may want to deactivate initial polling and to postpone the creation of a visitor session until it’s actually needed.

  • If you don’t use Unblu’s messenger or call features, the initial polling will never return a change that the visitor need know about. You may therefore decide to deactivate initial polling.

  • If your visitors never see their earlier conversations, initializing the visitor session when they open the Floating Visitor UI is unnecessary. You could instead wait until a visitor actually starts a conversation to initialize the visitor session.

For example, Unblu’s live chat feature is intended for short-lived, one-off conversations. These may take place in situations where a visitor to your website needs assistance right away to complete a task. Furthermore, as the name suggests, live chat only works live, like a conversation on the telephone. Once the participants leave the conversation, the conversation is over and can’t be resumed.

You can choose the initialization strategy best suited to your requirements from the options provided in the configuration property com.unblu.visitor.presence.visitorPresenceInitializationMode, outlined below. The configuration property is available in a number of scopes, so you can set it differently for different use cases.

Initialization ALWAYS

The setting ALWAYS activates the default initialization strategy described above:

  • Initial polling takes place every 5 seconds

  • A visitor session is created when the visitor opens the Floating Visitor UI or a polling request returns information that should be displayed for the visitor, for example regarding a new message or an incoming call.

The setting ALWAYS must be applied in the following use cases:

  • Asynchronous messaging

  • The possibility of multiple concurrent conversations

  • Incoming calls

  • Sharing visitor state between different tabs or devices

In all these cases, the initial polling ensures that visitors are notified of changes. This would not be possible otherwise.

Controlling polling network traffic

If you set com.unblu.visitor.presence.visitorPresenceInitializationMode to ALWAYS, you may find that polling generates a significant number of requests. You can affect how frequently the visitor’s client polls the Unblu server with the following configuration properties:

You can influence the polling rate, and thus the amount of network traffic it generates, by changing one or more of three values:

Initialization ON_INTERACTION

The setting ON_INTERACTION reduces the amount of network traffic by eliminating the initial polling requests to check for changes on the Unblu Collaboration Server.

  • There is no initial polling.

  • The visitor session isn’t created until a visitor interacts with Unblu. In this context, "interaction" means either opening the Floating Visitor UI or using the Unblu Visitor and Embedded JavaScript APIs in a way that requires a visitor session. You need a visitor session when you use the JS API to retrieve person-related information, for example.

  • Visitors can view both ongoing and ended conversations.

The lack of initial polling limits the use cases for Unblu:

  • All conversations are initiated by visitors. This means it isn’t possible for you or your agents to reach out actively to visitors.

  • Asynchronous messaging isn’t possible.

  • Visitors can only receive inbound calls while actively using Unblu.

  • There is no transfer of state between multiple browser tabs or devices. Even when a visitor has interacted with Unblu on one device, the other device or devices won’t be aware of the interaction until they, too, are used to interact with Unblu.

All these features require a visitor session. This means that they’re possible once some form of interaction has taken place—​for example, once the visitor has clicked on the launcher button—​but not before. Using this setting in conjunction with the features listed above will result in a poorer user experience than applying the setting ALWAYS.

Initialization IN_CONVERSATION

Besides deactivating the initial polling mechanism, the setting IN_CONVERSATION also defers the initialization of the visitor session until the visitor opens a conversation. It also ends the visitor session when the current conversation ends, thereby further reducing the amount of unnecessary polling.

The limitations of the setting ON_INTERACTION apply here, too:

  • All conversations are initiated by visitors. It isn’t possible to reach out actively to visitors.

  • Asynchronous messaging isn’t possible.

  • Visitors can’t receive inbound calls.

  • There can be no transfer of visitor state between browser tabs and/or devices.

However, the setting IN_CONVERSATION further restricts the possible uses of Unblu:

  • Visitors can only take part in a single conversation at a time.

  • There is no conversation overview, neither before nor after a conversation. This is because the visitor session only persists while the conversation is ongoing, and a visitor session is required to retrieve the data used to populate the conversation overview.

This setting is intended solely for use cases that involve only one-off conversations initiated by visitors.

Visitor session initialization in the Unblu mobile SDK

The mobile SDK relies on the same initialization strategies to inform your app’s users of new messages or incoming calls. However, it is possible to send push notifications to a mobile device, regardless of the visitor session state, provided the mobile SDK was initialized at some point in the past. So if a visitor were using a mobile app with the mobile SDK and viewing a web page instrumented with Unblu on their computer at the same time, and the configuration property were set to ON_INTERACTION, they would be notified of, say, unread messages on their mobile device, but not on the web page.

The configuration property com.unblu.visitor.presence.visitorPresenceInitializationMode affects when and how the Unblu mobile SDK initializes a visitor session the same way as it does your Unblu-instrumented website.