Битрикс24

Не все письма сразу: 7 способов распределить рассылку в Битрикс24 по времени и ящикам

Не все письма сразу: 7 способов распределить рассылку в Битрикс24 по времени и ящикам

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

Решение — распределить отправку: по времени, чтобы письма уходили небольшими порциями, и по нескольким почтовым ящикам, чтобы ни один не упирался в свои лимиты. Но у бизнес-процессов Битрикс24 есть особенность, которая делает эту задачу нетривиальной.

Почему это не так просто, как кажется

При массовом переводе лидов в стадию запускается не один процесс, а тысяча независимых копий. Общей очереди между ними нет: каждая копия ничего не знает о соседях. Поэтому распределение нельзя «раздать сверху» — каждый лид должен сам вычислить, в какую минуту и с какого адреса ему отправиться.

Как распределить отправку по времени с учётом часовых поясов и выходных, мы подробно разбирали в статье Рассылка из Битрикс24 по часовым поясам клиентов. Там же описан механизм «слота»: к времени отправки каждому лиду добавляется сдвиг на 0…N минут, где N — окно рассылки. Здесь сосредоточимся на том, как этот сдвиг и выбор ящика можно вычислять — способов больше, чем кажется.

Способы удобно разделить на три группы: математические, с бизнес-смыслом и с учётом лимитов почтового сервера.

Есть и ограничение, общее для всех способов ниже: в облачном Битрикс24 пауза бизнес-процесса просыпается не в точную минуту, а при ближайшем проходе планировщика, на практике раз в 5–10 минут. Поэтому любой расчёт по минутам в итоге превращается в небольшие пачки писем с интервалом в несколько минут. Размер пачки регулируется шириной окна.

Математические способы

1. Остаток от ID лида

Каждый лид берёт свой ID и делит его на число ящиков или на размер окна отправки (количество минут, в течении которых должны отправляться письма). Остаток от деления числа на N всегда лежит в диапазоне от 0 до N−1.

Ящик = ID − intval(ID / 3) × 3          // 0, 1 или 2
Слот = ID − intval(ID / Окно) × Окно    // 0 … Окно−1

Плюсы. Просто, ничего не нужно хранить, результат предсказуем. Один и тот же лид всегда попадает в один и тот же слот и на один и тот же ящик, это легко проверить заранее хоть в Excel.

Минусы. Распределение ровное «в среднем», а не идеально. Перекос появляется, если закономерность в отобранных ID совпадает с делителем. Например, если в выборку попали только чётные ID, а ящиков два, все письма уйдут с одного.

Когда выбирать. В большинстве случаев. Это хороший способ по умолчанию.

2. Случайное число

Вместо остатка каждый лид получает случайный номер ящика или минуты.

Ящик = rand(0, 2)

Плюсы. Не зависит ни от каких закономерностей в ID.

Минусы. Результат невоспроизводим: при повторном запуске лид уйдёт с другого ящика, и заранее проверить, кто куда попадёт, нельзя. На маленьких партиях перекос заметнее, чем кажется: 30 лидов на три ящика легко разойдутся как 6 / 10 / 14.

Когда выбирать. Когда ID отобранных лидов подозрительно «регулярные», а воспроизводимость не важна.

3. Общий счётчик (строгая очередь)

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

Счётчик = Счётчик + 1
Ящик = Счётчик − intval(Счётчик / 3) × 3
Слот = intval(Счётчик / Темп)

Плюсы. Распределение идеально ровное: каждый ящик и каждая минута получают одинаковое число писем. Темп можно задать точно, хотя из-за планировщика облака письма всё равно уходят пачками раз в несколько минут.

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

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

4. Взвешенные доли

Тот же остаток от ID, но диапазоны раздаются неравными долями. Например, остаток от деления на 10: 0–4 → ящик 1 (50%), 5–7 → ящик 2 (30%), 8–9 → ящик 3 (20%).

Остаток = ID − intval(ID / 10) × 10
Ящик 1, если Остаток ≤ 4
Ящик 2, если Остаток ≤ 7
иначе Ящик 3

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

Минусы. Те же, что у остатка от ID, плюс доли нужно периодически пересматривать.

Когда выбирать. Когда у ящиков разные лимиты или вы постепенно вводите в работу новый адрес.

Способы с бизнес-смыслом

5. Закрепление за клиентом

Номер ящика считается не от ID лида, а от ID компании или контакта.

Ящик = ID_компании − intval(ID_компании / 3) × 3

Плюсы. Компания из рассылки в рассылку получает письма от одного и того же отправителя, даже если у неё несколько лидов. Для переписки это естественнее, а для доставляемости лучше: получатель уже знает адрес, и фильтры доверяют ему больше.

