медиа про еком + ии
Главная / Материалы
Гайд · CRM-маркетинг

Как проверить CRM-сегмент «два заказа от 5000 рублей каждый»

Редакция Кометы · опубликовано

Проверено: 28 октября 2026

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

Что понадобится

Скачайте архив упражнения и распакуйте в отдельную папку. Внутри — вымышленные заказы, условия, заранее записанные ожидания, код и результаты. Для чтения достаточно текстового редактора или таблицы; для повторного расчёта нужен Python 3.9 или новее со стандартным модулем SQLite. Рабочий запуск и состав файлов описаны в записи упражнения.

Аккаунт CRM, токен и зарубежный платёж не нужны. Упражнение выполняется локально, без сети и платных API, поэтому его можно пройти из России. Ручное время и стоимость труда мы не измеряли; время настройки вашей CRM по этому примеру оценивать нельзя.

1. Запишите, какие именно заказы нужны

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

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

Слово «каждый» здесь относится к двум отобранным заказам, а не ко всем покупкам клиента. В учебном журнале у C01 есть покупки на 5000, 5000 и 1000 рублей: клиент подходит. Если вам нужны люди, у которых вообще все заказы дорогие, это другое условие; отдельно решите, что делать с клиентами без покупок.

2. Не заменяйте количество событий общей суммой

Три похожие фразы задают разные операции. Таблица переводит условия учебного контракта, а не описывает интерфейс конкретной CRM.

Аудитория Что сделать с подходящими по периоду и статусу заказами Что проверять на выходе
A: минимум два заказа от 5000 рублей каждый Оставить заказы от порога; сгруппировать по клиенту; сравнить количество с двумя Количество дорогих заказов, а не всех покупок
B: общая сумма заказов от 10000 рублей Сложить суммы заказов клиента; сравнить с суммарным порогом Итоговую сумму, даже если ни один заказ не дорогой
C: хотя бы один заказ от 5000 рублей Найти хотя бы одно событие от порога Наличие дорогого заказа, без требования второго

В документации Sendsay к условию количества заказов добавляется свойство суммы отдельного события: «Свойства → Сумма → больше или равно → N». Там же поясняется случай, когда каждый из отобранных заказов должен быть не дешевле порога. Это документальный пример вложенного условия, не подтверждение функции создания сегментов нейросетью по русской фразе.

Если нейросеть предлагает готовый фильтр, попросите её отдельно назвать: период, допустимые статусы, условие внутри заказа, способ группировки и условие по клиенту. Затем сопоставьте ответ с таблицей. Промпт помогает разобрать задачу, но не заменяет проверку списка ID.

3. Найдите клиентов, на которых подмена заметна

Откройте ручные ожидания и сравните с заказами. Сначала разберите строки ниже, затем проверьте оставшихся клиентов. Суммы в таблице — рубли; исходные копейки, причины исключений и все результаты находятся в учебных файлах.

Клиент Заказы для разбора A: два дорогих B: сумма от порога C: один дорогой
C01 5000 + 5000 + 1000 Да Да Да
C02 4000 + 3500 + 2500 Нет Да Нет
C03 Один заказ 10000 Нет Да Да
C04 5000 + 4999 Нет Нет Да
C05 Два по 5000 внутри периода; ещё два за его границами Да Да Да
C08 6000 + 4000; точный повтор записи 6000 удалён Нет Да Да
C09 5000 + неизвестная сумма Неизвестно Неизвестно Да
C12 0 + 4999,99 + 5000,01 Нет Да Да

C02 показывает ошибку «сумма вместо количества дорогих заказов». C03 ловит подмену «один дорогой вместо двух». У C04 порог суммы не достигнут, хотя дорогой заказ есть. Для C08 повтор события не должен становиться новой покупкой. Эти случаи и их объяснения записаны в ожиданиях.

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

4. Посчитайте и сравните три списка

Запустите из папки распаковки:

python3 reference.py

Скрипт создаёт результаты в той же папке. Откройте файл verification.json: ожидаются status: pass, manual_python_sqlite_comparisons: 36 и passed: 36; в results.csv — три ответа для каждого клиента. Полный порядок и назначение выходных файлов — в записи упражнения.

Полученные списки ниже относятся ко всему учебному списку клиентов, включая клиента без заказов. Источник всех строк — результат расчёта.

Условие Подходит Недостаточно данных
A: два дорогих заказа C01, C05 C09, C10
B: общая сумма от порога C01, C02, C03, C05, C08, C12 C09, C10
C: хотя бы один дорогой C01, C03, C04, C05, C06, C08, C09, C12 C10

Если исходные данные полны, суммы неотрицательны и пороги те же, A влечёт B и C. Обратное неверно: это видно на C02 и C03. Условие про все покупки потребует отдельной проверки; его нельзя незаметно добавить в этот расчёт.

5. Разберите пропуски до переноса фильтра

У C09 одного известного дорогого заказа достаточно для C, но недостаточно для ответа по A или B. У C10 есть запись без времени и сумма в другой валюте; скрипт не придумывает дату и курс. Такие строки перечислены в карантине. «Неизвестно» не означает «не подходит»: сначала восстановите данные, затем пересчитайте.

Ошибка Что исправить Как проверить исправление
Один заказ засчитан дважды Считать уникальные order_id; точный повтор убрать, конфликтующие версии разобрать C08 не должен попасть в A из-за копии события
Пустая сумма заменена нулём Вернуть признак неизвестности, запросить сумму Для C09 сохранить неизвестность A и B до получения данных
Граница периода посчитана иначе Использовать начало включительно, конец исключительно и один часовой пояс Сопоставить четыре события C05 с периодом
Деньги округлены раньше сравнения Считать целые копейки и согласовать округление при импорте Для C12 получить ровно суммарный порог

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

Перед переносом в CRM проверьте полноту выгрузки. В справке Sendsay сказано, что сегментация зависит от переданных с сайта клиентских событий и данных; для «Продажи Старт» там указана история последних 48 часов. Наш учебный период не означает, что такое окно доступно в любом тарифе. Сначала выясните глубину истории своего аккаунта, затем выбирайте период.

В рабочей системе сравнивайте ID на обезличенной контрольной выборке и причины включения, а не только итоговый счётчик. Настройка и проверка реальной CRM остаются следующим самостоятельным действием. Если задача другая — проверить остановки сообщений после оплаты, пригодится разбор CRM-цепочки.

Как мы проверяли

Редакция заранее задала вымышленные заказы и ручные ожидания, затем выполнила расчёт на Python и SQLite. В наборе — 12 клиентов, 28 строк и 27 уникальных заказов; все 36 сопоставлений трёх условий совпали. Повторный запуск в день проверки на Python 3.14.4 из распакованного архива дал те же выходные файлы. Полные входы, условия и результаты сохранены в записи упражнения.

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

Источники

Редакция Кометы

Сообщить об ошибке