Агентство запустило рассылку по купленной базе на 10 000 номеров. Софт успел отправить только 40 сообщений - 18 из них ушли в статус «не доставлено». На 41-м сообщении аккаунт с двухлетней историей и высоким трастом получил перманентный бан. Причина - не текст и не время отправки, а сама база, и это можно было увидеть за 15 минут до старта.
Большинство гайдов про WhatsApp-рассылки разбирают текст сообщения, время отправки, прогрев номера - и почти никогда саму базу. А именно база чаще всего решает, доживёт ли рассылка до второго дня. «Мёртвая» база - это не один признак, а сумма из возраста контактов, источника, доли мобильных номеров и истории активности, и большинство этих сигналов видно ещё до отправки первого сообщения. Дальше - какие признаки токсичной базы стоит проверять, как провести экспресс-аудит за 15 минут и на каком показателе недоставок останавливать тест.
Под этим словом обычно скрывают пять разных проблем, и их стоит различать, потому что обнаруживаются они по-разному.
| Тип проблемного контакта | Что это значит | Как обнаружить |
|---|---|---|
| Invalid | номера нет в WhatsApp (нет JID) | валидатор / Cloud API |
| Inactive | аккаунт есть, но человек им не пользуется | официально не определяется - Meta даёт только бинарный ответ «зарегистрирован / нет», без данных о последней активности |
| Duplicate | повторяющийся контакт | дедупликация перед импортом |
| Стационарный/факсовый | номер физически не может быть в WhatsApp | HLR-запрос, срез по типу номера |
| Ошибка формата | номер не соответствует стандарту E.164 | автоматическая проверка длины и маски |
Шаг 1. Формат и дубли. Проверка на соответствие E.164 и удаление дублей - это гигиена данных, а не WhatsApp-специфика. Удаление дублей в Excel закрывает только эту часть: программа не умеет определять, мобильный это номер или стационарный, и тем более не проверяет наличие аккаунта.
Шаг 2. Валидация через чекер. Официальный путь - метод проверки контактов в Cloud API в рамках WABA, возвращающий статус valid или invalid - подробнее в разборе WABA. «Серый» путь - скрипты на библиотеках вроде Baileys или whatsapp-web.js, опрашивающие сокет методом onWhatsApp(). Облачные сервисы с пулами регистраторов способны провалидировать базу из 10 000 номеров за 5–15 минут. Бесплатные чекеры с форумов сюда не годятся - кроме нестабильности из-за обновлений протокола, они нередко забирают проверяемые номера в свои собственные базы - логика та же, что при переносе базы из другого мессенджера.
Шаг 3. HLR-запрос. Определяет, активна ли SIM-карта и какой это тип номера - мобильный, стационарный или виртуальный. Наличие городских номеров в базе - почти всегда прямой маркер парсинга, а не органического сбора контактов.
Шаг 4. Срез по операторам и регионам. Хаотичная смесь кодов из десятков регионов без понятной географической или коммерческой логики на форумах автоматизаторов называют маркером «купленного мусора». Официального подтверждения, что Meta анализирует это распределение как часть антиспам-алгоритма, нет - относитесь к этому срезу как к собственной эвристике для принятия решения, а не как к подтверждённому сигналу системы Meta.
| Метрика | Что измеряет | Ориентир |
|---|---|---|
| Quality Rating | сводная репутация номера в WABA | желательно ≥ 0,80 |
| Bounce Rate | доля недоставленных сообщений в целом по аккаунту | ≤ 2% спокойно, > 10% - серьёзный сигнал проблем |
| Complaint Rate | доля жалоб от получателей | желательно ≤ 0,1% |
| Failed Rate на тесте новой базы | доля недоставок на первых отправках именно по свежей базе | многие практики считают безопасным уровень < 5% |
| P95 времени доставки | задержка отправки сообщений | до 3 секунд - признак нормальной нагрузки |
Bounce Rate и Failed Rate на тестовой выборке - не одно и то же. Bounce Rate - это общий показатель аккаунта во времени, Failed Rate на первых 50 сообщениях - диагностика конкретно новой базы перед стартом. Путать их - частая ошибка при разборе своих метрик - см. A/B-тест как методологию контролируемого теста.
Официальный WABA не спасает от последствий плохой базы: высокий Failed Rate не приводит к мгновенному автоматическому удалению номера, но проседает Quality Rating, из-за чего Meta может заблокировать рекламные шаблоны или урезать дневной лимит отправки до 250 сообщений - это подтверждённая механика, а не предположение.
Базу никогда не запускают целиком. Стандартная практика - тестовая выборка примерно в 50 сообщений с отдельным контролем Failed Rate, прежде чем масштабировать рассылку на остальную базу - см. первое холодное сообщение как логику тестового касания.
Если на тестовых 50 отправках доля статусов failed превышает 30%, рассылку стоит немедленно остановить и менять базу. Это не официальное правило Meta, а широко цитируемый практиками стоп-сигнал - но цена ошибки здесь высокая, поэтому к нему стоит относиться серьёзно.
Между «безопасным» уровнем (<5%) и стоп-порогом (>30%) есть серая зона. Это не повод паниковать, но повод насторожиться, сократить темп отправки и присмотреться к источнику базы внимательнее, прежде чем продолжать - см. механику банов и поведенческий антиспам.
| Провальный сценарий | Рабочий сценарий | |
|---|---|---|
| База | 10 000 номеров, купленная база интернет-магазина, собрана 2 года назад | 5 000 номеров, спарсенная b2b-база от подрядчика |
| Аудит перед стартом | Не проводился | Валидатор отсеял 1200 стационарных, 400 с ошибками формата, 800 без WhatsApp - осталось 2600 чистых номеров |
| Что произошло | 18 из первых 40 сообщений - failed, бан на 41-м сообщении несмотря на двухлетний траст номера | Тестовый запуск - доставка 98%, блокировок шаблонов или аккаунта не было |
Разница не в качестве номера-отправителя - он был одинаково «прогретым» в обоих случаях. Разница в том, что одна база прошла аудит до запуска, а другая нет.
Официальные инструменты Meta дают только бинарный ответ - зарегистрирован номер в WhatsApp или нет. Данных о последней активности пользователя, частоте использования приложения или давности захода в сеть в открытой документации нет и не предусмотрено. Любые утверждения о «доле активности базы» сверх этого бинарного статуса - это допущения, а не то, что реально можно проверить технически.
Чаще всего номер сгорает не из-за текста или времени отправки, а из-за одного и того же набора решений: рассылка по купленной базе без проверки её происхождения, пропуск этапа валидации «чтобы не терять время», запуск сразу по всей базе вместо тестового сегмента, использование случайных бесплатных чекеров для холодной базы. Распределение рассылки между несколькими аккаунтами эту проблему не решает - мёртвая база сожжёт любой из них, просто по очереди - см. экономику рассылки, где «дешёвая база» часто оборачивается самым дорогим пунктом.
Прежде чем запускать следующую рассылку, прогоните текущую базу через валидатор и зафиксируйте процент invalid и стационарных номеров. Если он окажется неожиданно высоким - это и есть ответ на вопрос, почему предыдущий запуск показал себя хуже, чем ожидалось.
Практическое правило:
Текст сообщения можно переписать после первой жалобы. Бан из-за мёртвой базы переписать нельзя - поэтому аудит базы идёт до старта, а не после первых проблем.