Минусы. Если у лида не заполнена компания, нужен запасной вариант, например остаток от ID самого лида.

Когда выбирать. Когда за рассылкой следует живая переписка и важно, чтобы клиент общался с одним адресом.

6. По правилам, а не по математике

Ящик выбирается по признаку лида: регион или часовой пояс, отрасль, источник. Например, центральные регионы — один ящик, восточные — другой.

Плюсы. У распределения появляется бизнес-смысл: например, у каждого менеджера свой регион, и письма уходят от его имени.

Минусы. Нагрузка неравномерная: она повторяет структуру вашей базы. Если 70% клиентов в одном регионе, ящик закрепленного менеджера отправит 70% писем.

Когда выбирать. Когда отправитель важен для клиента больше, чем равномерность нагрузки.

Способ с учётом лимитов

7. Контроль лимитов ящиков

У каждого ящика есть счётчик отправленных за день и дневной лимит, например в элементе Списка. Перед отправкой процесс проверяет счётчик. Если лимит исчерпан, письмо уходит со следующего ящика или переносится на завтра.

Плюсы. Это единственный способ, который учитывает лимиты напрямую, а не рассчитывает на то, что «в среднем не превысим».

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

Когда выбирать. Только если вы действительно упираетесь в лимиты и получаете блокировки. В остальных случаях это излишняя сложность.

Неочевидная особенность: слот и ящик могут быть связаны

Допустим, вы используете остаток от ID и для слота, и для ящика: окно в 210 минут, три ящика. Письма растянуты по времени и поделены между ящиками, всё работает.

Но 210 делится на 3 без остатка, поэтому номер минуты однозначно определяет номер ящика: в минуту "0" письма уходят только с ящика 1, в минуту "1" — только с ящика 2, и так по кругу.

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

Если связь не нужна, есть два простых решения:

  • выбрать окно, которое не делится на число ящиков, например 200 или 211 минут при трёх ящиках;
  • считать ящик от другой части ID — от результата его деления на окно:
Ящик = intval(ID / Окно) − intval(ID / Окно / 3) × 3

Такая зависимость не видна при тестировании на десятке лидов и обнаруживается, только когда смотришь на журнал реальной массовой рассылки.

Сводка: что когда выбирать

Способ Когда выбирать
Остаток от ID По умолчанию: просто, предсказуемо, достаточно ровно
Случайное число ID отобранных лидов идут с закономерностью, воспроизводимость не нужна
Общий счётчик Нужен точный темп отправки
Взвешенные доли Ящики с разными лимитами или прогрев нового адреса
Закрепление за клиентом После рассылки идёт переписка, важен постоянный отправитель
По правилам Отправитель важен для клиента: регион, менеджер, отрасль
Контроль лимитов Реально получаете блокировки от почтового сервиса

Если коротко: начинайте с остатка от ID. Нужен постоянный отправитель — переходите на закрепление за компанией. Упираетесь в лимиты — добавьте взвешенные доли из настроек. Контроль лимитов имеет смысл, только когда остальное уже не помогает.


Не уверены, какой способ подойдёт вашему процессу? Напишите нам — разберём текущий бизнес-процесс и предложим решение на штатных инструментах Битрикс24. Подробнее о том, как мы автоматизируем процессы, — на странице Разработка и автоматизация.

Читать далее

Рассылка в Битрикс24 с учётом часовых поясов

Рассылка в Битрикс24 с учётом часовых поясов

Статья

Как мы научили бизнес-процесс облачного Битрикс24 отправлять тысячу писем так, чтобы каждый клиент получил своё в рабочее время по своему часовому поясу, не в выходной и не одновременно со всеми.

Читать
Как собрать вебхук внутри бизнес-процесса Битрикс24 без внешнего сервера

Как собрать вебхук внутри бизнес-процесса Битрикс24 без внешнего сервера

Статья

Связать два портала Битрикс24 можно без отдельного сервера: бизнес-процесс сам отправляет REST-запросы, получает ответы и обновляет карточки. Разбираем, как собрать такой вебхук, почему внутри batch значения кодируются дважды и где всё ломается.

Читать
Мультиязычный сайт на CMS Ghost: как разделить дизайн, переводы и оперативные данные

Мультиязычный сайт на CMS Ghost: как разделить дизайн, переводы и оперативные данные

Статья

Когда мы переносили собственный корпоративный сайт с конструктора на Ghost CMS, перед нами встала задача, знакомая многим компаниям, работающим на несколько стр

Читать