# Time-based visitor event triggers

Use visitor timing and cooldowns to run visitor events when the current page and targeting conditions still qualify.

*Release 3.3 · admin, developer, operator*

**Settings › Events › Visitor Events**

## What it is

**Time On Page** and **Time On Site** are visitor-event triggers based on elapsed time. They let you delay an invitation, offer or alert until a visitor meets the timing and targeting rules. A cooldown controls how soon a successful event can run again.

## Who uses it and why

Administrators configure timed engagement rules. Developers check that page tracking and the visitor connection work with navigation. Operators receive the resulting alerts or engage visitors who respond to the configured action.

## Where to find it

Open **Settings › Events › Visitor Events** with the **Settings** or **Manager** role. In an event, use **Test for this event** to choose **Time On Page** or **Time On Site**.

## How it works

For **Time On Page**, INSIDE first checks the rule's conditions, schedule and cooldown after a page view. It then asks the browser to wait until **Minimum Time** has elapsed on that page. If that time has already passed, the browser reports completion immediately.

Before running the action, INSIDE checks the event again. It must still be enabled, the visitor must still be on the same tracked page, the conditions and schedule must still match, and the cooldown must have expired. Navigation cancels outstanding browser timers, and INSIDE also rejects a timer for an old page.

For **Time On Site**, INSIDE checks the elapsed visit time when processing a page. **Minimum Time** and **Maximum Time** constrain that evaluation. Staying on one page does not by itself guarantee a fresh site-time evaluation at the threshold.

A successful action updates the visitor's cooldown history. A scheduled timer alone does not start the cooldown.

## Configure it

1. Create or edit the visitor event and choose its timed trigger.
2. Enter **Minimum Time** in seconds. For a visit-time range, also set **Maximum Time**.
3. Set targeting conditions, the event schedule and the action to perform.
4. Set **Cooldown** in minutes. Use **Shared Cooldown** if the event should coordinate with another event.
5. Enable and save the event, then test it on the intended page and after navigating away.

### Fields

| Field | Where | Required | What it is for |
|---|---|---|---|
| Enabled | Settings › Events › Visitor Events | No | Allows the event to be evaluated. |
| Test for this event | Settings › Events › Visitor Events | Yes | Selects the trigger, including Time On Page or Time On Site. |
| Minimum Time | Settings › Events › Visitor Events | No | Sets the minimum page or visit time in seconds for the selected timed trigger. |
| Maximum Time | Settings › Events › Visitor Events | No | Sets the upper visit-time filter for Time On Site; do not rely on it as a hard deadline for deferred Time On Page actions. |
| Cooldown | Settings › Events › Visitor Events | No | Sets the interval in minutes before the event can run again for the visitor. |
| Shared Cooldown | Settings › Events › Visitor Events | No | Uses another selected event's cooldown history to coordinate repeated actions. |

### Permissions

| Permission | Lets you |
|---|---|
| Settings | Access visitor-event configuration. |
| Manager | Access visitor-event configuration. |

## Limits and good to know

- Disabled events and events without conditions do not execute through this timed rule handling.
- **Maximum Time** is not a reliable hard deadline for a deferred **Time On Page** action in this release.
- A positive cooldown must have fully elapsed before another action runs.
- Browser delays and connection interruptions can affect when a page timer reports completion. The configured time is not an exact delivery promise.
- Elapsed time does not establish that the visitor was actively looking at the page throughout.

## Depends on and works with

### This feature uses

- **Requires** [Visitor event rules and actions](ENG-001.md): Timed triggers are configured as visitor-event rules.
- **Requires** [Visitor event targeting conditions](ENG-002.md): A timed visitor event needs at least one qualifying visitor condition before its action can run.
- **Requires** [Visits and returning visitors](VIS-002.md): Time On Site evaluates elapsed time in the visitor's visit.
- **Requires** [Visitor page and product tracking](VIS-003.md): Page timing is tied to the current tracked page view.
- **Requires** [Visitor connection recovery](VIS-022.md): Time On Page registration and completion use the visitor's browser connection.
- **Configured in** [Visitor event and bot schedules](ENG-003.md): Event schedules are checked again before a deferred action runs.
- **Works better with** [Proactive chat invitations](ENG-004.md): Timed rules can trigger proactive invitations.
- **Works better with** [Visitor popup event setup](ENG-006.md): Timed rules can trigger visitor offers or popups.
- **Works better with** [Visitor event alerts for operators](ENG-008.md): Timed rules can trigger operator alerts or floor actions.

### Used by

- **Enhances** [Visitor connection recovery](VIS-022.md): Selected time-on-page registrations can wait for the matching page connection.
- **Enhances** [Visitor event rules and actions](ENG-001.md): Timed page signals support Time On Page events.

## FAQ and troubleshooting

### Why did the action not run when the timer elapsed?

The current page, conditions, schedule and cooldown are checked again. Any of them can prevent the action.

### Why did navigation stop my invitation?

The timer belongs to the original tracked page. Navigating away cancels it, and an old-page completion cannot run the action.

### Why did Time On Site not fire while I stayed on one page?

It is evaluated after page processing. Use **Time On Page** when you need a timer for the current page.

### Why are two events delaying each other?

Check **Shared Cooldown**. Events that share cooldown history can suppress one another after a successful action.