Want help applying this guide?Ask the DripTell team
A trustworthy WhatsApp campaign report starts with one record for every outbound recipient message, then attaches each status event to that record by message ID. Keep the event timestamp and raw failure detail. Do not decide the latest state from the order in which webhooks reached your system, because Meta says those notifications may arrive in a different order from the events themselves.
The operational question is simple. Can the team explain every intended message without changing the evidence after the campaign? A campaign workspace should make that answer visible.
Meta's WhatsApp webhook reference defines sent as received by the WhatsApp server, delivered as delivered to the recipient, read as read by the recipient and failed as a send failure. Those are different events. Treating them as interchangeable is how a report becomes reassuring but useless.
Start with one record per message
Create the reporting row when your sending workflow accepts the outbound request. Store the campaign, recipient, message type, attempt time and returned WhatsApp message ID. Meta documents that messages have unique IDs and can be tracked through webhooks.
Keep your audience decision separate. A contact excluded before submission because of consent, suppression, duplication or an audience rule did not fail at WhatsApp. It was never sent to the platform. A WhatsApp campaign process should show requested audience, eligible audience and submitted messages separately.
Give every justified retry its own message ID while linking it to the same campaign and recipient. One later delivery must not hide an earlier failure.
Keep the raw status events
Append status events instead of overwriting a single status field. Store the message ID, status, Meta event timestamp, receipt time and any error object that accompanies a failed state. The raw log lets you rebuild the report when a webhook is delayed, retried or processed twice.
- 1Capture the message IDTie every outbound recipient attempt to the identifier returned for that message.
- 2Store every eventKeep the raw status, event timestamp and failure detail without overwriting earlier evidence.
- 3Order by event timeUse the status timestamp because webhook arrival order can differ from event order.
- 4Reconcile the totalsCompare the audience, accepted messages and observed final states with named denominators.
- 5Review exceptionsInvestigate missing and failed records before changing a contact or retrying a send.
Make ingestion idempotent so the same event cannot increase a counter twice. An event key can combine message ID, status and event timestamp. Protect the evidence through your security and permissions model.
Meta's status update documentation says successful messages produce sent, delivered and read notifications, and warns that notification order in your application may not reflect the actual timing. The timestamp is therefore part of the fact, not decoration.
Reconcile by event time
Sort events for each message by the timestamp inside the status notification. Keep receipt time as a monitoring field so you can find delayed webhook processing, but do not let receipt order move a message backwards. If read arrives before delivered in your database, the report should still preserve both events and present the chronology indicated by their timestamps.
Set a reporting cutoff. Mark a live report provisional while events still arrive, then freeze a dated snapshot without deleting late evidence. If a late event changes the final state, record the revision time.
| Evidence in the report | What it proves | What it does not prove |
|---|---|---|
| Outbound request with message ID | WhatsApp assigned an identifier to that message | The recipient device received it |
| Sent status | The WhatsApp server received the message | The message was delivered or read |
| Delivered status | The message reached the recipient | The recipient understood or acted on it |
| Read status | A read event was reported for that message | The campaign caused a reply or sale |
| Failed status and error | The send failed with recorded failure detail | Every other recipient has the same problem |
Use denominators that answer clear questions
Every percentage needs a named denominator. Delivery among submitted messages answers a platform delivery question. Reads among delivered messages describe reported reading among messages known to have arrived. Neither answers how much of the original audience was eligible, nor whether the campaign created useful customer action.
Publish counts beside rates so people can see whether the audience, exclusions or late events changed. Keep timezone and cutoff visible. Comparing one campaign at twelve hours with another at three days is not fair.
Replies and purchases belong to a separate outcome layer. Join them through a campaign or conversation identifier rather than treating read as conversion. A shared inbox preserves the later conversation, while automation rules route the resulting work.
Investigate failures without rewriting history
A failed status may include an error object. Preserve it, group failures by the recorded code or detail and inspect a small recipient sample before choosing an action. One cause may justify fixing a template or configuration. Another may require correcting data or leaving the contact suppressed. A blanket retry can repeat the same mistake.
Put missing status evidence in a separate queue. Confirm the message ID, webhook subscription and endpoint receipt, then check ingestion and duplicate handling. Never turn unknown into sent, delivered or failed just to balance totals.
Assign every exception group. Campaign managers can own audience rules, engineers webhook gaps and customer operations replies. Do not alter source history.
Turn the report into campaign decisions
Review reconciliation before creative performance. First ask whether every submitted message has an explainable observed state or an open exception. Then examine failure clusters, late-event lag and differences between campaign segments. Only after the transport evidence is stable should the team interpret reads, replies or outcomes.
DripTell can bring campaign activity, supported conversation history and ownership into one operating view. Reconcile one recent campaign against its summary. If the totals cannot be explained, fix the reporting rule before the next large send. A DripTell demonstration can use that campaign as the test case.
Frequently Asked Questions
What is the difference between sent and delivered
Sent means the WhatsApp server received the message. Delivered means the message reached the recipient. Use delivered, not sent, when answering whether the platform reported arrival.
What if WhatsApp status webhooks arrive out of order
Keep every event and order them by the timestamp in the status notification. Preserve receipt time separately to monitor your webhook pipeline, but never let arrival order erase a later event.
Should failed messages be retried automatically
Not as a blanket rule. Preserve the failure detail, group the recorded causes and correct the underlying problem first. Any retry should be a new linked attempt with its own message ID.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy