🔁 Ревизия 11.09: основное сделано, остаток — отдельной задачей «Визит гостя по присутствию за столом и метрика «оплачено гостем»».
🗺 Этап 5 (маркетинг/рост)
📌 СУТЬ (TL;DR) Сценарий должен собираться из кубиков, а не выбираться из готовых. Сегодня часть логики живёт не там, где её ищет владелец: «за сколько дней до ДР» и «сколько дней без визита» — это фильтры аудитории, но они спрятаны в шаге «Триггер», а условий с такой логикой нет вообще. Значит свой сценарий с той же логикой собрать нельзя — пресет предлагает настройки, которых нет в общей комплектации. Правило, к которому приводим раздел: ТРИГГЕР = когда и с каким ритмом, УСЛОВИЯ = кому, ПРЕСЕТ = только предзаполнение того и другого, ничего своего.
⚠️ Анти-спам: не пишите «сделайте фильтр по датам» — прочтите список полей ниже, он уже согласован. Полезны: недостающие поля условий из вашей практики и примеры сценариев, которые на текущем наборе не собираются.
✅ УЖЕ УЧТЕНО (не нужно напоминать) — диапазон значений: собирается двумя правилами с «И», отдельный контрол не нужен; — пересечение условий, порядок правил, ВСЕ/ЛЮБОЕ — есть; — антидубль (один запуск на гостя за период триггера) — инвариант движка, не настройка; — тихие часы, частотный лимит, согласие на рассылку — есть в правилах доставки; — время сценария считается в часовом поясе точки — сделано 21.07.2026.
🚫 ЧТО НЕ ВХОДИТ — пресеты-пакеты (один клик = несколько связанных сценариев) — прорабатываем отдельно; — вложенные группы условий со скобками (плоский AND/OR остаётся: новичок не должен спотыкаться); — сегменты как сохранённая сущность (Аналитика 2.0, фаза 2); — визуальный конструктор-схема (ветвления) — не в этой итерации.
❓ ОТКРЫТЫЕ ВОПРОСЫ — нужен ли оператор «между» отдельным контролом, если два правила уже дают диапазон; — какие ещё даты цепляем к механизму смещения (годовщина первой покупки, дата регистрации, дата последнего визита) и в каком порядке.
1. Условия — ядро
Операторы для чисел: > ≥ = ≤ < (сейчас только «больше»/«меньше»). Пример на «=»: «покупок = 1» — гость купил ровно раз, классический сценарий «догнать после первой покупки».
Новые поля (источник — материализованные метрики гостя customer_metrics):
- дней с последнего визита;
- визитов всего;
- сумма покупок;
- средняя покупка гостя;
- RFM-сегмент (равно / не равно) — связывает Аналитику с Автоматизацией.
Даты как класс полей. Поле «День рождения» + оператор смещения: «за N дней до», «в день», «через N дней после». Тем же механизмом позже подключаются годовщина первой покупки и дата регистрации. Отдельное условие «дата рождения указана» — сейчас пустой birthday у большинства гостей даёт молча пустую аудиторию.
Источник (UTM) — выбор, а не ввод. Одно условие, под ним пять уровней (source → medium → campaign → content → term) селектами сверху вниз: заполняешь до нужной глубины, незаполненные = «любой». Значения — только реально встречающиеся у этой организации, с количеством гостей рядом; каскад (medium показывает только то, что бывает при выбранном source); отдельная опция «не указан». Ручной ввод убрать — опечатка Instagram вместо instagram сейчас молча даёт нулевую аудиторию. Метка — тоже выбор из существующих.
Оценка NPS — числовое поле, семантика «последняя известная оценка гостя». При NPS-триггере это только что полученная оценка; в плановом сценарии — последняя известная («раз в месяц всем, у кого оценка ≥ 9 — попроси отзыв»).
2. Триггеры
- Новый: «Получена оценка NPS» (
nps.answered) — событие эмитится из вебхука.
- «Давно не был» и «День рождения» остаются ритмом, их параметры (
days, days_before) переезжают в условия; пресет их предзаполняет. Ритм — это законная работа триггера: у «Давно не был» ведро антидубля месячное, поэтому спящий не получает письмо каждый день, пока не вернётся.
- Баг: «Давно не был» считает последний визит по шапке чека (
pos_receipts.customer_id). На чеках, где платил один, а ели несколько, шапка пуста → участник числится «не был ни разу» и получает реактивацию. Перевести на customer_metrics.
3. Данные и метрики
- Визит = присутствие за столом (
customer_uid), даже если за гостем не записано ни одной позиции. Персонал часто не разбивает чек — особенно на постоянниках — и сваливает все позиции на одного. Гость не должен из-за этого попадать в «спящие».
- Развести три величины и не путать в интерфейсе: средний чек (на чек/стол — метрика заведения, оценка посадки), средняя покупка гостя (его строки / его визиты — состав личной корзины), оплачено гостем (роль плательщика — кто реально носит деньги).
4. Действия
- Системные кнопки «Отзыв в 2ГИС» / «Отзыв в Яндекс» — ссылка из карточки точки (сейчас их умеет подставлять только зашитый код NPS).
- Починить: действие «Уведомить команду» зовёт уведомление без привязки гостя → ответ администратора на такое уведомление не уходит гостю. У зашитого NPS-алерта привязка есть, и при переносе логики в сценарии
