Автоматическая сегментация клиентов в Битрикс24: кейс Pasionaria

В Pasionaria автоматизировали три поля контакта в Битрикс24: покупательский сегмент, активность и принадлежность к розничному направлению. Для каждого поля согласовали отдельное правило. Затем проверили расчёт на реальных сделках и поэтапно обновили карточки.

В основном рабочем прогоне обработали 7 335 контактов и изменили 358. Ниже — почему одинаковая история может давать разные значения трёх полей, как бизнес проверял спорные случаи и как поддерживают результат в работающей CRM.

Здесь важен не сам алгоритм “1 покупка — новый клиент”. Главное — как превратить меняющиеся правила бизнеса в систему, которую можно безопасно проверить на реальной CRM и только потом включить в работу.

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

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

На этом этапе стало понятно, что “сегмент клиента”, “активность” и “тип контакта” нельзя рассчитывать одним условием. Они отвечают на разные бизнес-вопросы и должны жить независимо друг от друга.

Сегмент зависит от числа засчитанных розничных покупок. При нуле покупок поле остаётся пустым. После первой покупки появляется «Новый клиент», после двух-трёх — «Повторный клиент», после четырёх и более — «Постоянный клиент». Образцы, услуги и пустые сделки сами по себе число покупок не увеличивают. Полный возврат и отмена не считаются покупкой; при частичном возврате покупка учитывается, поскольку часть заказа остаётся у клиента.

Активность рассчитывается независимо от покупок. При наличии хотя бы одной открытой розничной сделки клиент активный. Если открытых сделок нет, берётся дата закрытия последней финальной розничной сделки: успешной, неуспешной или возвратной. Прошло менее года — клиент активный; год или больше — неактивный. Состав сделки значения не имеет: учитываются и пустые розничные сделки.

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

Тип контакта “Розничный” — третье независимое правило. В финальной версии достаточно наличия хотя бы одной существующей сделки в розничной воронке, независимо от её статуса и состава. Если таких сделок больше нет, снимается именно тип “Розничный”; другие типы система не пытается назначать или переписывать сама.

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

Бизнес мог открыть тот же контакт в Bitrix24, посмотреть его историю и сравнить результат расчёта с тем, как этот случай должен трактоваться по смыслу. Именно на таких проверках несколько правил изменились ещё до массовой загрузки.

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

Другой пример — тип “Розничный”. В одной из промежуточных версий мы связывали его с состоявшейся покупкой. После обсуждения выяснилось, что бизнес вкладывает в поле другой смысл: если у контакта вообще есть розничная сделка, значит он относится к розничному направлению. Это изменение затрагивало состав выборки, поэтому смысл поля уточнили до массовой записи.

После согласования пограничные сценарии не остались только в переписке. Их закрепили отдельными автоматическими проверками: пустая сделка, сделка только с образцами, открытая розничная сделка, частичный возврат, другая воронка, отдельные даты покупки и активности, установка и снятие типа “Розничный”.

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

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

В одном из финальных прогонов снимок включал 14 256 розничных сделок и 7 335 уникальных контактов. Товарные строки запрашивались только для тех стадий, где они действительно нужны для расчёта сегмента, что сократило лишние обращения к API.

Полный тестовый прогон по 7 335 контактам показал, что реально изменить нужно только 358, а 6 977 уже находятся в правильном состоянии. В этом прогоне ошибок расчёта не зафиксировали. Дополнительно проверили состав изменений: они касались именно тех полей, ради которых менялась логика, и не “расползались” на соседние показатели.

Даже после полного расчёта без записи переход к рабочей CRM шёл поэтапно. Сначала проверили отдельные контакты, затем небольшие серии, после этого первые 100 записей и только потом запустили массовую обработку.

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

В отдельном контрольном прогоне первые 100 контактов дали ровно тот результат, который предсказал тест без записи: 46 изменений и 54 уже корректные карточки. Повторная проверка после записи показала 100 совпадений из 100.

Обновление нескольких тысяч контактов занимает время, а внешнее API может временно отвечать с ошибкой. Поэтому массовый процесс сохранял состояние после каждого контакта. Если запуск прерывался, его можно было продолжить без повторной записи уже обработанных карточек.

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

В результате полный рабочий запуск практически повторил предварительный расчёт: из 7 335 контактов изменились те же 358. Почти все остальные были пропущены как уже соответствующие правилам. Один единичный сбой ответа Bitrix24 затем проверили отдельно — он не оказался ошибкой алгоритма.

После изменения правила для типа “Розничный” появилась важная отрицательная проверка. Если строить список только по контактам, у которых сейчас есть розничные сделки, невозможно увидеть людей, у которых тип “Розничный” остался со старых времён, а розничных сделок уже нет.

Отдельной проверкой нашли 27 таких контактов. Сначала для всех выполнили расчёт без записи, убедились, что требуется только снять старый тип и не менять другие данные, затем обновили их и повторно проверили результат. Контроль после обработки показал, что устаревших значений больше не осталось.

CRM продолжает жить даже во время массовой обработки: менеджеры создают и меняют сделки. Поэтому старый снимок нельзя считать окончательной истиной после нескольких часов работы.

После массового запуска мы отдельно “догнали” изменения, произошедшие за это время. Один из таких проходов увидел 413 изменённых сделок, отобрал 57 релевантных розничных и пересчитал связанные контакты. Большинство уже не требовало изменений, несколько карточек были обновлены. Повторный проход практически ничего не менял — то есть повторная обработка была безопасной и не создавала лишних обновлений.

После первоначального пересчёта значения должны оставаться актуальными. Для этого не стали каждый раз заново пересчитывать всю CRM.

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

• Раз в сутки отдельно проверяется переход из “Активного” в “Неактивный”: здесь данные могут устареть просто из-за течения времени, даже если ни одна сделка не менялась.

• Ещё одна фоновая сверка отслеживает структурные изменения — например, удаление сделки, перенос между воронками или изменение связей между сделкой и контактом.

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

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

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

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

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

Для своего проекта попросите команду показать на нескольких контактах, какие сделки повлияли на каждое поле. Затем согласуйте полный расчёт без записи: сколько карточек изменится, какие значения будут поставлены и как проверят результат. Эта последовательность даёт бизнесу возможность подтвердить правила до массового изменения клиентской базы.

Предыдущий этап проекта — связка программы лояльности с сайтом, 1С и CRM. Он описывает, как согласовали покупки, бонусы и клиентские данные между каналами.