Как сверять отчёты о доставке кампаний WhatsApp

Надёжный отчёт о кампании WhatsApp начинается с отдельной записи для каждого исходящего сообщения получателю. Затем каждое событие статуса связывается с этой записью по ID сообщения. Сохраняйте время события и исходную информацию об ошибке. Не выбирайте последнее состояние по порядку прихода вебхуков, потому что Meta предупреждает, что уведомления могут прийти не в порядке самих событий.

Практический вопрос прост. Может ли команда объяснить судьбу каждого запланированного сообщения, не переписывая доказательства после кампании? Рабочее пространство кампаний должно показывать этот ответ, а не только несколько красивых итогов.

Справочник вебхуков WhatsApp от Meta определяет sent как получение сообщения сервером WhatsApp, delivered как доставку получателю, read как чтение, а failed как неудачную отправку. Это разные события.

Создайте запись для каждого сообщения

Создавайте строку отчёта, когда исходящая попытка принята вашим процессом отправки. Храните кампанию, предполагаемого получателя, тип шаблона или сообщения, время попытки и ID сообщения WhatsApp. Meta указывает, что сообщения имеют уникальные идентификаторы, а статусы отслеживаются через вебхуки.

Отделяйте внутреннее решение об аудитории от результата платформы. Контакт, исключённый до отправки из-за согласия, списка подавления, дубля или правила сегмента, не получил ошибку WhatsApp. Он вообще не был отправлен платформе. Поэтому процесс кампании WhatsApp должен отдельно показывать исходную аудиторию, подходящую аудиторию и отправленные платформе сообщения.

Не объединяйте повторные попытки. Обоснованный повтор можно связать с той же кампанией и получателем, но ему нужен новый ID. Иначе одна последующая доставка скроет раннюю ошибку и улучшит вид первой попытки.

Храните исходные события статуса

Добавляйте события в журнал, а не перезаписывайте одно поле. Сохраняйте ID сообщения, статус, время события Meta, время получения и объект ошибки при failed. Такой журнал позволяет восстановить отчёт, если вебхук задержался или пришёл повторно.

Обработка должна быть идемпотентной. Повтор того же события не должен второй раз увеличивать счётчик. Ключ может объединять ID сообщения, статус и время события, а контрольная сумма исходной нагрузки пригодится для аудита. Доступ к журналу следует защищать через модель безопасности и разрешений.

Документация Meta об обновлениях статуса говорит, что успешные сообщения дают уведомления sent, delivered и read, и предупреждает, что порядок уведомлений в приложении может не отражать фактическое время. Значит, время является частью факта.

Сверяйте по времени события

Сортируйте события каждого сообщения по времени внутри уведомления. Время получения храните для контроля задержек, но не позволяйте ему откатывать состояние назад. Если read попал в базу раньше delivered, сохраните оба события и покажите хронологию их временных меток.

Определите момент закрытия отчёта. Текущий отчёт можно пометить предварительным, пока события продолжают поступать. Позже зафиксируйте датированный снимок, не удаляя опоздавшие данные. Если позднее событие меняет итог, запишите время пересмотра, чтобы разница между выгрузками была понятна.

Называйте знаменатель каждой доли

Процент имеет смысл только с явным знаменателем. Доставка среди переданных платформе сообщений отвечает на вопрос о транспорте. Чтения среди доставленных описывают зарегистрированное чтение того, что дошло. Эти доли не объясняют размер подходящей аудитории и полезный результат.

Показывайте количества рядом с долями. Иначе невозможно понять, сократилась ли аудитория, изменились ли исключения или поздние события передвинули знаменатель. Указывайте часовой пояс и момент закрытия. Нельзя честно сравнивать кампанию через двенадцать часов с кампанией через три дня.

Ответы, встречи и покупки относятся к отдельному уровню результата. Связывайте их обоснованным ID кампании или разговора, а не считайте read конверсией. Общий inbox сохраняет разговор после доставки, а правила автоматизации направляют возникшую работу. Журнал статусов остаётся доказательством доставки, а не бизнеса.

Исследуйте ошибки без переписывания истории

Статус failed может содержать объект ошибки. Сохраните его, сгруппируйте записи по коду или деталям и проверьте небольшую выборку до выбора действия. Иногда нужно исправить шаблон или настройку, иногда данные контакта либо решение об исключении. Массовый повтор способен повторить ту же проблему.

Записи без последующего статуса вынесите в отдельную очередь. Сначала подтвердите ID сообщения, подписку нужного WhatsApp Business Account на вебхуки и приём уведомлений конечной точкой. Затем проверьте журнал обработки и дедупликацию. Не превращайте неизвестное в sent, delivered или failed только ради баланса.

Назначьте владельца каждой группе исключений. Менеджер кампании отвечает за аудиторию, инженер за пробелы вебхуков, клиентские операции за ответы. Так отчёт ведёт к действию, не меняя исходную историю.

Превратите отчёт в решение

Проводите сверку до оценки креатива. Сначала спросите, есть ли у каждого переданного сообщения объяснимое состояние или открытое исключение. Затем изучите группы ошибок, задержку событий и различия сегментов. Только после устойчивой транспортной картины интерпретируйте чтения, ответы и результаты.

DripTell может объединить активность кампании, историю поддерживаемых разговоров и владельцев в одном рабочем контексте. Возьмите недавнюю кампанию и сверите сообщения со сводкой. Если итоги нельзя объяснить, исправьте правило до следующей крупной отправки. Реальную кампанию можно использовать на демонстрации DripTell.

Часто задаваемые вопросы

Чем sent отличается от delivered

Sent означает, что сервер WhatsApp получил сообщение. Delivered означает, что оно дошло до получателя. Для вопроса о доставке используйте delivered.

Что делать с вебхуками не по порядку

Храните все события и сортируйте их по времени в уведомлении. Время получения используйте для наблюдения за каналом, но не позволяйте порядку прихода стирать более поздний факт.

Нужно ли автоматически повторять failed

Не как общее правило. Сохраните ошибку, сгруппируйте причины и сначала исправьте источник проблемы. Повтор должен стать новой связанной попыткой с собственным ID.