Поиск «серой» рассылки в SaleBot

В этой статье рассмотрим кейс, как мне удалось исправить последствия неудачно отправленной рассылки с серого блока в SaleBot.

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

Главное в подобных ситуациях не поддаваться панике. Не спешите, не суетитесь. Никакой катастрофы не происходит. Важно быстро среагировать и остановить рассылку, а дальше уже устранять последствия уже свершившегося факта. Ну и по возможности не допускать подобных промахов. Однако человеческий фактор никто не отменял.

Остановили рассылку. Что дальше? Конечно же после остановки рассылки, логично было бы перезапустить заново. Но как перезапустить. В нашем случае было известно об отправке около 2000 сообщений. Было бы неплохо установить масштабы бедствия, какому кол-ву пользователей в целом ушла рассылка. Попутно было бы неплохо исключить из новой рассылке тех пользователей, кому рассылка уже была отправлена и бонусом — сэкономить немного суточный лимит сообщений.

В целом, по правилам, рассылки в SaleBot делаются либо в меню рассылок, что в целом не очень практично. Либо в сером блоке «Не состояние». Преимуществ использования серого блока достаточно много. Удобнее подготовить, удобнее протестировать рассылку и при необходимости, легко найти и повторить. Технически рассылку можно отправлять с любого типа блоков. Однако использовать белые и разношерстные зеленые блоки не желательно, так как они могут «выбить» пользователей с тех воронок по которым они движутся. Серые же блоки позволяют отправлять сообщения не нарушая логику цепочки сообщений в воронке.

Однако на практике не все так гладко. Отправляя рассылки с белых блоков есть возможность скопировать ID блока, а затем, используя фильтр «Блоки воронки», выделить всех пользователей, кто находится в этом блоке. Далее уже можно уточнить по каналам коммуникаций по спискам и т.д и более точно скорректировать ошибку.

Но с серым блоком «Не состояние» такой трюк уже не прокатит. Однако есть решение. В конструкторе SaleBot есть огромное множество условно скрытых возможностей. Одна из таких «фишек» это возможность просмотреть историю переходов пользователя по блокам воронки. Но это нельзя сделать силами самого конструктора. Чтобы добраться до этой информации, необходимо сделать выгрузку пользователей с раздела «Клиенты».

Получившуюся выгрузку загружаем на Google-диск и открываем.

Больше всего в этой выгрузке нас интересует столбец «История переходов по блокам». В данной истории, как ни странно, учитываются и серые блоки. Используя поиск по тексту, мы узнаем общее число пользователей, которые получили рассылку с текущим блоком. В примере это 5874 чел. Уже что-то.

Далее переходим к столбцу «Мессенджер». Нажимаем на него правой кнопкой и создаем фильтр. Далее в этом фильтре выбираем запретограм.

Затем повторяем наш трюк с поиском по ID блока и получаем кол-во пользователей, которые получили сбойную рассылку. Аналогичным образом можно выбрать и Telegram и заново через поиск посчитать кол-во рассылок. Но можно поступить и проще. С общего числа упоминаний ID блока с рассылкой отнять найденные сбойные. В нашем примере 5874 — 1024 = 4 854 сообщения были отправлены корректно.

И так, мы определили масштаб бедствия. Что дальше? А дальше нам нужно запускать рассылку далее по корректной базе и попутно исключить пользователей, которым эта рассылка уже была отправлена. Для этого нужно выбрать все client_id, они же ID в первой колонке таблицы и создать список в SaleBot на основе этих ID. На этом статью можно было бы, наверное, заканчивать. Так как все дальнейшие манипуляции я проводил используя API SaleBot. Подгружал данные базу данных Mongoose используя MongoDB Compass, писал модель данных, код и ….

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

Но есть альтернативный путь. О нём и поговорим. На текущий момент мы разобрались, что вся задача сводится к тому, что бы каким-то образом выбрать все client_id у которых в столбце «История переходов по блокам» имеется ID-блока с рассылкой и в которых в столбце «Мессенджер» указан Telegram.

Для решения этой задачи я решил попробовать использовать Google-таблицы. Данные там уже загружены к этому моменту. Задача сводится к выборке нужных данных. Я перепробовал массу способов, но выбор пал на функцию QUERY таблиц. Её прелесть в том, что можно указать диапазон данных в которых функция собирает данные, можно указать, какие данные нужно получить на выходе и гибко задать условия выборки, используя синтаксис языка SQL. Этот синтаксис используется в основном для работы с базами данных. Но тем не менее отлично работает и в Google таблицах.

Вот общий синтаксис функции QUERY:

В общем виде моя тестовая формула в Google-таблицах выглядит следующим образом:

Разберем по подробнее:

‘clients-2024-05-11.csv’! —  название ЛИСТА(!) таблицы в котором находятся данные выгруженные с конструктора.

A1:AG — диапазон входных данных для функции запроса. Начиная с А1 двигаемся вправо до столбца G и выбираем все данные, которые есть в этих столбцах.

select A,B,G where G like ‘%29611449%’ AND B = ‘Telegram’ — непосредственно сам SQL-подобный запрос. Он переводиться буквально следующим образом ВЫБЕРИ (столбцы) A, B, G ТАМ ГДЕ (столбец) G содержит (строку) %29611449% И (столбец) B равен (строке) Telegram.

После вставки формулы с запросом на новый лист, получается новая таблица следующего вида:

Если внимательно присмотреться, то в столбце C можно обнаружить как строгое соответствие с ID нашего блока 29611449, так и тех клиентов, у которых нужный нам ID находится среди прочих.

Раз мы убедились, что все необходимые данные есть, и они у нас корректные, можно убрать из запроса лишние столбцы. Напомню, нас интересуют только данные в столбце А (ID).

Корректируем формулу.

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

Скачиваем результат нашей работы обязательно в формате CSV. После переходим в SaleBot, создаем список. Находим только что созданный список и нажимаем кнопку «Добавить в этот список». В открывшемся окошке выбираем режим загрузки «Клиенты из файла».

Обратите особое внимание на настройку этой формы. Кодировку необходимо переключить на UTF-8, в качестве разделителя выбрать точку с запятой, а также отключить опцию сохранения новых клиентов WhatsApp. Если всё ок, жмем кнопку Browse и выбираем CSV-файл который скачали с Google-таблиц.

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

Таким образом, используя выгрузку SaleBot (которую, кстати, всегда рекомендую делать в CSV-формате), Google-таблицу с помощью формулы QUERY и какой-то матери можно исправить практически нерешаемую ситуацию, если рассылка «улетела» не в те каналы. А также оценить масштаб бедствия и предпринять другие шаги. Допустим при большом кол-ве ошибочных рассылок в запретограме (удалить их не получится) выпустить сторис с информацией о возникшей проблеме. А если отправка прошла не в тот бот Telegram, то ошибочные сообщения можно удалить используя серый блок с функцией remove_last_message() в калькуляторе.