Features

Analytics and delivery logs

What was sent, what failed, and, the question stores actually have, what was skipped and why.

There are two different questions, and they are answered in two different places. "How are we doing?" is Analytics. "Why didn't this one customer get their message?" is the delivery log, and that is the question that actually gets asked.

Analytics

The Analytics screen covers a rolling 7, 14 or 30 days and can be filtered to one number.

The headline metrics

Field	Required	Type	Description
Total Messages	No	count	Everything in and out over the period.
Delivery Rate	No	percent	Share of outbound messages Meta confirmed as delivered. A rate well below your peers usually means wrong numbers, not a platform problem.
Read Rate	No	percent	Share confirmed as read. Read receipts depend on the recipient's settings, so this floor is not zero-error.
Contacts	No	count	Total contacts across your address books.

Below those:

Daily Volume, outbound, inbound and read, stacked per day, with per-day figures on hover.
By Type, message counts split by type, so you can see how much of your traffic is templates versus free-form replies. Useful as a rough cost proxy, since templates are what you pay for.
Conversation Status, open, pending, bot-handled and resolved.
Bot Performance, executions and completion rate per flow. A flow with many executions and a low completion rate is one people are abandoning part-way.
Agent Performance, conversations assigned, resolved and messages sent, per team member.
Message Flow Summary, sent, received, delivered and read as absolute counts.

The Analytics screen with four metric cards across the top, a stacked daily volume chart, a by-type breakdown, and conversation status and bot performance panels below. — Delivery and read rates are the two numbers worth watching week to week.

The message log

Logs in the dashboard is the platform's own record of what went through it: time, direction, recipient, message type and status, twenty rows at a time, filterable by number.

Status values in the dashboard log

Field	Required	Type	Description
sent	No	status	Accepted by Meta. This is the default state a row is written in.
delivered	No	status	Meta confirmed delivery to the handset.
read	No	status	Meta confirmed the recipient opened it.
failed	No	status	Meta rejected or could not deliver it.

Status updates arrive asynchronously, so a message read back immediately after sending usually still shows sent. Individual messages can also be checked over the API with GET /v1/notifications/status/:messageId, see the Notifications API.

The delivery log, and why skips matter

The store integrations keep a richer log, because they are where a message can be decided against before the platform is ever called. This is the one to open when a customer says they got nothing.

WhatsApp → Logs in wp-admin. Every row records the event, the recipient, the status, the WhatsApp message id, the channel, an error code, an error message, the resolved variables, the source, and the order it belongs to.

Filter by status, Any status, Sent, Failed, Skipped, Queued, or search by recipient, message id or error message. The dashboard has a direct Only failures link.

Rows are kept for Keep logs for days, log_retention_days, default 30, range 1 to 365, and older ones are deleted hourly.

Individual orders also carry a WhatsApp notifications panel on the order screen showing the last fifteen rows for that order, with a Resend link on each.

The skip reasons, exactly

In WooCommerce these are the strings that appear in the log's error message column against a skipped row. They are written to be read by a shopkeeper, not a developer.

Why a send was skipped

Field	Required	Type	Description
No usable phone number for this customer.	No	no_recipient	The recipient tag resolved to nothing, usually an order placed without a billing phone.
Recipient has opted out of WhatsApp messages.	No	no_consent	The number is on the opt-out register. This beats every consent mode and every category.
Customer declined WhatsApp updates.	No	no_consent	The customer explicitly unticked the opt-in box at checkout or on their account page.
Marketing messages need an explicit opt-in and this customer has not given one.	No	no_consent	A `MARKETING` event with no recorded opt-in, while the marketing opt-in requirement is on. The usual reason abandoned cart sends nothing for guests, see Abandoned cart recovery.
Consent mode is set to "explicit opt-in required" and this customer has not opted in.	No	no_consent	Consent mode is “required” and this customer never opted in.
Stopped by a wac_should_send filter.	No	filtered	Your own code, or another plugin, vetoed the send through the filter hook.
Customer replied with an opt-out keyword.	No	opt_out	Filed against the inbound STOP itself, so you can see when a customer opted out and from which message.

Reading a problem end to end

Find the row in the delivery log
Search by the customer's number. If there is no row at all, the event is switched off, the plugin is not connected, or the message was suppressed as a duplicate.
Read the status
Skipped means a decision was made not to send, the reason column tells you which. Failed means it was attempted and Meta refused. Queued means it is still waiting. Sent means it left.
For a failure, read the error code
Meta error 133010 means the number is not registered on the Cloud API, every send fails until that is fixed. A template error means the template is not approved for that number.
For a send, check the delivery status
A row marked sent that never became delivered usually means the number is not on WhatsApp, or is wrong. Compare against the dashboard's delivery rate to see whether it is one customer or a pattern.
Check for a warning on a successful row
A delivered row can still carry Delivered, but these variables were empty: …. The customer got the message with a literal - where the value should have been, the merge tag resolved to nothing.

What is never logged

One-time codes: Every variable of an AUTHENTICATION event is masked before the row is written, and the COD handler overwrites the row again afterwards. A near-miss in a log is a hint at the real code, so failed attempts record the count and not the value. See Cash on delivery confirmation.
Raw IP addresses: Rate-limit counters key on a hash rather than the address itself.
Inbound message floods: Inbound logging is capped at 60 rows per number per hour. Past the cap the message is still acted on, STOP still works, only the log row is skipped.

Cost

Reading logs and analytics costs nothing. A skipped send costs nothing either. The platform is never called, so no credit is reserved. A failed send is refunded automatically. Only a message that actually left is billed. See Credits and billing.

Loading…