# Analytics

> Read conversation volume, channel mix, agent workload, and voice performance in the console — and know exactly what each figure counts before you act on it.

Source: https://docs.amomic.in/console/analytics

---

Analytics answers one question: how much customer demand arrived, where it came from, and how well your agents met it. It is a read-only view of activity in the active workspace, available to every role.

It is deliberately about **demand and workload**, not money. For what you have consumed against your plan, see [Limits and plans](/operate/limits) and [Credits and billing](/operate/credits).

![The Analytics page for 7 days: Conversations 1,846, Messages 18,021, Avg messages 9.8, Unique visitors 1,408, three insight cards, a stacked conversation-volume chart by channel from 8 to 14 Oct, and Peak period, Top channel and Preview traffic cards](https://docs.amomic.in/screens/analytics/overview.light.webp)

*Analytics for a seven-day range. Every figure is recomputed when you change the range or the agent filter.*

::: note Analytics is not the Home figure
**Conversations** here counts conversation threads that *started* in the range. **Conversations** on [Home](/console/home#the-four-figures) is the billing meter for the current cycle, where one long thread can count as more than one AI conversation. Expect the two to differ.
:::

## The two controls

Everything on the page is driven by two controls in the header.

- **Range** — `24h`, `7 days`, `30 days`, or `90 days`. The default is 7 days. The range is a rolling window ending now, not a calendar period: "30 days" means the last 30 days, not this month.
- **Agent** — **All agents**, or one agent. The dropdown appears only when the workspace has more than one agent. Selecting one narrows every card on the page to conversations and calls handled by that agent.

Neither control is stored in the URL, so an analytics view cannot be bookmarked or shared as a link. Take a screenshot or export the numbers you need.

## The four headline figures

| Figure | What it counts |
|---|---|
| **Conversations** | Conversation threads that started inside the range. A thread that began before the range and continued into it is not counted. |
| **Messages** | Every message in those conversations — the customer's, the agent's and your team's replies — added together. Operational trail rows are not counted. |
| **Avg messages** | Messages ÷ conversations, to one decimal. A proxy for how much back-and-forth an answer takes. |
| **Unique visitors** | Distinct people behind those conversations. |

::: note
**Conversations are counted by when they started.** This is the single most common source of confusion when a figure looks lower than expected. A long-running WhatsApp thread that has been active for a week appears once, on the day it opened — not on every day it received a message. Compare **Messages** across ranges when you want a picture of ongoing activity.
:::

### How "unique visitors" is worked out

On web and WhatsApp, a visitor is the identity attached to the conversation — the widget visitor or the customer's phone number. On voice, it is the **calling number**, taken from the call records rather than from the conversation.

That distinction matters. On the phone, a conversation *is* a call, so a voice conversation carries the call id and not a person. Counting it would make three phone numbers that called nine times look like nine callers. The figure therefore counts callers, and someone who reaches you on both WhatsApp and the phone counts once per channel identity, not once as a person — [contact identity](/console/contact-memory) is where those are joined, not here.

## Conversation insights

Three cards sit under the headline figures.

- **Conversations per visitor** — how often the same person comes back inside the range. Consistently above 1 usually means either loyal customers or unresolved first attempts; the [Tickets](/console/tickets) queue tells you which.
- **Messages per visitor** — total messages divided by unique visitors.
- **Leading agent** — the agent with the most conversations, and how many it handled. The *top channel* shown next to it is the workspace's busiest channel in the range, not necessarily that agent's.

All three show `—` when there is no traffic to divide by, rather than a misleading zero.

## Conversation volume

A stacked area chart of conversations over time, one band per channel.

- On the **24h** range the buckets are **hourly** (*Hourly activity*); on every other range they are **daily** (*Daily activity*).
- Buckets are **UTC**, so a "day" on this chart runs midnight to midnight UTC — 5:30 a.m. to 5:30 a.m. IST. An evening spike in India lands where you expect it; a late-night one may appear on the next bucket.
- The series is zero-filled, so a quiet day is drawn as a gap at zero rather than skipped. A flat line means no traffic, not missing data.
- Only channels with traffic in the range are drawn.

![Analytics on the 24h range: 241 conversations, an hourly volume chart labelled 7am to 5am, and a peak period of 2026-10-13 · 06:00](https://docs.amomic.in/screens/analytics/24h.light.webp)

*On 24h the chart is hourly. The hour labels are UTC: 5am on the axis is 10:30 a.m. in India.*

On the **24h** range the axis labels are UTC hours too, written as `7am`, `1pm` and so on, without a time zone. Add your offset to read them — for India, add five and a half hours.

Beside the chart, three summary cards read the same data:

- **Peak period** — the busiest bucket in the range, and how many conversations it held. It reads as a date such as `2026-10-12`, or a date and an hour such as `2026-10-13 · 06:00` on the 24h range; the hour is UTC, like the chart.
- **Top channel** — the channel with the most conversations, written as the channel's internal name (`Whatsapp`, `Web`, `Voice`).
- **Preview traffic** — see below.

### Preview chats are excluded

Conversations from the console's agent **Test** tab are testing, not customer demand. They are excluded from every figure on this page — conversations, messages, visitors, the chart, and both breakdowns.

They are not hidden, though: the count is reported in the **Preview traffic** card and in the chart's subtitle. If you have spent an afternoon testing an agent and the page still says there was no customer traffic, that card is the explanation.

## Voice performance

![Lower half of Analytics: Voice performance with 62 in and 38 out badges, 100 calls, talk time 227:53, 86% completion and 1.1s median response, then Agent performance listing four agents and Channel mix with WhatsApp 48%, Web 38% and Voice 14%](https://docs.amomic.in/screens/analytics/voice-and-mix.light.webp)

*Voice performance reads the latest 100 calls; the two breakdowns read the same conversations as the rest of the page.*

Four figures over the calls in the range: **Calls**, **Talk time**, **Completion**, and **Median response**. Badges on the card split the calls into `in` and `out`.

- **Completion** is the share of calls that ended normally — the caller hung up, the agent hung up, or the call completed — rather than failing to connect or dropping. The [Calls](/console/calls) page groups call endings its own way, so don't expect its counts to reproduce this percentage exactly.
- The `in` badge counts every call that wasn't placed outbound by an agent, so calls a team member placed from a [ticket](/console/tickets) are counted as `in`.
- **Median response** is the median of each call's typical turn latency: how long the agent took to start answering after the caller stopped speaking. The median, not the average, so one pathological turn does not move the number.
- **Talk time** is the total, shown as minutes and seconds — `227:53` is 227 minutes 53 seconds. It is answered time. Ringing is not talk time, so an unanswered call adds nothing here. See [Calls and call-backs](/console/calls#talk-time-versus-ringing).

::: warning
**This card reads a sample, not the whole range.** It is built from the most recent **100 calls**, which are then filtered to the selected range. If the workspace made more than 100 calls, the header says `latest 100-call sample` and the figures describe those calls only — on a 90-day range that can be a small and recent slice.

Treat it as a health check on how voice is behaving right now. For a complete history, use the [Calls](/console/calls) page, which pages through every record.
:::

## Agent performance and channel mix

Two breakdown cards close the page.

**Agent performance** lists each agent with its conversation count, its share of the total, its message count, and its average messages per conversation. An agent deleted after handling traffic still appears, as `Deleted bot`, so history does not silently rewrite itself.

**Channel mix** lists each channel with conversations and share. Shares are of conversations, not messages — a voice channel with few but long calls looks small here and large on the [Calls](/console/calls) page. Both are true; they measure different things.

## Per-deployment usage lives with the agent

Analytics answers the workspace-level question. When you need to know **which touchpoint** the traffic reached — this WhatsApp number versus that one, the website widget versus the pricing-page widget — open the agent and use **Usage by touchpoint** on its **Deployments** tab. See [Deployments](/build/deployments#usage-by-touchpoint).

## Before you trust a number

::: steps

::: step Check the workspace
Every figure is scoped to the active workspace. A page that looks empty is very often the wrong workspace — see [Console overview](/console/overview#the-organization-menu).
:::

::: step Check the agent filter
It persists while you stay on the page. A surprisingly small chart is sometimes one agent's traffic rather than the workspace's.
:::

::: step Check the preview count
If the **Preview traffic** card is non-zero and the rest of the page is near-empty, you have been testing, not receiving customers.
:::

::: step Check the volume of the range
A range containing more than **5,000 conversations** is truncated: the page aggregates up to 5,000 conversation records per range and no more. Figures for a very busy 90-day window will therefore under-report. Narrow the range — or the agent — until you are under that ceiling, and the numbers become exact again.
:::

:::

## What Analytics does not do

Being explicit, because these are the things people look for here first:

- **No export.** There is no CSV or scheduled report. If you need the data in your own system, pull it over the API — [Conversations](/api/conversations) for threads and messages, [Calls](/api/calls) for call records — and aggregate it yourself.
- **No period-over-period comparison.** The page shows the selected range only; there are no "vs. previous period" deltas.
- **No revenue, cost, or credit figures.** Those live in **Billing**. See [Credits and billing](/operate/credits).
- **No ticket or campaign reporting.** Ticket workload is on the [Tickets](/console/tickets#the-tracker) tracker; campaign delivery is on the [campaign report](/campaigns/overview#following-a-running-campaign).

## Live updates

The page refreshes as new conversations and calls arrive while it is open, so a range you leave on screen stays current without a reload.

## Related

::: cards

::: card Calls and call-backs
[Every call record](/console/calls) — outcome, recording, transcript, and origin.
:::

::: card Deployments
[Usage by touchpoint](/build/deployments#usage-by-touchpoint) — which number or widget the traffic actually reached.
:::

::: card Limits and plans
[What your plan includes](/operate/limits) and what happens at the ceiling.
:::

::: card Conversations API
[Read the underlying data](/api/conversations) and build your own reporting.
:::

:::
