> For the complete documentation index, see [llms.txt](https://help.zaapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.zaapi.com/analytics/how-we-calculate-metrics.md). # How we calculate metrics This page explains the rules that sit underneath **every** number in your Analytics dashboard — how time periods work, how a ticket gets counted, why your historical reports stay stable, and how we handle the tricky cases (reopens, automated replies, AI replies etc.). Each individual page (Overall performance, Team performance, and so on) gives you the exact definition of its metrics. This page is the shared foundation they all build on. *** ### The one rule that explains everything **Analytics is always calculated for the date period you select.** You choose a date range using the picker at the top right of each page. By default it's the **last 7 days**, and you can go back as far as **one year (365 days)** in a single view. A ticket, message, or event is included in a report **only if the event that the metric measures happened inside that date range.** That's the whole model. The subtlety — and the reason two metrics can disagree about the "same" ticket — is that **different metrics watch for different events.** We call this the *anchor event*. | Metric | A ticket counts in the period when… | | ----------------------------- | --------------------------------------------------------------------------------- | | **Tickets created** | the ticket was **created** during the period | | **Tickets replied** | the ticket received **at least one agent reply** during the period | | **Messages sent** | each message was **sent** during the period *(this counts messages, not tickets)* | | **First response time** | the **first agent reply** happened during the period | | **Resolution time** | the ticket was **closed** (its final closure) during the period | | **Closed / Resolved tickets** | the ticket was **closed** during the period and is still closed at period end | | **Open tickets** | the ticket is **still open** at the end of the period | | **One-touch tickets** | the ticket was **closed** during the period | So a single ticket can appear in one metric's count and be absent from another's, depending on which of its events fall inside your selected dates. The worked example at the bottom of this page shows exactly how that plays out. *** ### Your past reports never change This is the most important consequence of period-based counting, and the reason you can trust week-over-week comparisons: **Once a period has passed, its numbers are locked. Anything that happens *****after***** the period does not rewrite it.** A few examples of what that means in practice: * A ticket was **closed** on Friday. It gets **reopened** the following Monday. In last week's report, it still counts as closed — Monday's reopen belongs to *this* week, not last. * You **remove a label** from a ticket after the period ends. The ticket still counts under that label for the period it carried it. * You **reassign** a ticket to a different agent next week. For the closed period, the ticket stays with whoever was the assignee **at period end**. * A ticket is later **marked as spam**. If it was active during the period, it's still counted for that period. The payoff: a number you read today for "last month" will read exactly the same in six months. Nothing drifts. *** ### What's counted and what's ignored **Always excluded from analytics:** * **Spam tickets** * **Internal notes.** Notes between teammates are never counted as replies or as messages sent — these metrics only measure messages your customer actually receives. **Automated and AI replies:** * **Auto-acknowledgements** (e.g. an automatic "Thanks, we've received your message") are **ignored** for First response time. That metric is designed to measure how long a customer waits for a *meaningful* answer, not a receipt. * **AI Agent replies** that actually answer or resolve the customer's question **do count** as a response and a resolution. *** ### Time-based metrics: do we count nights and weekends? **By default, time-based metrics (First response time, Resolution time) measure elapsed clock time — including nights, weekends, and holidays.** If a customer messages at 9pm and you reply when you open at 9am, that's recorded as a 12-hour first response, even though no one was working overnight. *** ### Reopens and multi-issue tickets * **Reopened within the period:** if a ticket is closed and then reopened before the period ends, it counts as **open** at period end, not closed. * **Closed more than once in a period:** counted **once** as closed. * **Resolution time on a reopened ticket:** measured from the first customer message to the **final** closure, no matter how many times it was opened and closed in between. * **Multiple issues in one ticket:** resolution time still runs from the first customer message to the final closure, regardless of how many separate questions were raised. *** ### Time zone All dates and periods are calculated in your **workspace time zone**. *** ### How fresh is the data? * **Period-based pages** (Overall, Team, Sales, Label usage, Ticket fields) update every few hours, so a change you make is reflected within a 2 hour period. * **The Live page** is a real-time snapshot that auto-refreshes every 30 seconds — see Live. *** ### A full worked example Let's follow one WhatsApp ticket through its life and see which metrics pick it up. All times are ICT. **The ticket:** | When | What happened | | ------------------------- | ------------------------------------------------- | | **Mon 1 Jun, 09:00** | Customer (Contact) messages the store on WhatsApp | | **Mon 1 Jun, 09:00** | Auto-acknowledgement sent automatically | | **Mon 1 Jun, 09:25** | Agent **Tom** sends the first real reply | | **Mon 1 Jun – Tue 2 Jun** | A few messages back and forth | | **Tue 2 Jun, 14:00** | **Tom** closes the ticket — resolved | **If your selected period is 1–7 June, this ticket contributes:** * **Tickets created:** +1 (created Monday) * **First response time:** **25 minutes** — measured 09:00 → 09:25. The 09:00 auto-acknowledgement is ignored; we count the time to Tom's meaningful reply. * **Tickets replied:** +1 * **Messages sent:** +1 for each message Tom sent in the period * **Resolution time:** **29 hours** — from the first customer message (Mon 09:00) to final closure (Tue 14:00). This is elapsed time, so it includes Monday night. * **Closed tickets:** +1 * **One-touch:** **No** — Tom sent more than one message. (A one-touch ticket is closed with exactly one agent reply.) **Now change only the period — say you select just Tuesday 2 June:** * **Closed tickets:** +1 and **Resolution time:** counted — the ticket was *closed* on Tuesday, so Tuesday's report claims it. * **Tickets created** and **First response time:** **not counted** — those events happened on Monday, which is outside this period. Same ticket, different period, different numbers — because each metric is anchored to a different event. That's the model in a nutshell. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://help.zaapi.com/analytics/how-we-calculate-metrics.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.