Рекомендации по работе с сегментами
Сегменты — ключевой инструмент работы с данными в CDP-платформе. От их корректной настройки зависит качество выборок, аналитики и запуска маркетинговых рассылок. Однако на практике иногда возникают ситуации, когда сегмент не работает так, как ожидается: не пересчитывается, не обновляется или возвращает неожиданные результаты.
Чтобы упростить поиск и устранение таких проблем, в этой статье собраны рекомендации по работе с сегментами.
Слишком большое количество условий с "НЕ"
Чрезмерное использование отрицаний, особенно оператора НЕ В СЕГМЕНТЕ, сильно усложняет логику и снижает производительность.
Оператор "НЕ В СЕГМЕНТЕ".
Это самый тяжёлый с точки зрения производительности оператор. При его использовании система выгружает всю базу профилей, чтобы выполнить пересечение с исключаемым сегментом. Это очень долго.
Пример проблемной конструкции:
НЕ В (сегмент A)
И НЕ В (сегмент B)
И НЕ В (сегмент C)
...
Рекомендации:
- По возможности избегайте оператора "НЕ В СЕГМЕНТЕ". Вместо него продублируйте условия из исключаемого сегмента, но с обратным знаком.
Например, нужно отобрать профили, которые не входят в сегмент "Не состоит в ГКГ". Вместо НЕ СОСТОИТ (сегмент "Не состоит в ГКГ") используйте условие Состоит в ГКГ . Результат будет тот же, а производительность — выше.
-
Не используйте более 2–3 условий с "НЕ" (любых) подряд без веской причины.
-
Заменяйте набор условий с "НЕ" на одно позитивное правило. Вместо перечисления, где объект не должен находиться, лучше описать, где он должен находиться.
-
Документируйте правила сегментации: указывайте, зачем добавлено каждое отрицание. Это поможет избежать ситуации, когда одно из условий становится неактуальным, а логика остаётся избыточно сложной.
-
Применяйте "НЕ В СЕГМЕНТЕ" только тогда, когда без него действительно не обойтись (например, исключаемый сегмент динамически обновляется другой командой).
Использование условия с "НЕ" через "ИЛИ"
Часто при построении сегмента задаётся условие вида:
НЕ (имеет активный договор) ИЛИ НЕ (прошёл верификацию)
На первый взгляд может показаться, что такое условие исключит всех клиентов без договора и без верификации. На практике оно работает иначе: в сегмент попадут все клиенты, кроме тех, у кого одновременно есть и активный договор, и пройдена верификация.
Это значит, что условие исключает только тех, у кого оба признака выполняются одновременно, а не всех, кто обладает хотя бы одним из признаков.
Рекомендации:
-
Избегайте длинных выражений с чередованием НЕ и ИЛИ.
-
Если требуется отобрать только клиентов, у которых нет договора и нет верификации, используйте:
НЕ (имеет активный договор) И НЕ (прошёл верификацию)
Индексы и производительность сегментов
Индексы — это внутренние структуры базы данных, которые ускоряют поиск профилей по значениям полей. Без индекса система вынуждена перебирать всех клиентов подряд — сегмент строится медленно, особенно на больших базах.
Часть индексов создаётся автоматически при запуске платформы. Это системные индексы, которые необходимы для работы платформы. Вы не можете управлять ими, и их набор может отличаться в разных инсталляциях. Запросы по таким полям обычно работают быстро, но полагаться на это для любых полей не стоит.
Рекомендации
Проанализируйте, какие сегменты вы строите чаще всего и какие поля в них используете. Передайте этот список администратору. Администратор проверит, какие индексы уже есть, и при необходимости создаст дополнительные с учётом ограничений.
Всего на аккаунт можно создать не более 64 индексов. Подробнее про индексы баз данных вы можете узнать в документации администратора.
Хранение списков значений
Если в сегменте нужно отобрать профили по конкретному значению из списка (например, интересы, категории, метки), такие списки стоит хранить в поле типа "теги", а не в строке.
Например, поле interests содержит tennis, football, chess. Если требуется выбрать всех, кому интересен теннис, при хранении в строке процесс сегментации займёт больше времени, чем при хранении в поле типа "теги".
Диапазон дат
Если в условии сегмента используется дата (дата регистрации, дата заказа, достижение цели, открытие письма), процесс пересчёта будет быстрее, когда диапазон значений ограничен. Чем меньше дат надо проверить, тем меньше времени уходит на сегментацию.
Рекомендации:
-
По возможности указывайте конкретный период. Вместо "достигнута цель" используйте "достигнута цель в последние 7 дней".
-
Вместо проверки событий за всё время по возможности используйте атрибуты профиля, которые не требуют сканирования истории (например, "дата последнего заказа" вместо "был хотя бы один заказ").
-
Для регулярных сегментов ставьте относительные даты ("последние N дней"), но не берите N слишком большим — обычно достаточно 30–90 дней.