Лучшие практики автоматизации в IZI: как не спамить клиентов
Лучшие практики автоматизации в IZI
Заголовок раздела «Лучшие практики автоматизации в IZI»Автоматизация — мощный инструмент, который легко перегнуть. Слишком много правил, слишком частые уведомления, перекрывающиеся условия — и вместо улучшения клиентского опыта получаете раздражённых клиентов которые отключают уведомления. Этот раздел — свод правил гигиены автоматизаций.
Принцип 1 — Ценность для клиента как фильтр
Заголовок раздела «Принцип 1 — Ценность для клиента как фильтр»Перед созданием любого правила с уведомлением задайте себе вопрос: клиент будет рад получить это сообщение?
| Отправлять | Не отправлять |
|---|---|
| Начислен бонус (клиент получил что-то) | При каждом завершении сессии без бонуса |
| Достигнут новый ранг (значимое событие) | При каждом небольшом списании с баланса |
| Реактивационный оффер после долгого отсутствия | Напоминания более трёх раз подряд |
| Приветствие при первом визите | Технические уведомления без ценности для клиента |
Уведомление должно быть событием, а не шумом.
Принцип 2 — Частотные ограничения
Заголовок раздела «Принцип 2 — Частотные ограничения»В IZI нет автоматического ограничителя частоты на уровне платформы — ответственность на владельце клуба.
Максимум за одну сессию: 1–2 уведомления. Если при завершении сессии клиент может получить уведомление о кэшбэке, о ранге и о бонусе при пополнении — это три уведомления за один визит. Выберите самое важное или объедините в одно.
Максимум реактивационных сообщений: 2 за цикл. 14-й день и 30-й день. После двух попыток без ответа — клиент ушёл, дальнейшие пинги не помогут.
Временной буфер между уведомлениями одного типа: если клиент получил уведомление о реактивации, вернулся, снова ушёл — следующее реактивационное уведомление не раньше чем через новый интервал (14 дней). Реализуется через правильное снятие групп «спящих» при возврате.
Принцип 3 — Антиспам-архитектура правил
Заголовок раздела «Принцип 3 — Антиспам-архитектура правил»Разделяйте аудиторию условиями. Если бонус при пополнении действует для всех, а кэшбэк за бар — только для группы «Золото», добавьте условие по группе в кэшбэк-правило. Без условий правило применяется ко всем — это может быть не то что вы хотели.
Проверяйте пересечение событий. Для каждого события (Завершена сессия, Пополнение баланса и т.д.) просмотрите все активные правила с этим событием. Если два правила срабатывают на одно событие без разделяющих условий — клиент получит оба действия.
Чеклист пересечений:
| Событие | Все активные правила | Пересечение условий |
|---|---|---|
| Завершена сессия | Список всех правил | Нет ли двух правил без взаимоисключающих условий? |
| Пополнение баланса | Список всех правил | Не начисляют ли два правила за одно пополнение? |
Используйте взаимоисключающие условия для рангов. В ранговой системе правила для каждого ранга должны иметь взаимоисключающие диапазоны часов. Серебро: ≥ 10 И < 50. Золото: ≥ 50. Без верхней границы для Серебра клиент с 60 часами попадёт под оба правила.
Принцип 4 — Тестирование перед запуском на всю базу
Заголовок раздела «Принцип 4 — Тестирование перед запуском на всю базу»Тест на одном клубе. При создании правила укажите конкретный клуб в поле «Клубы» — правило будет работать только там. Проведите несколько тестовых операций, проверьте историю срабатываний.
Тестовый клиент. Заведите отдельный аккаунт для тестирования (ваш номер телефона или номер коллеги). Всегда проверяйте новые правила на тестовом клиенте перед тем как снять ограничение по клубу.
Проверка истории. После тестовой операции: Автоматизация → правило → вкладка История → проверить статус (Выполнено / Пропущено / Ошибка). Статус «Выполнено» при правильных условиях = правило работает.
Принцип 5 — A/B тестирование
Заголовок раздела «Принцип 5 — A/B тестирование»Нативного A/B тестирования в IZI нет, но можно организовать вручную.
Способ через группы:
- Создайте две группы: «Тест A» и «Тест B»
- Разделите похожих клиентов между группами (например, первая половина алфавита в A, вторая в B)
- Создайте два варианта правила — одно с условием «Группа = Тест A», другое с «Группа = Тест B»
- Запустите оба правила одновременно на 2–4 недели
- Сравните: количество срабатываний, метрики клиентов из каждой группы (возвраты, пополнения)
Что тестировать:
- Размер бонуса (50 vs 100 бонусов за первую сессию)
- Срок действия бонуса (14 дней vs 30 дней)
- Текст уведомления (эмоциональный vs нейтральный)
- Интервал реактивации (14 дней vs 21 день)
Минимальный срок теста: 2–4 недели, желательно одинаковые дни недели в обоих периодах. Меньший срок — слишком мало событий для выводов.
Принцип 6 — Управление набором правил
Заголовок раздела «Принцип 6 — Управление набором правил»Именование правил. Чёткое название экономит время при диагностике. Формат: «[Категория]: [Действие] — [Условие]». Примеры:
- «Ранг: Золото — назначение»
- «Бонус: 10% при пополнении от 500»
- «Реактивация: 30 дней без визита»
Группировка описаниями. Используйте поле «Описание» в правиле для контекста: когда создано, какую задачу решает, до какой даты должно работать (для временных акций).
Регулярный аудит. Раз в квартал: откройте список всех правил. Для каждого правила ответьте на три вопроса:
- Это правило всё ещё нужно?
- Оно срабатывает ожидаемо часто?
- Нет ли другого правила которое делает то же самое?
Правило которое не срабатывает — или неактуально, или настроено неверно. Лишние правила — технический долг и источник неожиданных пересечений.
Принцип 7 — Opt-out клиентов
Заголовок раздела «Принцип 7 — Opt-out клиентов»Клиент управляет уведомлениями на уровне устройства. В IZI нет встроенного «отписаться от маркетинговых уведомлений» в профиле — это системная настройка iOS/Android.
Рекомендации:
- В FAQ клуба опишите как отключить уведомления (Настройки устройства → Приложения → IZI → Уведомления)
- Не пытайтесь обойти отключение уведомлений
- Если клиент просит «не присылать рекламу» — можно убрать его из соответствующих групп (например, из группы которая получает акционные уведомления)
Клиент который отключил уведомления, но продолжает ходить — ценнее, чем клиент раздражённый спамом.
Принцип 8 — Порядок действий в правиле
Заголовок раздела «Принцип 8 — Порядок действий в правиле»При нескольких действиях в правиле важен порядок. Рекомендуемый:
- Снять старые группы (если ранговая система)
- Присвоить новую группу
- Начислить бонусы
- Отправить уведомление — всегда последним
Уведомление последним потому что к моменту когда клиент откроет приложение, все предыдущие действия уже выполнены: ранг обновлён, бонус начислен. Клиент видит актуальное состояние.
Чеклист перед запуском нового правила
Заголовок раздела «Чеклист перед запуском нового правила»- Событие запуска выбрано правильно
- Условия не позволяют правилу сработать для нежелательных клиентов
- Порядок действий логичный (бонус → уведомление)
- Название правила понятное без пояснений
- Правило протестировано на тестовом клиенте
- Проверены пересечения с другими активными правилами для того же события
- Для временной акции — в описании указана дата завершения
- Если тестируете — ограничили одним клубом
Чеклист аудита существующих правил (раз в квартал)
Заголовок раздела «Чеклист аудита существующих правил (раз в квартал)»- Все активные правила имеют чёткие названия
- Нет правил которые срабатывают нулевой раз за последний месяц (кроме исключительных сценариев)
- Нет дублирующих правил с одинаковым событием и похожими условиями
- Временные акции выключены после завершения
- Для каждого события не более 3–4 активных правил
Типичные ошибки
Заголовок раздела «Типичные ошибки»| Ошибка | Сигнал | Решение |
|---|---|---|
| Слишком много уведомлений за визит | Клиенты жалуются на спам, отключают уведомления | Оставьте максимум 1–2 уведомления за сессию |
| Правила для бывших акций забыты и работают | Устаревшие тексты в уведомлениях | Квартальный аудит, выключайте временные правила по дате |
| Двойное начисление бонусов | Клиенты получают больше чем ожидалось | Проверьте пересечение условий правил для одного события |
| Непонятные названия правил | Невозможно быстро понять что делает правило | Переименуйте по формату «[Категория]: [Действие]» |
См. также
Заголовок раздела «См. также»Частые вопросы
Сколько уведомлений в день нормально для клиента?
Максимум 1–2 содержательных уведомления за одну сессию. Если за один визит клиент получает уведомление о кэшбэке, ранге и реактивации одновременно — это перегрузка. Оставляйте только те которые добавляют реальную ценность.
Как узнать что клиент перегружен уведомлениями?
Косвенный сигнал — рост числа клиентов с отключёнными уведомлениями от приложения. Прямой статистики в CRM нет, но если конверсия в клики по уведомлениям падает — аудитория «устала». Уменьшите количество правил с уведомлениями.
Нужно ли давать клиентам возможность отписаться от уведомлений?
Да. Клиент управляет уведомлениями на уровне устройства (iOS/Android системные настройки). Рекомендуем в FAQ клуба объяснить как отключить уведомления — это лучше чем клиент раздражается и удаляет приложение.
Как тестировать новое правило не затронув всю базу?
Создайте правило с ограничением по клубу (выберите один тестовый клуб в поле «Клубы»). После подтверждения что работает корректно — расширьте на всю организацию.
Сколько правил нормально для клуба?
Типовая конфигурация — 10–20 активных правил. Больше 30 — признак что правила дублируют друг друга или система стала неуправляемой. Периодически делайте аудит: выключите всё, включайте по одному и проверяйте что каждое правило реально нужно.
Можно ли проводить A/B тесты с разными версиями правил?
Нативного A/B тестирования в IZI нет. Самый простой способ: создайте две версии правила с разными условиями (например, разные группы клиентов), запустите параллельно на 2–4 недели, сравните срабатывания и метрики клиентов из каждой версии.
Как убедиться что два правила не конфликтуют?
Для каждого события просмотрите все активные правила с этим событием. Клиент получает все действия всех подходящих правил. Если два правила начисляют бонусы за одно и то же событие без разделения по условиям — клиент получит двойное начисление.