Разделить базу по алфавиту кажется самым простым способом - взял первую треть, отдал первому номеру. На практике это создаёт неравномерную нагрузку и ломает логику коммуникации. Разберём, как делить базу по смыслу, а не по порядку строк в Excel, и почему синхронная отправка одного текста с нескольких номеров - это риск независимо от того, как именно его детектирует Meta.
Было: база делится по алфавиту, порядку в CRM или просто пополам - кажется, что это «справедливо» и быстро.
Стало: база делится по смыслу - регион, ниша, тип клиента - а скорость нарезки уступает место логике сегментации - см. сегментацию базы. Деление по алфавиту не нарушает какое-то конкретное правило Meta - оно создаёт практические проблемы: перекосы по регионам и операторам связи внутри одной пачки, неудобство управления и потерю истории общения с клиентом.
Главная проблема алфавитной или последовательной сортировки - не мистическая детекция Meta, а структурная: такая нарезка группирует однотипные записи. Однотипные названия компаний, фамилии одного региона или контакты, добавленные в CRM в одну сессию, оказываются в одной пачке.
Это создаёт две проблемы. Первая - операционная: вы теряете контроль над тем, какой сегмент реально получает какой аккаунт. Вторая - техническая в широком смысле: если в одной пачке концентрируются номера одного оператора или региона, нагрузка на эту группу неравномерна по времени и гео, что увеличивает риск всплеска жалоб именно с этой пачки - см. механику банов.
Ручная нарезка в Excel простой сортировкой по строкам оставляет, по наблюдениям практиков, до 15–25% скрытых хронологических или региональных склеек номеров - это практический ориентир, не официальный показатель. Настоящая рандомизация требует прогона базы через функцию случайных чисел (=СЛЧИС() / =RAND()) перед нарезкой на сегменты, а не сортировки исходного списка - см. A/B-тест и рандомизацию.
Распределение базы решает не задачу «поровну», а задачу «логично». Рабочие критерии деления:
Стандартный подход в WhatsApp-маркетинге - разделять аудиторию минимум на три сегмента для разных типов сообщений: информационные, персонализированные, опросные. Это не специфика антибана, а общая логика сегментации, которая работает независимо от того, сколько у вас аккаунтов.
Среди операторов есть спор о том, как распределять отправку внутри пула номеров - см. когда заводить второй аккаунт.
| Подход | Логика | Главный риск |
|---|---|---|
| Round-Robin | Каждое следующее сообщение уходит со следующего случайного аккаунта в пуле | Один клиент при повторном касании получает сообщение с другого номера - рвётся история чата и доверие |
| Закреплённые сегменты | Конкретный сегмент базы навсегда привязан к конкретному номеру-донору | Если номер банят, весь сегмент остаётся без канала до восстановления |
Единого мнения здесь нет. Round-Robin даёт более размытый паттерн автоматизации с точки зрения инфраструктуры, но ломает узнаваемость отправителя для клиента. Закреплённые сегменты сохраняют историю общения, но концентрируют риск на одном номере.
В моей практике для долгих воронок (когда клиента дожимают несколько касаний) закреплённый номер почти всегда выигрывает - потеря узнаваемости стоит дороже, чем теоретическая размытость паттерна - см. дожим vs первое сообщение. Round-Robin имеет смысл только для разовых холодных рассылок без повторного контакта.
Здесь нужна точная формулировка. Утверждение «Meta вычисляет MD5/SHA-256 хэш текста и банит сетку аккаунтов» - это форумная гипотеза, а не подтверждённый механизм работы антиспам-системы Meta. Официальных данных о том, как именно сопоставляются сообщения между независимыми аккаунтами, не публикуется.
Но практический вывод остаётся в силе: синхронная отправка идентичного текста с нескольких номеров по разным базам - это повышенный риск с точки зрения практиков, независимо от точного технического механизма детекции.
Мини-кейс провала. Маркетолог подключил 5 свежих номеров к автоматизации, скопировал один рекламный текст со скидкой и ссылкой во все 5 потоков и запустил отправку одновременно по общему списку из Excel - см. скидку в первом сообщении. Через 12 минут все 5 аккаунтов были синхронно заблокированы. По наблюдению оператора, антифрод-система связала рассылку в единый паттерн именно из-за совпадения текста и ссылки на одном временном отрезке.
Мини-кейс успеха. Поставщик стройматериалов разделил 3000 холодных контактов на три рандомизированных сегмента, закрепил их за тремя прогретыми номерами и на каждом использовал свой уникальный текст со спинтаксом, адаптированный под нишу - без пересечений по содержанию - см. структуру первого сообщения. Скорость отправки держали на уровне одного сообщения в 3 минуты. За неделю пул аккаунтов прошёл всю базу и собрал 8% целевых лидов без блокировок.
Форумные кейсы, публичной верификации методологии нет.
Что нельзя писать как факт: что три одинаковых текста с разных номеров гарантированно приводят к бану, что существует подтверждённый порог «3–5 аккаунтов = бан за 10–20 минут», или что Meta официально использует MD5/SHA-256 для этого. Это операторские наблюдения, а не задокументированные правила.
Частое заблуждение: тег {{name}} делает текст уникальным на каждом аккаунте. Изменение одного слова меняет техническую сигнатуру строки, но не меняет структуру предложения. Если скелет текста идентичен на всех номерах, по наблюдениям практиков, риск склейки в один паттерн остаётся.
Реальная уникализация требует разной структуры предложения на каждом потоке, а не просто переменной с именем.
Если несколько номеров одновременно отправляют один и тот же URL, по практическим наблюдениям это повышает риск даже сильнее, чем повторяющийся текст: ссылка - самый заметный спам-маркер для систем мониторинга. Практический приём - использовать сервисы коротких ссылок или разные UTM-параметры на каждом потоке, чтобы итоговый URL визуально отличался между аккаунтами.
То же касается медиафайлов: незначительное изменение размера изображения или добавление прозрачного водяного знака превращает файл в технически другой объект для систем сравнения контента.
Если вы работаете через WhatsApp Business Platform (API), распределение базы между разными номерами обычно не нужно ради объёма - один номер легально масштабируется по системе уровней (Tier) до десятков и сотен тысяч диалогов в сутки - см. сколько аккаунтов реально нужно и обзор WABA. В WABA несколько номеров (WABA-ID) имеют смысл для:
Деление базы между номерами в WABA - организационное решение, а не способ обойти лимиты отправки.
Прежде чем нарезать базу, выпишите критерий сегментации (регион, ниша или тип клиента) и проверьте текущую CRM-выгрузку на одном из вариантов - посмотрите, группируются ли контакты не по смыслу, а по случайным признакам вроде алфавита.
Практическое правило:
База делится по смыслу бизнеса, а не по порядку строк - и текст на каждом потоке должен звучать по-своему, а не отличаться только именем клиента.
