A real-time website gadget may want to display information such as:
7 people are listening now
12 people are viewing this property
5 people are shopping right now
18 visitors are currently using this tool
But before a gadget can display a live number, it needs to answer a deceptively difficult question:
What exactly makes a visitor "currently active"?
Opening a webpage does not necessarily mean someone is still using it.
A visitor may open an article and walk away. Someone may start a song and leave the browser tab open. A shopper may switch to another website. Someone may put their phone to sleep while the page remains loaded.
Therefore, a well-designed real-time gadget needs a clear definition of an active session, a method for detecting continued activity, and a rule for removing sessions that have become inactive.
This is the foundation of an accurate live counter.
An Open Browser Tab Does Not Equal an Active Visitor
The simplest implementation would be:
Page opened → Add visitor
Page closed → Remove visitor
Unfortunately, this is not reliable enough.
Browsers do not always provide a dependable notification when someone leaves a page.
A visitor might:
close the tab;
close the entire browser;
navigate to another page;
lose internet connectivity;
put their phone to sleep;
leave the tab open;
switch to another application;
move to another browser tab;
experience a browser crash.
The server cannot simply assume that a session is active because the initial page-load event happened.
This is why real-time systems generally use session expiration and heartbeats.
What Is a Heartbeat?
A heartbeat is a small periodic message sent by the gadget to the server.
Its purpose is essentially:
"This visitor's session is still alive."
For example, the gadget could send a heartbeat every 30 seconds.
The server might receive:
Session: A8271
Last seen: 10:15:00
Thirty seconds later:
Session: A8271
Last seen: 10:15:30
Another 30 seconds later:
Session: A8271
Last seen: 10:16:00
As long as these heartbeats continue arriving, the system considers the session active.
If the heartbeats stop, the session eventually expires.
This is much more reliable than relying on the visitor to explicitly close the page.
The Active-Time Window
The gadget also needs an activity timeout.
Suppose the heartbeat interval is 30 seconds.
You might decide:
A visitor is considered active if their last heartbeat was received within the previous two minutes.
The system can then use a rule such as:
Current time - last_seen <= 120 seconds
If that condition is true:
ACTIVE
If it is false:
INACTIVE
For example:
| Session | Last heartbeat | Status |
|---|---|---|
| A | 10:15:50 | Active |
| B | 10:15:20 | Active |
| C | 10:14:00 | Inactive |
| D | 10:12:30 | Inactive |
The server simply counts the sessions that fall within the defined activity window.
There Is No Universal "Correct" Timeout
The appropriate timeout depends on what the gadget is measuring.
This is one of the most important design decisions.
A music player, shopping page and calculator may require different definitions of activity.
For example:
| Gadget | Possible active definition |
|---|---|
| Music player | Audio actively playing + recent heartbeat |
| Online calculator | Recent interaction or heartbeat |
| Shopping page | Recent page activity + heartbeat |
| Property listing | Recent session heartbeat |
| Live chat | Open session + heartbeat |
| Online course | Active lesson/session + heartbeat |
| Game | Active connection |
| Article | Recent heartbeat, optionally combined with engagement |
These are examples rather than universal standards.
The gadget designer should choose the definition that best represents the activity being measured.
A Practical Starting Point: 30-Second Heartbeats
For many simple live counters, a reasonable starting architecture is:
Heartbeat: every 30 seconds
Active timeout: around 90–120 seconds
This creates a useful balance.
If the heartbeat is too frequent, the gadget generates unnecessary network traffic.
If it is too infrequent, the counter may remain inaccurate for too long after someone disappears.
For example:
10:00:00 → heartbeat
10:00:30 → heartbeat
10:01:00 → heartbeat
10:01:30 → heartbeat
If the visitor disappears after 10:01:30, the server eventually notices that no newer heartbeat has arrived.
Once the timeout is exceeded, the session is removed from the live count.
Why Not Remove the Visitor Immediately?
Suppose the gadget removes someone after only 10 seconds without a heartbeat.
A temporary network delay could cause:
Visitor active
↓
Network delay
↓
Heartbeat arrives late
↓
Visitor incorrectly removed
↓
Heartbeat arrives
↓
Visitor added again
The live counter might jump:
8 → 7 → 8
even though nothing meaningful changed.
A slightly longer expiration window provides tolerance for:
network delays;
mobile connections;
temporary browser throttling;
server delays;
background-tab behavior.
The timeout should therefore be long enough to avoid excessive false removals.
Why Not Keep Visitors Active for 30 Minutes?
The opposite problem occurs with an excessively long timeout.
Suppose someone opens your music page and leaves.
If your timeout is 30 minutes, the gadget might continue displaying that person as an active listener long after they have stopped listening.
You could end up with:
27 people listening now
when only a few are actually active.
That makes the statistic less meaningful.
The objective is therefore to find a practical balance between:
false inactivity
and
false activity.
Different Gadgets Need Different Activity Rules
This becomes particularly important for the systems you may eventually build.
Music Gadget
A music gadget should not necessarily count everyone who loads the page.
A better definition might be:
A visitor is an active listener when the selected audio is playing and the session has recently sent a heartbeat.
So:
Page opened
↓
Music not playing
↓
Not counted as listener
Then:
Visitor presses PLAY
↓
Listening session starts
↓
Heartbeat continues
↓
Visitor counted
If the visitor presses Pause:
Pause
↓
Listening session ends
This produces a much more meaningful "listening now" number.
Shopping Gadget
For shopping, you might define activity differently.
A visitor could be considered active if they have recently:
viewed a product;
searched;
filtered products;
opened a product card;
added an item to a cart;
interacted with the shopping interface.
However, simply having a product page open for several minutes does not necessarily mean the person is actively shopping.
You could therefore combine:
heartbeat + recent interaction
rather than relying on the page load alone.
Property Gadget
For a real-estate listing, the definition might be:
A visitor is active when their property-listing session has sent a recent heartbeat.
You could additionally record events such as:
property_view
photo_open
location_click
price_click
whatsapp_click
phone_click
inquiry_submit
Then the system can distinguish between:
Active visitors
and
Actual enquiries.
That distinction is valuable.
Someone viewing a property is not necessarily a lead.
Article or Blog Gadget
Articles are more complicated because people can spend long periods reading without clicking anything.
For example:
Visitor opens article
↓
Reads for 4 minutes
↓
No clicks
↓
Still potentially active
If you define activity only through mouse clicks, you may incorrectly classify the reader as inactive.
A heartbeat can therefore be useful.
You can optionally combine it with browser signals such as:
page visibility;
scrolling;
recent interaction;
focus state.
However, these signals should be treated carefully. A visible page does not prove that a human is actually reading it.
Page Visibility Can Improve the Model
Modern browsers provide visibility information that can help determine whether a page is currently visible.
For example:
Visible tab
↓
Potentially active
Hidden tab
↓
Potentially inactive
This can improve a basic system.
Suppose someone opens your music page and then switches to another tab.
The page may still exist, but it may no longer represent the visitor's current interaction with the gadget.
The gadget could respond to visibility changes by adjusting its heartbeat behavior or activity status.
However, visibility alone should not be treated as proof that the visitor is paying attention.
It is simply another signal.
Activity Should Be Based on Sessions, Not Personal Identity
For a basic live counter, you usually do not need to know who the visitor is.
Instead, create an anonymous session identifier.
For example:
session_id = X7A92K
The system stores:
session_id
gadget_id
page_id
started_at
last_seen
activity_type
status
The live counter then counts active sessions.
This is simpler and generally more privacy-conscious than attempting to identify individual people.
It also solves a practical problem: a visitor does not need to log into the website for the gadget to maintain a temporary session.
One Visitor Can Potentially Create Multiple Sessions
This is another reason to be careful with wording.
A person could open the same website:
on a phone;
on a laptop;
on a tablet.
That could produce three sessions.
Therefore:
3 active sessions
does not necessarily mean:
3 different people.
If the system cannot reliably determine unique people, it is technically safer to describe what it actually measures.
For example:
3 active visitors
may be acceptable depending on the identification model, but:
3 active sessions
is more technically precise.
The wording should match the measurement.
What Happens When a Visitor Closes the Page?
Ideally, the system can detect the end of the session quickly.
The browser may attempt to send a final event such as:
session_end
when the visitor leaves.
But this should not be the only mechanism.
Why?
Because the browser may not always successfully send that message.
The reliable backup is:
expiration based on last activity.
For example:
Final heartbeat:
10:10:00
Expiration threshold:
10:12:00
No activity after 10:10:00
↓
Session expires
↓
Removed from live count
This means the system can recover even when the visitor disappears unexpectedly.
The Server Should Be Responsible for Expiration
It is tempting to have the browser decide:
I am inactive, so I will remove myself.
But the server should ultimately control the active-session calculation.
The gadget sends:
heartbeat(session_id)
The server stores the latest timestamp.
When somebody requests the current count, the server calculates which sessions are still within the active window.
Conceptually:
active_sessions =
sessions where
current_time - last_seen <= timeout
This prevents the browser from manipulating the official count simply by changing its own JavaScript state.
Do Not Let the Counter Depend Entirely on the Displayed Number
The gadget should obtain the live count from the tracking system.
For example:
Gadget
↓
GET /active-listeners
↓
API
↓
Active-session store
↓
"7"
The gadget displays:
7 people listening now
The number should therefore come from the backend rather than being randomly generated or permanently stored in the HTML.
What If the Tracking Server Goes Offline?
A professional gadget needs a failure state.
Imagine that the music player itself works perfectly, but the analytics API is temporarily unavailable.
The gadget should not suddenly display:
0 people listening now
because that could falsely suggest that nobody is listening.
A better approach may be:
Live listener count temporarily unavailable
or simply hide the live counter while continuing to allow the music player to function.
The tracking system should not break the primary function of the gadget.
You Can Separate "Active" From "Engaged"
For more advanced systems, you can create multiple activity levels.
For example:
Online
The session is connected or has recently sent a heartbeat.
Active
The session has recently interacted with the gadget.
Engaged
The visitor has performed a meaningful action.
For a music site:
Online:
Page open
Active:
Audio playing
Engaged:
Audio playing for more than 30 seconds
For a property website:
Online:
Listing page open
Active:
Recent heartbeat
Engaged:
Photos viewed, location opened or enquiry initiated
This creates far more useful analytics than one generic "online" number.
A Useful State Machine
An advanced gadget can treat visitor activity as a series of states:
NEW
↓
ACTIVE
↓
IDLE
↓
EXPIRED
For example:
NEW
The visitor has just opened the gadget.
ACTIVE
The visitor is sending recent activity signals.
IDLE
The visitor has not interacted recently but the session has not yet expired.
EXPIRED
The session has exceeded the inactivity threshold and is removed from the live count.
This approach makes the system easier to reason about.
Example: A 2-Minute Activity Window
Suppose the system uses:
Heartbeat: every 30 seconds
Expiration: 120 seconds
A visitor's session might look like this:
10:00:00 Session created
10:00:30 Heartbeat
10:01:00 Heartbeat
10:01:30 Heartbeat
10:02:00 Heartbeat
At 10:02:30, the visitor has still been seen recently.
At 10:03:31, if no additional heartbeat arrived, the session is now beyond the two-minute window and can be considered expired.
The server therefore stops counting it as active.
This does not require perfect detection of the moment the browser closed.
The timeout provides a practical approximation.
The Live Counter Should Be an Approximation of Human Activity
This point is worth emphasizing.
A website cannot perfectly know whether a human being is physically looking at the screen every second.
Even sophisticated systems are estimating activity from signals.
Therefore, the objective should not be:
Detect exactly what every visitor is doing every second.
The objective should be:
Establish a consistent, technically defensible definition of active activity and apply it reliably.
Once the definition is established, the live counter becomes useful.
A Strong Configuration for a Reusable Gadget
If you are designing a reusable gadget that could work across Blogger, WordPress, Wix, Shopify, Webflow and standard websites, activity settings should ideally be configurable.
For example:
heartbeatInterval: 30 seconds
activeTimeout: 120 seconds
refreshInterval: 30 seconds
activityMode: "heartbeat"
requireInteraction: false
A music version might use:
activityMode: "media"
requirePlaying: true
A shopping version might use:
activityMode: "shopping"
requireInteraction: true
This is better than hard-coding one definition of activity into every gadget.
The Best Design Is Usually a Combination of Signals
For advanced gadgets, you do not necessarily have to choose between heartbeat, interaction and visibility.
You can combine them.
For example:
ACTIVE =
recent heartbeat
+
relevant gadget state
+
optional recent interaction
For a music player:
ACTIVE =
heartbeat
+
audio is playing
For an online calculator:
ACTIVE =
heartbeat
+
page visible
+
recent interaction
For a shopping interface:
ACTIVE =
heartbeat
+
recent shopping activity
The exact combination depends on the product.
A Practical Specification Before Coding
Before building the live counter, write down these decisions:
| Question | Example decision |
|---|---|
| What counts as active? | Recent heartbeat |
| Heartbeat frequency | 30 seconds |
| Expiration threshold | 120 seconds |
| Session identifier | Anonymous random ID |
| Additional signal | Page visibility |
| Gadget-specific signal | Audio playing |
| Server calculation | now - last_seen <= timeout |
| Counter refresh | Every 30 seconds |
| Historical events | Stored separately |
| Failed heartbeat | Retry |
| API failure | Do not show false zero |
| Privacy | Minimize personal data |
| Multiple devices | Treat as separate sessions unless deduplicated |
This specification should be completed before writing the JavaScript.
Final Takeaway
A visitor should not be considered "currently active" merely because a webpage was opened.
A better real-time system creates an anonymous session and periodically receives a heartbeat or other activity signal.
The server records the visitor's last_seen time and considers the session active while it remains within a predefined activity window.
For example:
Heartbeat every 30 seconds + approximately 2-minute expiration window
can provide a practical starting point for many simple gadgets, although the exact values should depend on what the gadget is measuring.
For specialized gadgets, additional signals can make the definition more meaningful:
Music: audio playing + heartbeat
Shopping: recent shopping activity + heartbeat
Property: recent listing activity + heartbeat
Courses: active lesson/session + heartbeat
General content: heartbeat + optional visibility/interaction signals
When the visitor stops sending valid activity signals and the timeout is exceeded, the server removes the session from the live count.
The most important principle is this:
The gadget should display what the system can actually measure—not what we merely assume is happening.
That principle becomes especially important when a live counter is used for business analytics, music engagement, property marketing, e-commerce or any other system where visitors may make decisions based on the displayed information.
