There are two tables behind the screen
Analytics here is stored twice, in two shapes, for two different jobs.
The first is an append-only event stream. Every meaningful action adds one row: a ticket created, a ticket resolved, a first response posted, a help center search that returned nothing, an article marked helpful, an AI answer generated, an escalation to a human. Each row carries its type, who did it, what it was about, and often a number, such as the seconds elapsed before a first reply or the latency of a provider call. Writing to it is cheap. Scanning it across a date range is not.
The second is a rolled-up table, keyed by site, day, metric and bucket. It holds one row per metric per day, with a count, a sum and an average already worked out. This is the table every chart and headline figure on your dashboard actually reads. No part of the analytics screen queries the raw stream directly.
Almost everything else on this page follows from that split.
The rollup is rebuilt while you wait
There is no nightly job. Nothing runs on a schedule to keep the rolled-up table current.
Instead, opening the analytics screen rebuilds it first. The page recomputes recent days from the raw stream, then reads the freshly written rollup and draws itself. The window is at least the last fourteen days, more if the range you selected is longer, and hard-capped at ninety days regardless.
This is a deliberate trade and it has two consequences you can feel. The good one is that your numbers are never stale: what you see includes the ticket that was resolved a minute ago, because the rollup for today was rebuilt on the way to drawing the page. The cost is that the analytics screen does real work before it renders, so it is slower than screens that only read. That gap widens with volume, and on a busy account a wide range takes noticeably longer than a narrow one.
If the rebuild fails for any reason, the page still renders from whatever the rollup already contained. You get a dashboard rather than an error, which is the right call and does mean a persistent failure would show up as numbers that quietly stop moving rather than as a broken page.
Reloading cannot double-count anything
The natural worry about recomputing on every page load is that the totals inflate as people refresh. They do not, and the reason is worth stating because it is what makes the design safe.
A rebuild does not add to what is there. For each day it rebuilds, it deletes that day's rolled-up rows and writes them again from the raw stream, both inside one transaction. The result depends only on the events in the stream, never on how many times the rebuild has run. Ten people opening the dashboard at once produce exactly the same numbers as one person opening it once.
That also means the rolled-up table is disposable. It is derived data, and if it were ever wrong, opening the page over the covered window would repair it. The stream is the record; the rollup is a cache with a rebuild button attached to the front door.
One number on the page comes from somewhere else
Nearly every figure on the screen is a straight count of events of one type on one day. The conversations figure is not, and this is the most important thing on this page to know.
It is derived instead from the AI transcript table, by counting the distinct chat sessions that recorded a message that day. It works this way because AI-handled conversations already write a transcript row, so the count could be built without instrumenting the chat framework separately.
The consequence is direct: conversations handled entirely by human agents, with no AI involvement at all, are not counted by that path. On an account where AI answers most first messages the figure is close to the whole picture. On an account where AI is off, or limited to out-of-hours, it measures a fraction of your real conversations and does not say so.
So compare that number to itself over time rather than treating it as your total chat volume, and be careful about ratios built on top of it. Anything divided by conversations inherits the same blind spot, and a per-conversation rate can look like it moved when what actually changed was how much of your traffic the AI touched. Your chat reports remain the place to answer how many conversations you had.
Tracking never breaks the thing that called it
Recording an event is best-effort by design. If the write fails, the failure is swallowed and the action that triggered it carries on. Resolving a ticket must not fail because an analytics row could not be written, and it does not.
That is obviously the right priority and it costs you one thing: silence and absence look identical from the dashboard. If the analytics tables are not deployed on your installation, every write quietly does nothing and every read comes back empty, and the screen shows a tidy set of zeros rather than telling you it has nothing to read from.
So treat an all-zero analytics screen as ambiguous rather than as bad news about your week. Check whether other screens that read the same stream are also empty. A dashboard with real ticket activity and zero analytics is a deployment question, not a performance one.
The visitor map is the other view on the dashboard where empty means missing input rather than missing activity, and for an unrelated reason: it needs something upstream to resolve a country before it can plot anything at all. Why your visitor map pins people in the middle of a country covers what it is really showing.
Event types are plain strings rather than a fixed list, capped at eighty characters. Adding a new kind of event needs no schema change, and the rollup picks it up automatically, because it groups by whatever types it finds in the stream that day.
This is why the metrics on the screen have grown over time without migrations, and it explains a small thing you may notice: a metric can simply start existing partway through your history. A rollup row is only written for a day when there was something to count, so a chart that begins mid-series usually means the event started being recorded then, not that your activity started then.
When you are comparing a period before and after such a change, that distinction is the difference between a real trend and an artefact of instrumentation.
How MyLiveChat fits
The short version is that your analytics screen reads a derived table, rebuilds it while you wait over at least a fortnight, cannot double-count no matter how often it is loaded, and carries one count that measures AI-touched conversations rather than all of them.
Knowing which numbers are counted events and which one is derived differently is most of what you need to read the screen honestly. When a figure here disagrees with a figure elsewhere, that difference is usually the explanation rather than a fault.
Why your live chat numbers do not add up covers the other reasons two reports disagree, and what your CSAT number is actually counting applies the same scepticism to satisfaction. If you would rather work from the raw stream than the rolled-up view, getting live chat data into your own reporting is the route out.