Visitor connection recovery
Deliver live visitor updates to the relevant browser page and retain selected pending actions while it connects.
What it is
INSIDE sends live visitor updates to the relevant open browser connection. Some actions can wait until the matching page connects. This supports normal visitor interaction when page tracking and the live connection become ready at different times.
Who uses it and why
Developers need to understand which page receives an action when integrating INSIDE into a website. Visitors benefit from live chat and engagement controls updating as their connection becomes available.
Where to find it
This behaviour operates within the website's INSIDE visitor experience. It has no separate Settings page or visitor recovery control.
How it works
INSIDE can send a live update to all of a visitor's connections, one eligible connection or the connection associated with a particular page view. Multiple open pages can therefore receive different updates.
For selected actions, INSIDE keeps a pending action if the target connection is not available. When a page connection registers, INSIDE sends the pending actions for that page and eligible visitor-wide actions. Ordinary pending actions are then removed from the waiting list.
Some continuing actions remain available to later connections until they are explicitly cleared. This limited buffering does not cover every live update.
Configure it
Use the website's supported INSIDE integration to establish the visitor connection and process its updates. There is no client setting for a general replay window in this release.
When investigating an interruption, record whether it affected one tab, several tabs or a page navigation. Ask Powerfront to check the relevant visitor interaction if an action fails to appear after reconnection.
Limits and good to know
- Recovery of a live connection does not guarantee replay of every update sent during an interruption.
- Pending actions are temporary live state. Do not rely on them surviving a service restart.
- An action intended for one page is not automatically applicable to the visitor's next page.
- Connection status alone does not establish whether a conversation message was delivered. Use the conversation's delivery status where available.
Depends on and works with
View all connections as a list
This feature uses
- Message delivery and read receiptsRelated
Check message delivery feedback separately when deciding whether to resend after a connection interruption.
- Visitor identityEnhances
Visitor recognition supports continuity when a browser reconnects.
- Visitor page and product trackingEnhances
Tracked page views let selected live updates be targeted and buffered for a particular page.
- Visitor activity and availabilityRequires
Live visitor connections determine where updates can be sent.
- Time-based visitor event triggersEnhances
Selected time-on-page registrations can wait for the matching page connection.
Used by
- INSIDE visitor CLIRequires
The test visitor receives updates through the existing live visitor connection.
- Time-based visitor event triggersRequires
Time On Page registration and completion use the visitor's browser connection.
- Visitor chat status and waitingRequires
Live updates carry availability and conversation state.
FAQ and troubleshooting
Will every missed update be replayed after reconnection?
No. Only selected actions use pending-action handling in this release.
Why did an action appear in one tab only?
Some actions target a specific tracked page or one visitor connection.
Can I set a guaranteed recovery period?
There is no client-configurable general replay period for this behaviour in 3.3.
Should I resend a chat message just because the connection dropped?
Check the conversation and its delivery feedback first. Connection recovery and message delivery are separate behaviours.