Поведенческие сигналы для SMS: как запускать триггеры без дублей
Поведенческие сигналы для SMS — это конкретные события и рассчитанные признаки, которые запускают коммуникацию: брошенное действие, повторная покупка, окончание ресурса или длительная неактивность. Материал не повторяет общий гайд по сегментации базы: его задача — показать технические правила триггеров и остановки.
Событие и сегмент
Событие происходит в момент времени: просмотр, заказ, оплата, отмена. Сегмент описывает состояние: покупал дважды за 90 дней, не заходил месяц, использовал 80% лимита. Триггер может сочетать оба вида данных.
Поля события
Нужны пользователь, тип, время, объект, источник и уникальный идентификатор. Для исправлений используют версию или событие отмены. Без идентификатора повторная загрузка способна запустить второе SMS.
Давность, частота и ценность
Вместо пола и города поведение показывает актуальный интерес. Однако признаки рассчитываются в контексте продукта. Месяц без визита может быть нормой для редкой услуги и сигналом для ежедневного SaaS.
Зафиксируйте окно расчёта и дату обновления. Сегмент без времени быстро становится неверным.
Пример правила
«Клиент начал оформление, не завершил его за 30 минут, не оплатил другим способом, не обращался в поддержку и не получал аналогичное SMS семь дней».
Вы не завершили оформление заказа №418. Корзина сохранена до 20:00: [ссылка]. Если помощь не нужна, сообщение можно проигнорировать.
Такое правило точнее сегмента «все с брошенной корзиной», потому что содержит стоп-условия и частоту.
События отмены
Оплата, возврат, закрытие заявки, отказ и смена тарифа должны закрывать активный триггер. Проверка выполняется перед отправкой, даже если аудитория уже сформирована.
Если данные приходят с задержкой, задайте безопасный буфер. Лучше отправить немного позже, чем напомнить о действии после его завершения.
Приоритет конфликтующих правил
Один человек может одновременно попасть в возвратную, платёжную и продуктовую цепочку. Создайте таблицу приоритетов и исключений. Сервисный статус обычно важнее рекламного предложения, а открытая претензия подавляет стандартную акцию.
Общий контроль выполняет политика частоты SMS.
Интеграция
Хранилище событий или CRM публикует сигнал, движок правил формирует кандидата, повторно проверяет состояние и вызывает HTTP API QUICKTEL. Идентификатор коммуникации связывает правило, версию и результат.
Согласия и минимизация данных
Поведенческая точность не отменяет необходимость основания для конкретной коммуникации. Не используйте чувствительные признаки и не раскрывайте в тексте подробности, которые человек не ожидает увидеть на экране телефона.
Храните только необходимые события и ограничивайте доступ аналитиков и подрядчиков.
Контрольная группа
Часть подходящей аудитории не получает SMS. Сравнение показывает добавочный эффект, а не просто покупки людей, которые и так собирались вернуться. Заранее определите размер, период и целевое действие.
Качество событий
До запуска проверьте полноту, задержку и порядок данных. Если оплата поступает в хранилище через несколько часов, триггер брошенного оформления будет ошибаться независимо от качества текста. Постройте отчёт по событиям, которые были отменены запоздалым фактом.
Схема события версионируется. Новое название или формат поля не должно молча обнулить сегмент. Потребители данных переходят на версию после теста.
Объединение профилей
Поведение одного человека может храниться под cookie, телефоном, email и аккаунтом. Правила слияния должны быть прозрачными и осторожными. Нельзя автоматически приписывать человеку действия другого пользователя общего устройства.
После подтверждённого объединения пересчитываются признаки и частота контактов. Активные триггеры-дубли закрываются, остаётся одна коммуникация с понятным источником.
Каталог правил
Для каждого триггера храните владельца, версию, условие, исключения, срок полезности, шаблон и метрику. Правило без владельца отключается. Изменение порога проходит тест на исторических данных, чтобы оценить размер аудитории и конфликты.
Ручная кампания по поведенческому сегменту использует тот же каталог и стоп-проверки, что автоматический worker.
Проверка и метрики
Протестируйте повтор события, запоздалую оплату, два устройства, объединение профилей, отказ и конфликт правил. Измеряйте добавочное действие, сообщения после стоп-события, дубли, отказы и стоимость результата.
Начните с одного события с явным намерением и коротким сроком. Только после проверки расширяйте набор признаков. Так тема остаётся про событийные триггеры, не каннибализируя общую статью о сегментации.
