# Visitor activity and availability Live activity and connection state help you judge whether a website visitor is still available. *Release 3.3 ยท developer, operator, supervisor, visitor* **Floor** ## What it is INSIDE uses browser activity, tab state and connection checks to keep visitor availability current. Visitors can become inactive, go away or leave the live floor. These states help operators judge whether a visitor is likely to receive a response now. ## Who uses it and why - Operators check availability before starting or continuing a conversation. - Supervisors interpret live visitor counts and away conversations. - Developers check that browser activity and reconnection continue to work with the website integration. - Visitors can resume activity and reconnect after an idle period. ## Where to find it Presence is reflected on the live floor and in conversation availability. An eligible retained conversation can show the system comment **Customer went away**. This is distinct from ending the conversation. ## How it works The standard browser integration observes activity such as mouse movement, keyboard use, scrolling, clicks and focus. Its normal timing is a two-minute keepalive, three-minute idle threshold and five-minute away threshold. It signals an away warning 25 seconds before the away threshold; the visible warning depends on the visitor interface. At the away threshold, the browser stops its live connection. Foreground activity can start it again. During a supported warning, pressing Space can extend the away timer. INSIDE also tracks active tabs. Making one tab inactive does not put the whole visitor to sleep while another tracked tab remains active. Server checks apply conversation and channel rules. Ordinary website visitors can become inactive after three minutes. Five minutes of inactivity or about 20 seconds of disconnection can lead to removal or away handling. A qualifying existing chat can remain available to the operator with the visitor marked offline. ## Configure it There is no general client Settings control for these standard thresholds. Ask Powerfront to review an integration if activity detection or reconnection is not working as expected. Conversation, workflow and co-browse state affect away handling. Configure their own lifecycle options in the corresponding features rather than treating the presence timers as chat-expiry settings. ## Limits and good to know - Checks run periodically. Thresholds are not exact promises about when a visitor disappears. - A connected browser does not prove someone is reading the page. - A visitor can leave the floor without losing a saved browser identity or starting a new visit. - A chat-free visitor with no connections is also eligible for cleanup after about 30 seconds. - An accepted co-browse session can affect inactivity retention. Going away can close co-browse and payment interactions in qualifying chat handling. - Email, voice, social and push-enabled visitors use different lifecycle rules. ## Depends on and works with ### This feature uses - **Requires** [Visitor identity](VIS-001.md): Connections and browser tabs are associated with a visitor identity. - **Configured in** [Cookie consent and opting out](VIS-018.md): A memory-only visitor is removed when its temporary session is no longer available. - **Works better with** [Starting, ending and expiring chats](CHAT-001.md): A qualifying conversation can be retained with its visitor marked offline after the visitor goes away. - **Works better with** [Floor avatar indicators](CON-010.md): Floor appearance communicates active and inactive visitor state. - **Works better with** [Virtual Assistant task steps and branches](ENG-011.md): A running workflow can keep a conversation available when the visitor goes away. - **Works better with** [Co-Browse with website visitors](RTC-030.md): An accepted co-browse session changes the inactivity handling that would otherwise remove a visitor. - **Works better with** [Live visitors on the floor](VIS-012.md): Live lists reflect visitor activity updates and removals. - **Related** [Visits and returning visitors](VIS-002.md): Going away or disconnecting does not by itself start a new visit. ### Used by - **Required by** [Live visitors on the floor](VIS-012.md): Activity and disconnection handling determine live visitor state and removal. - **Required by** [Visitor connection recovery](VIS-022.md): Live visitor connections determine where updates can be sent. - **Required by** [Live visitor and operator floor](CON-006.md): Visitor presence and activity supply the live floor state. - **Enhances** [Traffic Optimizer for visitor tracking](VIS-019.md): Visitors already online bypass the active optimiser in the normal tracking configuration flow. - **Related** [Visits and returning visitors](VIS-002.md): Live presence uses shorter inactivity rules than the rules that separate visits. - **Related** [Visitor chat status and waiting](VX-007.md): Visitor inactivity and disconnection are distinct from conversation expiry and confirmed operator unavailability. - **Related** [Captured data expiry and message sanitisation](SEC-022.md): Visitor session cleanup triggers session-end expiry independently of conversation ending. ## FAQ and troubleshooting ### Why did the visitor become inactive with the page still open? An open page is not the same as recent activity. Tab focus and the activity timers can change the visitor's state. ### Why is an away visitor still in my conversation? INSIDE can retain an eligible chat and mark the visitor offline so the conversation remains available to you. ### Why did closing one tab not remove the visitor? Another tracked tab may still have an active connection. ### Can the visitor return after going away? Yes. Foreground activity can reconnect the standard integration. Saved identity and conversation rules determine the context available on return.