WhatsApp analytics: what to track beyond message counts

A logistics client showed me their WhatsApp dashboard last year. Twelve thousand messages delivered that month, 98% read rate, the green number was up 30% on the previous month. Then I asked a simple question: how many of those conversations ended with a customer who had their answer?

Nobody knew. The dashboard was measuring traffic, and traffic is the one number that goes up when things break, because a customer who did not get an answer comes back three times to ask.

Why message counts feel like progress

Delivered, sent, read, and reply counts are easy to pull. The Business Platform hands them to you in webhook events, they fit on one line, and they move. That is exactly the problem. Every one of those numbers counts activity, not outcome.

A few concrete ways volume rises while service falls:

• Repeat questions. The same customer asks the same thing four times because nobody closed the loop. That is four sent, four delivered, four read.
• Template blasts to people who did not ask. Marketing templates sent to a purchased list deliver fine and get reported as reach, then the quality rating drops a week later. I have written about what actually moves the quality rating and it is never the send count.
• Bot loops. A keyword bot stuck in a fallback loop generates plenty of events and zero resolutions.
• Retries after failures. Failed sends that the system retries quietly inflate the total. You can spot this by counting status values instead of sends, which is covered in the errors post.

So the first rule I apply: any number that a bad week makes bigger is not a metric, it is a log line.

The four numbers worth a weekly page

I keep this to four because a page nobody reads is worse than no page. These four answer the only question that matters operationally: are customers getting answered, and what does each answer cost.

1. First reply time on inbound conversations

Not average across all messages, because outbound templates are instant and pull the average into fantasy. Take inbound conversations only, and measure the gap between the customer's first message and the first human or meaningful bot reply.

Then look at the shape, not the mean. A median of four minutes with a tail of eleven hours is a very different business from a median of forty minutes across the board. The tail is where customers leave. Group it in bands: under five minutes, five to thirty, thirty to four hours, over four hours.

This one number tells you whether you need more staff at a specific hour, or a bot that covers the gap, or nothing at all. Most teams discover the problem is between 7pm and 9pm and a single evening shift fixes it.

2. Resolution without a callback

How many conversations ended without the customer phoning, emailing, or messaging again within 48 hours about the same thing?

You cannot measure this perfectly, but you can measure it usefully. Tag each conversation when it closes: resolved, escalated to a call, escalated to another team, abandoned. The percentage marked resolved, divided by total closed conversations, is the number I would put in front of an owner before any volume chart.

A team sending twice as many messages with a resolution rate of 41% is losing to a team sending half as many at 78%.

3. Template-to-action rate, per template

For utility templates: did the recipient do the thing? A payment reminder counts a payment, not a delivery. An appointment reminder counts a confirm or a reschedule, not a read. A delivery update counts a completed drop, not an opened message.

Track it per template and per category, because a template that reads well can still perform badly: wrong send time, wrong variable, a button that does not resolve to anything. And check the denominator honestly. Sending 500 reminders and getting 300 confirmations is a 60% rate only if all 500 were still live bookings. Cleaning the list first is part of the number.

4. Cost per resolved conversation

Take your platform and per-conversation message costs and divide by the number of resolved conversations from metric two. This is the number your accountant would ask for, and it is the one that makes a conversation-based pricing model either reasonable or expensive depending on how messy your threads are.

If you have never mapped your spend to categories, WhatsApp Business Platform costs in India covers what each category actually bills at. The point here is not the tariff, it is that a cheap message to the wrong person is expensive once you divide by resolutions.

Where the data actually lives

Three sources, and teams usually only look at the first:

• Webhook status events. Sent, delivered, read, failed, with error codes. This is your delivery truth. Anyone reporting from their own send log instead is reporting intent.
• Your conversation store. Tags, close reasons, assigned agent, timestamps. If your provider's shared inbox archives conversations, this is where resolution data comes from. If it does not, you need to write those tags yourself, and that is a product requirement rather than a nice-to-have. The shared inbox guide covers why two people answering one number without a queue quietly destroys your response-time data.
• Your own business system. Payments received, orders shipped, appointments kept. Without this you can only measure what happened in WhatsApp, and half the outcome happens outside it.

The join is the hard part, and it is worth doing. A template ID tied to an order ID is what turns "we sent 400 payment reminders" into "we collected 61% of overdue invoices in seven days".

Traps that make clean data lie

I have been caught by all four of these.

Testing traffic in production numbers. Every team has a staging number that sends to real inboxes during setup, and a few colleagues who message the bot to see if it works. Filter them before anything reaches a report, or your first month of data is fiction.

Read receipts that are not receipts. Read status on WhatsApp means the message was opened, not understood. It is a delivery signal. Never put it next to a conversion figure and imply a relationship.

Timezones. A daily report cut at midnight UTC will attribute an Indian evening shift to the previous day and make a good team look inconsistent. Fix the reporting timezone to the business's own, once.

Opt-outs counted as engagement failures. Someone blocking or opting out is a real signal, but it belongs in a different chart from answerability. Word it carefully in any report you show a client: high opt-out on marketing is a targeting problem, not a service problem. The mechanics of keeping consent provable are in the opt-in post.

A weekly page you will actually read

One table, five rows, compared against last week. First reply median and tail, resolution rate, template conversion for your top three templates, cost per resolved conversation, and open conversations older than 24 hours. That is it. No message totals.

If you want one place to start, start with the open-conversations-older-than-24-hours row. It is trivially easy to compute, it catches the failures that every other metric averages away, and it usually drops by half in the first week once someone is actually looking at it.

Where BNex fits

BNex is the WhatsApp Business Platform product I build, and this piece is the measurement checklist I would hold any WhatsApp setup to, whichever provider runs it. The mechanics of delivery status, templates and the 24-hour window are Meta's and they are the same everywhere. What differs between platforms is whether conversations stay in one visible place with an owner, which is the precondition for every number above. The provider comparison guide sets out the questions to ask about exactly that, and the pricing guide covers what a conversation actually bills at.

If your monthly report currently starts with a message count and you cannot say how many conversations got resolved, send me your last month's totals on WhatsApp and I will tell you which of the four numbers you can produce today and which one you would need to add a tag to get.

Related Reading