There are two visitor lists in MyLiveChat, and because they are described with the same word, people plan reporting around the wrong one. The first is the live monitor, which shows who is on your site right now and forgets them the moment they leave. The second is a stored visitor record, which is what segments, exports and the visitor API read.
They do not contain the same people, and the rule that separates them is simple enough to hold in your head. It explains most of the confusion that follows a question like why does the monitor show forty visitors when my saved list barely grows.
Two lists that look like one
Every visitor on your site appears in the live monitor. That list is a snapshot of the runtime, held in memory, and it is complete by design: a crawler, a bounce, a person who opened a tab and wandered off, all of them are there while they are there.
The stored record is a different thing with a different job. It is meant to be the durable trace of a person you have some reason to remember. If everything in the monitor were written down, the store would fill with rows for visits that never involved a single interaction, and the useful records would be buried under drive-by traffic that arrives at a scale no human list can absorb.
The engagement test
So a record is only created the first time a visitor shows what the system treats as an engagement signal. Any one of these is enough:
- An email address has been captured.
- A question or pre-chat answer has been supplied.
- Custom data or context data has been attached to the visit, typically by your own page code.
- Their status has moved past plain browsing, which covers waiting for an agent, chatting, being invited, filling in a pre-chat form, or leaving an offline message.
- They have a name they actually entered themselves.
Miss all of those and nothing is written. The visitor still appears in the monitor and still gets the full experience; they simply do not leave a row behind. The first time they do any of the above, the record is created, and from then on it exists.
Why an assigned name does not count
The name test has one subtlety that is worth understanding, because it is the part that surprises people. Everyone gets a display name in chat, whether or not they typed one. The runtime assigns something like Visitor 47 so that agents and the monitor have a label to work with.
If a display name alone were treated as engagement, every visitor would qualify and the whole test would collapse. So the assigned placeholders are recognised and skipped: names that begin with the word Visitor or with Guest do not count as a signal. Only a name the visitor supplied does.
This is a good example of why a small implementation detail is worth publishing. Nobody could deduce it from the interface, and it changes what an empty visitor list means.
Once a record exists, it keeps being refreshed
The gate applies to creating a record, not to updating one. Once a visitor has a record, later visits refresh it whether or not they engage again, which is what keeps the last-seen timestamp honest and lets retention rules measure recency correctly.
Refreshes are also protective about identity. If a later, thinner snapshot arrives without an email address or a name, the values already captured are kept rather than blanked. A visitor who gave you their email during one chat does not lose it by browsing anonymously next week.
What the record actually holds
A record is keyed to your site and to an internal visitor key, so the same returning browser lands on the same row. Alongside identity fields for name, email and company, it carries first-seen and last-seen timestamps, a session count, and a bundle of attributes from the visit: the page title and address, the referrer, browser and platform, language, the pre-chat question, the department, and any custom data your own code attached.
The attribute bundle is current context, not an audit trail: it describes the visit, and it is not a log of every page a visitor has ever seen. If you need the history of what was said, that is what the transcript is for.
Writing all of this is deliberately a side task. If the store cannot be reached, the visitor's chat carries on regardless; a failure to record somebody must never be allowed to interrupt talking to them.
What this means for segments and reports
Three practical consequences follow. The first is that your saved visitor count is not your traffic count and never will be. Comparing it to analytics sessions will always look alarming and always be meaningless.
The second is that the population you segment is already filtered towards people who did something. That is usually what you wanted, but it does mean a segment built on saved visitors describes engaged visitors, not all visitors, and any conversion rate you compute from it has that filter baked in.
The third is the lever. If you want more visitors on the record, give them more chances to engage early: a pre-chat field that asks something worth asking, or attaching what you already know about a signed-in user through your own page code. Both of those trip the engagement test on the first page view rather than the tenth minute.
What to measure
Track new records per week against chats started. If records are barely growing while chats are, something is capturing less than you think, and the usual cause is a pre-chat form nobody fills in. Track the share of records that carry an email address, since that is what makes follow-up possible at all.
And check that returning visitors are landing on their existing record rather than creating new ones. A steady stream of one-session records from people you know are regulars means identity is not carrying across, which is a different problem from engagement and needs a different fix.
Put it into practice
- Stop comparing the monitor to the saved list. They answer different questions.
- Remember the assigned name rule. Visitor 47 is not a name and never counts.
- Ask for one useful thing before the chat if you want records created earlier.
- Attach what you already know from your own pages for signed-in visitors.
- Read segment results as engaged visitors, not as all traffic.
- Watch the email-capture share, because it caps every follow-up you can do.
- Investigate duplicate records for regulars before blaming the engagement gate.
The gate is doing you a favour, even though it shows up as a smaller number than you expected. A visitor list that records everybody is a list nobody reads. Once you know which signals create a record, you can decide deliberately which visitors you want to remember, and then design the first thirty seconds of the chat to make that happen. The field design that does most of the work is covered in collecting visitor details with custom chat fields.